On Oct19, 2011, at 18:17 , Tom Lane wrote:
> Joachim Wieland <joe@mcknight.de> writes:
>> [ synchronized-snapshots patch ]
>
> Looking through this code, it strikes me that SET TRANSACTION SNAPSHOT
> is fundamentally incompatible with SERIALIZABLE READ ONLY DEFERRABLE
> mode. That mode assumes that you should be able to just take a new
> snapshot, repeatedly, until you get one that's "safe". With the patch
> as written, if the supplied snapshot is "unsafe", GetSafeSnapshot()
> will just go into an infinite loop.
>
> AFAICS we should just throw an error if SET TRANSACTION SNAPSHOT is done
> in a transaction with those properties. Has anyone got another
> interpretation? Would it be better to silently ignore the DEFERRABLE
> property?
Hm, both features are meant to be used by pg_dump, so think we should
make the combination work. It'd say SET TRANSACTION SNAPSHOT should throw
an error only if the transaction is marked READ ONLY DEFERRABLE *and*
the provided snapshot isn't "safe".
This allows a deferrable snapshot to be used on a second connection (
by e.g. pg_dump), and still be marked as DEFERRABLE. If we throw an
error unconditionally, the second connection has to import the snapshot
without marking it DEFERRABLE, which I think has consequences for
performance. AFAIR, the SERIALIZABLE implementation is able to skip
almost all (or all? Kevin?) SIREAD lock acquisitions in DEFERRABLE READ
ONLY transaction, because those cannot participate in dangerous (i.e.
non-serializable) dependency structures.
best regards,
Florian Pflug
