Re: RFC: Making TRUNCATE more "MVCC-safe"

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