"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Is it really necessary for GetSerializableTransactionSnapshotInt
>> to acquire an empty SERIALIZABLEXACT before it acquires a
>> snapshot? If so, why? The proposed synchronized-snapshots
>> feature will mean that the allegedly-new snapshot actually was
>> taken some time before, so it seems to me that either this is not
>> necessary or we cannot use a synchronized snapshot in a
>> serializable xact.
> Hmm. If the intent is that each serializable transaction sharing
> the snapshot is a separate logical transaction, it *might* hold -- I
> have to think about that a bit. If the intent is that the work of
> one logical transaction is being split across processes, then SSI
> doesn't hold up without somehow tying all of the processes to a
> single SERIALIZABLEXACT; and then the direct access to
> MySerializableXact falls apart.
No, the intention of the synchronized-snapshots feature is just to be
able to start multiple transactions using exactly the same snapshot.
They're independent after that. The aspect of it that is worrying me
is that if xact A starts, gets a snapshot and publishes it, and then
xact B starts and wants to adopt that snapshot, then
(1) other transactions may have started or ended meanwhile; does that
break any of SSI's assumptions?
(2) as things stand, xact A need not be running in serializable mode ---
if B is serializable, does *that* break any assumptions?
We already have to have an interlock to ensure that GlobalXmin doesn't
go backwards, by means of requiring A to still be running at the instant
B adopts the snapshot and sets its MyProc->xmin accordingly. However,
there is not currently anything that guarantees that A is still running
by the time B does GetSerializableTransactionSnapshotInt, shortly later.
So if your answer to question (1) involves an assumption that A is still
running, we're going to have to figure out how to arrange that without
deadlocking on ProcArrayLock vs SerializableXactHashLock. Which might
be another good reason for changing predicate.c so that we don't hold
the latter while taking a snapshot ...
regards, tom lane