Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
> In the same vein, why is it necessary to be holding
> SerializableXactHashLock (exclusively, yet) while acquiring the
> snapshot? That seems rather bad from a concurrency standpoint,
> and again it's going to be pretty meaningless if we're just
> installing a pre-existing snapshot.
That seems like something which probably could and should be fixed,
especially since SerializableXactHashLock can become a bottleneck in
9.1 and will be much more of a problem with the elimination of other
bottlenecks in 9.2.
> The reason these things came to mind is that I want to refactor
> the code so that the SSI-specific work in
> GetSerializableTransactionSnapshotInt is done by a function that
> is handed an already-taken snapshot, because I cannot stomach what
> Joachim did to the APIs of GetSnapshotData and allied functions.
> But refactor or no refactor, it seems like installing a
> pre-existing snapshot may be breaking some assumptions here.
I guess the other thing to look out for is whether it could possibly
move PredXact->SxactGlobalXmin backwards. I would have to check for
other possible problems.
-Kevin