Florian Pflug <fgp@phlo.org> writes:
> On Oct19, 2011, at 18:17 , Tom Lane wrote:
>> 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".
Um, no, I don't think so. It would be sensible for the "leader"
transaction to use READ ONLY DEFERRABLE and then export the snapshot it
got (possibly after waiting). It doesn't follow that the child
transactions should use DEFERRABLE too. They're not going to wait.
> 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.
No, I don't believe that either. AIUI the performance benefit comes if
the snapshot is recognized as safe. DEFERRABLE only means to keep
retrying until you get a safe one. This is nonsense when you're
importing the snapshot.
regards, tom lane