Re: Problems with ALTER DOMAIN patch

Rod Taylor <rbt@rbt.ca> writes:
>> 2. Insufficient locking, guise 2: there's no protection against someone
>> else adding a column or table while you're processing an ALTER DOMAIN,
>> either.  This means that constraint checks will be missed.  Example:

> Locking the entry in pg_type doesn't prevent that?

If there were such a thing as "locking the entry in pg_type", it might
prevent that, but (a) there isn't, and (b) your code wouldn't invoke it 
if there were.  Reading a row should surely not be tantamount to
invoking an exclusive lock on it.

In any case, other backends might have the pg_type entry in their
syscaches, in which case their references to the type would be quite
free of any actual read of the pg_type row that might fall foul of
your hypothetical lock.

To make this work in a reliable way, there needs to be some concept
of acquiring a lock on the type as an entity, in the same way that
LockRelation acquires a lock on a relation as an entity --- which has
only the loosest possible connection to the notion of a lock on the
relation's pg_class row.  We have no such locks on types at present,
but I think it may be time to invent 'em.
        regards, tom lane