> > You forget about Tx Old! The point is that changes made by
> > Tx Old *over* Tx New' changes effectively make those Tx New'
> > changes *visible* to Tx S!
>
> Yes, but what's that got to do with the order of operations in
> GetSnapshotData? The scenario you describe can occur anyway.
Try to describe it step by step.
> Only if Tx Old is running in Read Committed mode, of course.
> But if it is, then it's capable of deciding to update a row updated
> by Tx New. Whether Tx S's xmax value is before or after Tx New's ID
> is not going to change the behavior of Tx Old.
1. I consider particular case when Tx S' xmax is before Tx New' ID.
1.1 For this case acquiring SInval lock before ReadNewTransactionId() changes behavior of Tx Old: it postpones change
ofTx Old' (and Tx New') MyProc->xid in xact.c:CommitTransaction(), so Tx S will see Tx Old as running, ie Tx Old'
changeswill be invisible to Tx S on the base of analyzing MyProc.xid-s, just like Tx New' changes will be invisible
onthe base of analyzing next Tx ID.
2. If you can find examples when current code is not able to provide consistent snapshot of running (out of
interest)transactions let's think how to fix code. Untill then my example shows why we cannot move SInval lock
requestafter ReadNewTransactionId().
> I'd still like to change GetSnapshotData to read the nextXid before
> it acquires SInvalLock, though. If we did that, it'd be safe to make
> GetNewTransactionId be
>
> SpinAcquire(XidGenLockId);
> xid = nextXid++;
> SpinAcquire(SInvalLockId);
> MyProc->xid = xid;
> SpinRelease(SInvalLockId);
> SpinRelease(XidGenLockId);
>
> which is really necessary if you want to avoid assuming that
> TransactionIds can be fetched and stored atomically.
To avoid that assumption one should add per MyProc spinlock.
Vadim