Re: Lazy Snapshots - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Lazy Snapshots
Date
Msg-id 7244.1250605082@sss.pgh.pa.us
Whole thread Raw
In response to Lazy Snapshots  ("simon@2ndquadrant.com" <simon@2ndquadrant.com>)
Responses Re: Lazy Snapshots  ("simon@2ndquadrant.com" <simon@2ndquadrant.com>)
List pgsql-hackers
"simon@2ndquadrant.com" <simon@2ndquadrant.com> writes:
> Currently, we take eager snapshots, meaning we take a snapshot at the start of
> each statement whether or not it is necessary. Snapshots exist to disambiguate
> the running state of recent transactions, so if a statement never sees data
> written by recent transactions then we will never actually use the snapshot.

> Another way of doing this is to utilize lazy snapshots: do not take a snapshot
> when a statement starts and only take one at the point that we need
> one.

Simon, this concept is completely broken, as far as I can tell.
Consider this example:
* You scan some row R1 with an ancient XMIN and no XMAX.  You decide it's visible.* Transaction T2 deletes R1, inserts
R2,and commits.* You scan R2.  Since it has a recent XMIN, you now take  a snapshot.  The snapshot says T2 committed.
Soyou  consider R2 is visible.  This is inconsistent.  In the  worst case R2 might be an update of R1.
 

Even if the idea gave self-consistent results, I don't agree that it's
okay to not know when the statement's snapshot will be taken.  Timing
of snapshots relative to other actions is critical for many reasons.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Determining client_encoding from client locale
Next
From: Michael Clark
Date:
Subject: Re: PQgetlength vs. octet_length()