Re: Buildfarm failure and dubious coding in predicate.c
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@postgresql.org
Date: 2017-07-22T20:32:39Z
Lists: pgsql-hackers
I wrote: > And, while I'm looking at this ... isn't this "scratch target" logic > just an ineffective attempt at waving a dead chicken? It's assuming > that freeing an entry in a shared hash table guarantees that it can > insert another entry. But that hash table is partitioned, meaning it has > a separate freelist per partition. So the extra entry only provides a > guarantee that you can insert something into the same partition it's in, > making it useless for this purpose AFAICS. After further study I found the bit in get_hash_entry() about "borrowing" entries from other freelists. That makes all of this safe after all, which is a good thing because I'd also found other assumptions that would have been broken by the behavior I posited above. But I think that that code is desperately undercommented -- the reader could be forgiven for thinking that it was an optional optimization, and not something that is critical for correctness of several different callers. I'm going to go improve the comments. Meanwhile, it's still pretty unclear what happened yesterday on culicidae. regards, tom lane
Commits
-
Fix race condition in predicate-lock init code in EXEC_BACKEND builds.
- 51865a0a0141 9.6.4 landed
- e2c8100e6072 10.0 landed
- 4ecee1192a02 9.3.18 landed
- 05a562d9cefc 9.2.22 landed
- 8ad35c7fa67d 9.4.13 landed
- 5146ca3525a8 9.5.8 landed
-
Improve comments about partitioned hash table freelists.
- ab2324fd468c 10.0 landed