On Wed, Sep 7, 2011 at 6:25 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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.
Well, it's very clear that you CAN orphan locks if a backend holding a session lock ever does CHECK_FOR_INTERRUPTS() outside of a transaction. Try the attached patch. rhaas=# vacuum full foo; FATAL: terminating connection due to administrator command FATAL: terminating connection due to administrator command The connection to the server was lost. Attempting reset: Succeeded. rhaas=# vacuum full foo; ERROR: lock AccessExclusiveLock on object 16384/1431013/0 is already held Now, I don't see any evidence of a live bug here (and on further thought it can't be Dave's bug because he is orphaning AccessShareLocks, not AccessExclusiveLocks), but I find this pretty convincing as a demonstration of ricketiness. It is certainly not obvious on its face that a misplaced CHECK_FOR_INTERRUPTS() can result in a backend exiting without cleaning up its locks, and I'd argue its a bad idea to leave it that way even if there's no user-visible problem there today. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
break-vacuum.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
