Re: [PATCHES] Static snapshot data

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