I wrote:
> After digging around a bit, I can find only one place where it looks
> like somebody might be messing with the LockMethodProcLockHash table
> while not holding the appropriate lock-partition LWLock(s):
> 1. VirtualXactLock finds target xact holds its VXID lock fast-path.
> 2. VirtualXactLock calls SetupLockInTable to convert the fast-path lock
> to regular.
> 3. SetupLockInTable makes entries in LockMethodLockHash and
> LockMethodProcLockHash.
> I see no partition lock acquisition anywhere in the above code path.
I've been able to reproduce the assertion crash by forcing the
appropriate timing with some carefully chosen debugger breakpoints.
So this theory is evidently correct.
> If this is a bug, it's rather disturbing that it took us this long to
> recognize it. That code path isn't all that seldom-taken, AFAIK.
On closer inspection, VirtualXactLock() is only called in CREATE INDEX
CONCURRENTLY and DROP INDEX CONCURRENTLY (and yes, the failed test case
on bushpig was exercising DROP INDEX CONCURRENTLY). So maybe the path
isn't that frequently taken after all.
regards, tom lane