Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

On Tue, Nov 29, 2011 at 10:10 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Nov 29, 2011 at 3:37 AM, Daniel Farina <daniel(at)heroku(dot)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