On Tue, Mar 6, 2012 at 5:43 AM, Noah Misch <n...@leadboat.com> wrote: >> Now, maybe we're never going to fix those kinds of anomalies anyway, >> but if we go with this architecture, then I think the chances of it >> ever being palatable to try are pretty low. > > Why?
Because it'll require at least one XID column in every system catalog that represents an SQL catalog to plug all the cases, and I doubt very much that we want to go there. > Simon's point about xmin vs. xid probably leads to an example. One value is > fine for TRUNCATE, because only the most recent TRUNCATE matters. Not all DDL > is so simple. Yep. >> 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers