Re: Snapshot synchronization, again...

Excerpts from Joachim Wieland's message of vie dic 31 00:15:57 -0300 2010:
> On Thu, Dec 30, 2010 at 9:40 AM, Alvaro Herrera
> <alvherre(at)commandprompt(dot)com> wrote:
> >> Disadvantage of b: It doesn't allow a snapshot to be installed on a
> >> different server. It requires a serializable open transaction to hold
> >> the snapshot.
> >
> > Why does it require a serializable transaction?  You could simply
> > register the snapshot in any transaction.  (Of course, the net effect
> > would be pretty similar to a serializable transaction).
>
> I am not assuming that the publishing transaction blocks until its
> snapshot is being picked up. A read committed transaction would get a
> new snapshot for every other query, so the published snapshot is no
> longer represented by an actual backend until it is being picked up by
> one. Since nobody is holding off xmin/GlobalXmin, eventually vacuum
> would remove tuples that the published-but-not-yet-picked-up snapshot
> should still be able to see, no?

A backend can have any number of snapshots registered, and those don't
allow GlobalXmin to advance. Consider an open cursor, for example.
Even if the rest of the transaction is read committed, the snapshot
registered by the open cursor still holds back GlobalXmin. My
(handwavy) idea is that whenever the transaction calls
pg_publish_snapshot(), said snapshot is registered, which makes it safe
to use even if the transaction continues to operate and obtain newer
snapshots.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support