On Fri, Jan 13, 2012 at 2:05 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Tue, Nov 29, 2011 at 10:10 AM, Robert Haas <robertmh...@gmail.com> wrote:
>> 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).

The patch looks ok, though I wonder if we could have a way to release
the lock on namespace much before the end of transaction. Since the
lock is held all the time, now the possibility of dead lock is bigger.

-- tx1

-- tx2

I know it's a limited situation, though. Maybe the right way would be
to check the namespace at the end of the transaction if any object is
created, rather than locking it.

> 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.

I took a quick look under src/include/catalog and the objects that
have namespace are

- collation
- constraint
- conversion
- extension
- operator
- operator class
- operator family
- function (proc)
- ts_config
- ts_dict
- ts_parser
- ts_template
- (what's missing?)

I agree with you that it's not worth doing everything, but function is
nice to have. I don't mind if we don't have it with the other objects.

Hitoshi Harada

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to