Re: SSI implementation question

On Wed, Oct 19, 2011 at 04:36:41PM -0400, Tom Lane wrote:
> No, the intention of the synchronized-snapshots feature is just to be
> able to start multiple transactions using exactly the same snapshot.
> They're independent after that.  The aspect of it that is worrying me
> is that if xact A starts, gets a snapshot and publishes it, and then
> xact B starts and wants to adopt that snapshot, then
> 
> (2) as things stand, xact A need not be running in serializable mode ---
> if B is serializable, does *that* break any assumptions?

[taking these in opposite order]

Yes, I think that's going to be a problem. The obvious case where it's
clearly not going to work is if A is older than the oldest active
serializable xact (i.e. SxactGlobalXmin would have to move backwards).
It's probably possible to make it work when that's not the case, but I
think it's better to require A to be serializable -- if nothing else,
it's a far simpler rule to document!

There is another case that could be problematic, if A was READ ONLY,
and B isn't. It sounds to me like that would also be a reasonable thing
to forbid.

> (1) other transactions may have started or ended meanwhile; does that
> break any of SSI's assumptions?

Mostly, no, if A is still running. There's one case that needs to be
handled a bit carefully, but shouldn't be a problem: if A was
SERIALIZABLE READ ONLY, and its snapshot was found to be safe, then
it's actually running (safely) at REPEATABLE READ. If we start a new
read-only transaction at the same snapshot, we need to make it run at
REPEATABLE READ if it requests SERIALIZABLE.

> We already have to have an interlock to ensure that GlobalXmin doesn't
> go backwards, by means of requiring A to still be running at the instant
> B adopts the snapshot and sets its MyProc->xmin accordingly.  However,
> there is not currently anything that guarantees that A is still running
> by the time B does GetSerializableTransactionSnapshotInt, shortly later.
> So if your answer to question (1) involves an assumption that A is still
> running, we're going to have to figure out how to arrange that without
> deadlocking on ProcArrayLock vs SerializableXactHashLock.

Yep, I think we're going to have to do that. I haven't had a chance to
look at the synchronized snapshots patch yet, so I can't (yet) offer
any suggestions about how to implement it.

> Which might
> be another good reason for changing predicate.c so that we don't hold
> the latter while taking a snapshot ...

It'd be great if we could do that, but I don't really see it being
possible...

Dan

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