Re: Weird Assert failure in GetLockStatusData()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Weird Assert failure in GetLockStatusData()
Date: 2013-01-08 22:30:35
Message-ID: 358.1357684235@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2013-01-08 22:37:01 Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it
Previous Message Robert Haas 2013-01-08 22:28:33 Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it