Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group