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. VirtualXac
I wrote:
> This is a bit disturbing:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bushpig&dt=2013-01-07%2019%3A15%3A02
> ...
> The assertion failure seems to indicate that the number of
> LockMethodProcLockHash entries found by hash_seq_search didn't match the
> number that had been cou
This is a bit disturbing:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bushpig&dt=2013-01-07%2019%3A15%3A02
The key bit is
[50eb2156.651e:6] LOG: execute isolationtester_waiting: SELECT 1 FROM pg_locks
holder, pg_locks waiter WHERE NOT waiter.granted AND waiter.pid = $1 AND
holder.gr
