From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "Neil Conway" <neilc(at)samurai(dot)com>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com> |
Subject: | Re: advancing snapshot's xmin |
Date: | 2008-03-26 14:18:02 |
Message-ID: | 19610.1206541082@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dimitri Fontaine <dfontaine(at)hi-media(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-03-26 14:26:16 | Re: having problem in rsync'ing cvs |
Previous Message | Brendan Jurd | 2008-03-26 14:15:42 | Re: having problem in rsync'ing cvs |