Philip Warner <pjw@rhyme.com.au> writes:
> In this case, wouldn't the answer depend on the isolation level of session
> 1? For serializable TX, then constraint would not apply; 'read committed'
> would mean the constraint was visible on the second insert and at the commit.
The important issue here is that all schema changes have to be read
on a read-committed basis, even if your transaction is otherwise
serializable. Consider for example the possibility that the schema
change you're ignoring consists of a DROP INDEX or some such --- you'll
fail if you proceed as though the index is still there. This is the
point Vadim was making a few days ago (but I didn't understand at the
time).
I believe we can work out a consistent set of behavior such that user
data accesses (SELECT/UPDATE/etc) follow MVCC rules but system accesses
to schema data always follow read-committed semantics. One of the
components of this has to be an agreement on how to handle locking.
AFAICS, we have to adopt hold-some-kind-of-lock-till-end-of-xact,
or we will have consistency problems between the user and system
views of the world.
regards, tom lane