On Wed, Sep 7, 2011 at 4:55 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
Well, according to Dave's report upthread, it's not only this one relation: DG> The recent errors are: DG> lock AccessShareLock on object 16403/2615/0 is already held DG> which is for pg_namespace in database c23. 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. And it should. But there's a bit more action-at-a-distance there than I'd ideally like. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
