On Tue, Mar 06, 2012 at 08:36:05AM -0500, Robert Haas wrote: > On Tue, Mar 6, 2012 at 5:43 AM, Noah Misch <n...@leadboat.com> wrote: > >> Well, consider something like CLUSTER. ?It's perfectly OK for CLUSTER > >> to operate on a table that has been truncated since CLUSTER's snapshot > >> was taken, and no serialization anomaly is created that would not have > >> already existed as a result of the non-MVCC-safe TRUNCATE. ?On the > >> other hand, if CLUSTER operates on a table that was created since > >> CLUSTER's snapshot was taken, then you have a bona fide serialization > >> anomaly. > > > > Core CLUSTER does not use any MVCC snapshot. ?We do push one for the benefit > > of functions called during the reindex phase, but it does not appear that > > you > > speak of that snapshot. ?Could you elaborate this example? > > Imagine this: > > - Transaction #1 acquires a snapshot. > - Transaction #2 creates tables A, inserts a row into table B, and then > commits. > - Transaction #1 tries to CLUSTER A and then select from B. > > The only serial execution schedules are T1 < T2, in which case the > transaction fails, or T2 < T1, in which case the row is seen. But > what actually happens is that the row isn't seen and yet the > transaction doesn't fail.
For the purpose of contemplating this anomaly, one could just as well replace CLUSTER with GRANT, COMMENT ON TABLE, or any other command that operates on a table, correct? I agree this test case is good to keep in mind while designing, but we could well conclude not to bother improving it. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
