From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
Cc: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, "'Hiroshi Inoue'" <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: AW: AW: relation ### modified while in use |
Date: | 2000-10-23 16:29:17 |
Message-ID: | 11676.972318557@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Philip Warner <pjw(at)rhyme(dot)com(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-10-23 16:43:53 | Re: add darwin/osxpb support to cvs |
Previous Message | Tom Lane | 2000-10-23 16:19:41 | Re: Add support for <xti.h> |