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 new scratch entry without
> interl
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, another backend started up and ran
>> InitPredicateLock
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 inserts
> (HASH_ENTER[_NULL]) into PredicateLockTarget
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 be a bug if that ever
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
>
Buildfarm member culicidae just showed a transient failure in
the 9.4 branch:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=culicidae&dt=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 ../sysde
