Re: Lazy Snapshots

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "simon(at)2ndquadrant(dot)com" <simon(at)2ndquadrant(dot)com>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Lazy Snapshots
Date: 2009-08-18 14:18:02
Message-ID: 7244.1250605082@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"simon(at)2ndquadrant(dot)com" <simon(at)2ndquadrant(dot)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. So you
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Clark 2009-08-18 15:04:24 Re: PQgetlength vs. octet_length()
Previous Message Heikki Linnakangas 2009-08-18 11:49:25 Re: Determining client_encoding from client locale