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
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 |