Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> I don't think it makes sense to change the isolation level for a
> non-toplevel transaction. That is, if the topmost transaction is
> ISOLATION LEVEL SERIALIZABLE, all its child transactions will be. And
> if it's not, then there's no way to make its child transactions be so.
> Is there an objection to this idea?
I have a feeling that there might be some value in running a
SERIALIZABLE subtransaction inside a READ COMMITTED parent. Too tired
to come up with an example right now, though. I agree that the other
way 'round (READ COMMITTED inside SERIALIZABLE) would be a bad idea,
since it negates the fundamental premise of SERIALIZABLE.
> With "constant isolation" in mind, it's clear that the
> SerializableSnapshot is going to be constant for all transactions.
But ... your definition of the snapshot includes the list of successful
previous subtransactions of the parent. How's that static?
> And about QuerySnapshots: given some running transaction with a given
> QuerySnapshot, a newly created child transaction's first QuerySnapshot
> can be calculated easily as:
> - Xmin, Xmax and xip are the same as in the current implementation
> (i.e. the values from GetSnapshotData)
Not entirely sure about that in READ COMMITTED mode. Should a child
xact be able to see commits from other backends that happened before it
started, but after its parent started? I can think of arguments on both
sides ...
regards, tom lane