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

Re: SSI bug?

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "YAMAMOTO Takashi" <yamt(at)mwd(dot)biglobe(dot)ne(dot)jp>
Cc: <drkp(at)csail(dot)mit(dot)edu>,<heikki(dot)linnakangas(at)enterprisedb(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SSI bug?
Date: 2011-03-31 13:31:40
Message-ID: 4D943BEC020000250003BFDA@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
YAMAMOTO Takashi <yamt(at)mwd(dot)biglobe(dot)ne(dot)jp> wrote:
 
> hoge=# select locktype,count(*) from pg_locks group by locktype;  
> -[ RECORD 1 ]--------
> locktype | virtualxid
> count    | 1
> -[ RECORD 2 ]--------
> locktype | relation
> count    | 1
> -[ RECORD 3 ]--------
> locktype | tuple
> count    | 7061
 
I've stared at the code for hours and have only come up with one
race condition which can cause this, although the window is so small
it's hard to believe that you would get this volume of orphaned
locks.  I'll keep looking, but if you could try this to see if it
has a material impact, that would be great.
 
I am very sure this patch is needed and that it is safe.  It moves a
LWLockAcquire statement up to cover the setup for the loop that it
already covers.  It also includes a fix to a comment that got missed
when we switched from the pointer between lock targets to
duplicating the locks.
 
-Kevin


Attachment: ssi-old-tuple-locks.patch
Description: text/plain (1.6 KB)

In response to

Responses

pgsql-hackers by date

Next:From: rsmoguraDate: 2011-03-31 13:53:01
Subject: Re: 2nd Level Buffer Cache
Previous:From: Bernd HelmleDate: 2011-03-31 12:38:00
Subject: wal_buffers = -1 and SIGHUP

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