On Tue, Nov 29, 2011 at 10:10 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Nov 29, 2011 at 3:37 AM, Daniel Farina <dan...@heroku.com> wrote: >> Hmm, just to prod this thread: has any fix for this been committed? >> After Nikhil confirmed that this bug could cause pg_dump to not be >> able to operate without direct catalog surgery I have encountered this >> bug (and treated its symptoms in the same manner) twice. I tried to >> do my homework in a backbranch, but am not seeing anything beaming out >> at me. > > I have plans to try to improve this, but it's one of those things that > I care about more than the people who write the checks do, so it > hasn't quite gotten to the top of the priority list yet.
All right... I have a patch that I think fixes this, at least so far as relations are concerned. I rewrote RangeVarGetAndCheckCreationNamespace() extensively, did surgery on its callers, and then modified CREATE OR REPLACE VIEW and ALTER <relkind> .. SET SCHEMA to make use of it rather than doing things as they did before. So this patch prevents (1) concurrently dropping a schema in which a new relation is being created, (2) concurrently dropping a schema into which an existing relation is being moved, and (3) using CREATE OR REPLACE VIEW to attempt to obtain a lock on a relation you don't own (the command would eventually fail, of course, but if there were, say, an outstanding AccessShareLock on the relation, you'd queue up for the lock and thus prevent any further locks from being granted, despite your lack of any rights on the target). It doesn't fix any of the non-relation object types. That would be nice to do, but I think it's material for a separate patch. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
concurrent-drop-schema.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
