Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Florian Pflug <fgp(at)phlo(dot)org> writes:
>>> 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.
Right, there are other circumstances in which a READ ONLY
transaction's snapshot may be recognized as safe, and it can opt out
of all the additional SSI logic. As you say, DEFERRABLE means we
*wait* for that.
>> This is nonsense when you're importing the snapshot.
Agreed.
> I think the requirement is that we need to do the appropriate
> push-ups so that the people who import the snapshot know that it's
> safe, and that the SSI stuff can all be skipped.
If the snapshot was safe in the first process, it will be safe for
any others with which it is shared. Basically, a SERIALIZABLE READ
ONLY DEFERRABLE transaction waits for a snapshot which, as a READ
ONLY transaction, can't see any serialization anomalies. It can run
exactly like a REPEATABLE READ transaction. In fact, it would be OK
from a functional perspective if the first transaction in pg_dump
got a safe snapshot through DEFERRABLE techniques and then shared it
with REPEATABLE READ transactions.
I don't know which is the best way to implement this, but it should
be fine to skip the DEFERRABLE logic for secondary users, as long as
they are READ ONLY.
-Kevin