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

Re: lock AccessShareLock on object 0/1260/0 is already held

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, daveg(at)sonic(dot)net
Subject: Re: lock AccessShareLock on object 0/1260/0 is already held
Date: 2013-01-04 17:10:15
Message-ID: CAFj8pRBxPvH9LxUOHRzvTkuOnX1dVJkF=VJyxaFQPbK5L3YhuA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2013/1/4 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> What is state of this issue?
>> http://archives.postgresql.org/pgsql-hackers/2011-09/msg00423.php
>
> AFAICS we never identified the cause.  It was pretty clear that
> something was failing to clean up shared-memory lock data structures,
> but not what that something was.  The last productive suggestion was
> to add process-exit-time logging of whether unreleased locks remain,
> but if Dave ever did that, he didn't report back what he found.


probably I am able to find statement, that was canceled as last
"success" statement from our application logs. And probably it will be
LOCK ... or CREATE TABLE AS SELECT

Recheck on session end can help us to drop this leaked locks, but I
don't understand how it can help with finding with finding the cause?




>
> Maybe you could add such logging on your machines.
>
>                         regards, tom lane


In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2013-01-04 17:10:16
Subject: Re: enhanced error fields
Previous:From: Alvaro HerreraDate: 2013-01-04 17:08:35
Subject: Re: PATCH: optimized DROP of multiple tables within a transaction

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