On Wed, Sep 07, 2011 at 04:55:24PM -0400, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > Tom's right to be skeptical of my theory, because it would require a > > CHECK_FOR_INTERRUPTS() outside of a transaction block in one of the > > pathways that use session-level locks, and I can't find one. > > More to the point: session-level locks are released on error. The only > way to get out of a transaction while still holding one is for the > VACUUM-or-whichever-command code to deliberately commit and exit while > still holding it. An error exit path would release the lock. > > > OTOH, I'm skeptical of the theory that this involves userlocks, > > because this whole thread started because of a complaint about lock > > 0/1260/0 already being held. That ain't no userlock. > > Yeah, and for that matter it seems to let VACUUM off the hook too. > If we assume that the reported object ID is non-corrupt (and if it's > always the same, that seems like the way to bet) then this is a lock > on pg_authid. > > Hmmm ... could the pathway involve an error exit from client > authentication? We're still finding bugs in the 9.0 rewrite of > auth-time database access.
It does not seem restricted to pg_authid: 2011-08-24 18:35:57.445 24987 c23 apps ERROR: lock AccessShareLock on object 16403/2615/0 And I think I've seen it on other tables too. -dg -- David Gould da...@sonic.net 510 536 1443 510 282 0869 If simplicity worked, the world would be overrun with insects. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers