On Mon, Jul 24, 2017 at 11:51 AM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Sun, Jul 23, 2017 at 8:32 AM, Tom Lane <t...@sss.pgh.pa.us> 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 tried to > insert a { 0, 0, 0, 0 } tag, and in any case it holds > SerializablePredicateLockListLock in LW_SHARED. > > 2. TransferPredicateLocksToNewTarget(), which removes and restores > the scratch entry and also explicitly inserts a transferred entry. It > asserts that it holds SerializablePredicateLockListLock and is called > only by PredicateLockPageSplit() which acquires it in LW_EXCLUSIVE. > > 3. DropAllPredicateLocksFromTable(), which removes and restores the > scratch entry and also explicitly inserts a transferred entry. > Acquires SerializablePredicateLockListLock in LW_EXCLUSIVE.
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 interlocking. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers