Rod Taylor <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
