"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> 1.1 For this case acquiring SInval lock before ReadNewTransactionId()
> changes behavior of Tx Old: it postpones change of Tx Old'
> (and Tx New') MyProc->xid in xact.c:CommitTransaction(), so Tx S
> will see Tx Old as running, ie Tx Old' changes will be invisible
> to Tx S on the base of analyzing MyProc.xid-s, just like Tx New'
> changes will be invisible on the base of analyzing next Tx ID.
Oh, now I get it: the point is to prevent Tx Old from exiting the set
of "still running" xacts as seen by Tx S. Okay, it makes sense.
I'll try to add some documentation to explain it.
Given this, I'm wondering why we bother with having a separate
XidGenLock spinlock at all. Why not eliminate it and use SInval
spinlock to lock GetNewTransactionId and ReadNewTransactionId?
What did you think about reordering the vacuum qual tests and
AbortTransaction sequence?
BTW, I'm starting to think that it would be really nice if we could
replace our spinlocks with not just a semaphore, but something that has
a notion of "shared" and "exclusive" lock requests. For example,
if GetSnapshotData could use a shared lock on SInvalLock, it'd
improve concurrency.
regards, tom lane