Re: FATAL: lock AccessShareLock on object 0/1260/0 is already held - Mailing list pgsql-hackers

From Tom Lane
Subject Re: FATAL: lock AccessShareLock on object 0/1260/0 is already held
Date
Msg-id 7386.1315434323@sss.pgh.pa.us
Whole thread Raw
In response to Re: FATAL: lock AccessShareLock on object 0/1260/0 is already held  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: FATAL: lock AccessShareLock on object 0/1260/0 is already held
Re: FATAL: lock AccessShareLock on object 0/1260/0 is already held
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> I thought about an error exit from client authentication, and that's a
> somewhat appealing explanation, but I can't quite see why we wouldn't
> clean up there the same as anywhere else.  The whole mechanism feels a
> bit rickety to me - we don't actually release locks; we just abort the
> transaction and *assume* that will cause locks to get released.

Well, transaction abort will call LockReleaseAll, which is carefully
coded to clean up the proclock lists regardless of what is in the
locallocks table, so I'm not sure why you find that any more rickety
than anything else.  But maybe it'd be interesting for Dave to stick a
LockReleaseAll call into ProcKill() and see if that makes things better.
(Dave: test that before you put it in production, I'm not totally sure
it's safe.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: daveg
Date:
Subject: Re: FATAL: lock AccessShareLock on object 0/1260/0 is already held
Next
From: Tom Lane
Date:
Subject: Re: FATAL: lock AccessShareLock on object 0/1260/0 is already held