On Tue, Mar 6, 2012 at 5:43 AM, Noah Misch <noah@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