Re: advancing snapshot's xmin - Mailing list pgsql-hackers

From Tom Lane
Subject Re: advancing snapshot's xmin
Date
Msg-id 19610.1206541082@sss.pgh.pa.us
Whole thread Raw
In response to Re: advancing snapshot's xmin  (Dimitri Fontaine <dfontaine@hi-media.com>)
Responses Re: advancing snapshot's xmin
List pgsql-hackers
Dimitri Fontaine <dfontaine@hi-media.com> writes:
> Le mercredi 26 mars 2008, Tom Lane a écrit :
>> whenever the number of active snapshots goes to zero

> Does this ever happen?

Certainly: between any two commands of a non-serializable transaction.

In a serializable transaction the whole thing is a dead issue
anyway, since the original snapshot has to be kept.

There are corner cases involving open cursors where a snapshot
might persist longer, and then the optimization wouldn't apply.

The formulation that Alvaro gave would sometimes be able to
move xmin forward when the simple no-snaps-left rule wouldn't,
such as create cursor A, create cursor B (with a newer snap),
close cursor A.  However I really doubt that scenarios like
this occur often enough to be worth having a much more expensive
snapshot-management mechanism.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Brendan Jurd"
Date:
Subject: Re: having problem in rsync'ing cvs
Next
From: Alvaro Herrera
Date:
Subject: Re: having problem in rsync'ing cvs