Excerpts from Kevin Grittner's message of lun feb 21 18:39:26 -0300 2011:
> Alvaro Herrera wrote:
>
> > I think we need a safety net so that the new serializable isolation
> > code doesn't get upset if we change the base snapshot from under
> > it, but I haven't looked at that yet.
>
> Replacing the snapshot for a serializable transaction after it has
> acquired its initial snapshot would quietly allow non-serializable
> behavior, I would think. I don't think that setting a snapshot for a
> SERIALIZABLE READ ONLY DEFERRABLE transaction makes any sense, since
> the point of that is that it waits for a snapshot which meets certain
> criteria to be available; setting a snapshot in that mode should
> probably just be disallowed. Otherwise, if you set the snapshot
> before the transaction acquires one through normal means, I can't
> think of any problems -- just make sure you set FirstSnapshotSet.
Actually this seems rather difficult to do, because in order to invoke
the function that imports the snapshot, you have to call SELECT, which
acquires a snapshot beforehand. So when we actually import the
passed-in snapshot, there's already a snapshot set. This is odious but
I don't see a way around that -- other than adding special grammar
support which seems overkill.
I've been thinking in requiring that snapshot to have refcount==1, but
I'm not sure if that works.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support