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

On Thu, Oct 20, 2011 at 07:33:59AM -0500, Kevin Grittner wrote:
> Dan Ports wrote:
> > 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.

Well, whenever a r/w transaction commits or aborts, we need to check
whether that caused any concurrent r/o transactions to have a
known-safe or unsafe snapshot. The way that happens now is that, when a
r/o transaction starts, it scans the list of r/w transactions and adds
a pointer to itself in their sxact->possibleUnsafeConflicts. When one
of them commits, it scans the list of possible conflicts and does the
appropriate thing.

That's not ideal because:

- it requires modifing another transaction's sxact when registering a
serializable transaction, so that means taking
SerializableXactHashLock exclusive.

- the set of concurrent transactions used to identify the possible
conflicts needs to match the one used to build the snapshot.
Otherwise, a transaction might commit between when the snapshot is
take and when we find possible conflicts. (Holding
SerializableXactHashLock prevents this.)

> 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.

Oh, right, one other problem is that the sxact free list is also
protected by SerializableXactHashLock, so allocating from it requires
locking. That one could be fixed by protecting it with its own lock, or
(better yet) eventually moving to a lock-free implementation.

In general, the contention problem is that SerializableXactHashLock
basically protects all SSI state except the predicate locks themselves
(notably, the dependency graph). This isn't partitioned at all, so
looking at or modifying a single sxact requires locking the whole
graph. I'd like to replace this with something finer-grained.

Dan

--
Dan R. K. Ports MIT CSAIL http://drkp.net/