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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers