Re: [HACKERS] Buildfarm failure and dubious coding in predicate.c

2017-07-24 Thread Tom Lane
Thomas Munro writes: > Ahh, I think I see it. This is an EXEC_BACKEND build farm animal. > Theory: After the backend we see had removed the scratch entry and > before it had restored it, another backend started up and ran > InitPredicateLocks(), which inserted a

Re: [HACKERS] Buildfarm failure and dubious coding in predicate.c

2017-07-24 Thread Thomas Munro
On Tue, Jul 25, 2017 at 7:24 AM, Tom Lane wrote: > Thomas Munro writes: >> Ahh, I think I see it. This is an EXEC_BACKEND build farm animal. >> Theory: After the backend we see had removed the scratch entry and >> before it had restored it,

Re: [HACKERS] Buildfarm failure and dubious coding in predicate.c

2017-07-24 Thread Thomas Munro
On Mon, Jul 24, 2017 at 11:51 AM, Thomas Munro wrote: > On Sun, Jul 23, 2017 at 8:32 AM, Tom Lane wrote: >> Meanwhile, it's still pretty unclear what happened yesterday on >> culicidae. > > That failure is indeed baffling. The only code that

Re: [HACKERS] Buildfarm failure and dubious coding in predicate.c

2017-07-23 Thread Thomas Munro
On Sun, Jul 23, 2017 at 8:32 AM, Tom Lane wrote: > Meanwhile, it's still pretty unclear what happened yesterday on > culicidae. That failure is indeed baffling. The only code that inserts (HASH_ENTER[_NULL]) into PredicateLockTargetHash: 1. CreatePredicateLock(). I would

Re: [HACKERS] Buildfarm failure and dubious coding in predicate.c

2017-07-22 Thread Tom Lane
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 >

[HACKERS] Buildfarm failure and dubious coding in predicate.c

2017-07-21 Thread Tom Lane
Buildfarm member culicidae just showed a transient failure in the 9.4 branch: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=culicidae=2017-07-21%2017%3A49%3A37 It's an assert trap, for which the buildfarm helpfully captured a stack trace: #0 __GI_raise (sig=sig@entry=6) at