On Mon, Mar 21, 2016 at 4:48 AM, Aleksander Alekseev <a.aleks...@postgrespro.ru> wrote: >> This is the point where I think I am missing something about patch. >> As far as I can understand, it uses the same freelist index >> (freelist_idx) for allocating and putting back the entry, so I think >> the chance of increment in one list and decrement in another is there >> when the value of freelist_idx is calculated differently for the same >> input, is it so, or there is something else in patch which I am >> missing? > > You are right, nentries _can't_ be negative unless we are using getpid() > for calculating freelist_idx, since same index of nentries is used > when we add (increment) and remove (decrement) element from/to hash > table. The fact that we also borrow elements from other freelists if > there is no more elements in our freelist doesn't change anything.
Ah. OK, I missed that. > Once again I suggest we merge this patch already: > > http://www.postgresql.org/message-id/CA+Tgmobtf9nH566_jjs=jrtymq5hdqdarf5j7o+abdowqhe...@mail.gmail.com > > I have a strong feeling that we are just wasting our time here. That is possible. However, I would like it if you would give me the benefit of the doubt and assume that, if I seem to be more cautious than you would be were you a committer, there might possibly be some good reasons for that. The fact is that, despite being more cautious than some people think I should be, I still manage to introduce quite a number of bugs via the patches I commit - see the thread 'Missing rows with index scan when collation is not "C"' on pgsql-bugs for just the very latest example of that. Nobody thinks that will happen with *their* patch, of course, but it does all the same. I'd still like an answer to the question of why this helps so much when there must be huge amounts of false sharing between the different mutexes. Maybe it doesn't matter, though. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers