Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

> > We definitely need some interlocking to handle this. For lack of better
> > APIs, we could do a LockDatabaseObject() call in AccessShareLock mode on
> the
> > namespace and release the same on completion of the creation of the
> object.
> >
> > Thoughts?
>
> In general, we've been reluctant to add locking on non-table objects
> for reasons of overhead. You can, for example, drop a type or
> function while a query is running that depends on it (which is not
> true for tables). But I think it is sensible to do it for DDL
> commands, which shouldn't be frequent enough for the overhead to
> matter much.

Agreed. Especially if the race condition has non-trivial downsides as
mentioned in the tablespace case.

> When I rewrote the comment code for 9.1, I added locking
> that works just this way, to prevent pg_description entries from being
> orphaned; see the end of get_object_address().
>
>
Yeah thanks, that does the object locking. For pre-9.1 versions, we will
need a similar solution. I encountered the issue on 8.3.x..

Regards,
Nikhils