On Oct19, 2011, at 18:17 , Tom Lane wrote: > Joachim Wieland <j...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers