Re: SSI implementation question

Dan Ports  wrote:
> I think it would be fairly sensible to push some of this into
> ProcArray, actually. The commit sequence numbers just involve
> assigning/incrementing a global counter when taking a snapshot and
> finishing a transaction -- that's not too much work, doesn't
> require any additional locking beyond ProcArrayLock, and isn't too
> tied to SSI. (I could imagine it being useful for other purposes,
> though I'm not going to make that argument too seriously without
> actually having one in mind.)
So far it sounds like we're on the same page.
> SxactGlobalXmin and WritableSxactCount are obviously more
> SSI-specific, but I think we can come up with something reasonable
> to do with them.
Agreed.
> The part that's harder is building the list of potential conflicts
> that's used to identify safe snapshots for r/o transactions. That
> (currently) has to happen atomically taking the snapshot.
That's not obvious to me; could you elaborate on the reasons?  If the
commit sequence number is incremented under cover of an existing
ProcArrayLock, and the current value is assigned to a snapshot under
cover of same, acquiring SerializableXactHashLock after we get the
snapshot seems to work for SxactGlobalXmin and WritableSxactCount,
AFAICS.
> We'll probably have to do this in some significantly different way,
> but I haven't quite worked out what it is yet.
Well, transaction startup needs some rearrangement, clearly.  So far
nothing fundamental has caught my attention beyond the commit
sequence number changes.
> On the bright side, if we can address these three issues, we
> shouldn't need to take SerializableXactHashLock at all when
> starting a transaction. (Realistically, we might have to take it or
> some other lock shared to handle one of them -- but I really want
> starting a serializable xact to not take any exclusive locks.)
Yeah, I don't see how we can avoid taking a LW lock to get a
serializable transaction which needs a SERIALIZABLEXACT set up, but
it might be possible and worthwhile to split the uses of
SerializableXactHashLock so that it's not such a hotspot.
-Kevin