Re: Static snapshot data

On Fri, May 16, 2003 at 07:12:31PM +0200, Manfred Koizar wrote:
> On Thu, 15 May 2003 19:39:55 -0400, Alvaro Herrera
> <alvherre(at)dcc(dot)uchile(dot)cl> wrote:

> >The user can
> >change from READ COMMITTED to SERIALIZABLE when starting a
> >subtransaction, but not the other way around.
>
> You cannot propose this and agree to my three rules at the same time.
> Rule 3 says that these two sequences of commands are equivalent:
> [example]

I see. Then I don't fully agree with your rules. Let's say I find that
the rules are very good guidelines, but they fail WRT the isolation
level, which is a special exception.

> What we *do* need is a saved_isolation_level on the transaction
> information stack, so we can restore the state of the enclosing
> transaction on subtransaction ROLLBACK (the same is true for
> changeable GUC variables):

Yes, I think it will be necessary to keep the isolation level state in
the transaction state stack.

I'm not sure how are SET changes supposed to work. In fact, I don't
know how the rollback of such is implemented currently. If there is
some static variable around for each GUC variable, there's probably
something to be done about this. I don't know yet, but I bet it's going
to be a real PITA.

> fred=# BEGIN;
> BEGIN
> fred=# SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
> SET
> fred=# SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
> SET
> fred=# SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
> SET
> fred=# SELECT version();
> version
> -------------------------------------------------------------
> PostgreSQL 7.3 on i586-pc-linux-gnu, compiled by GCC 2.95.2
> (1 row)
>
> fred=# SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
> ERROR: SET TRANSACTION ISOLATION LEVEL must be called before any
> query

Well, this is what I meant: the transaction isolation level is
changeable to SERIALIZABLE only if:

- There has been no command in the current transaction(*), and
- I am the topmost transaction, or
- my parent transaction is READ COMMITTED

And the transaction isolation level is changeable to READ COMMITTED only
if there has been no command in the current transaction, and I am the
topmost transaction. This should be necessary only for the cases where
the default transaction isolation level is serializable.

(*) should be a test equivalent to the current
SerializableSnapshot == NULL

> >We need to check the CurrentCommandId only if xmin (or xmax) is my own
> >XID.
>
> This sounds good as long as queries are issued by a client application
> one after the other. But will it still work when we have
> subtransactions in functions?

Oh, you are right. I was thinking that changing the test to be
"xmin/xmax should be lesser than my current XID", but that also fails.
We'll have to continue incrementing CommandIds inside the transaction
tree.

> >Hm, why do you want to left out the startTime and startTimeUsec?
>
> I thought they're useless ...

Maybe they are. I don't really care much about them either.

> Maybe the term "nested transactions" is confusing. I'm starting to
> believe that my position is better described by "multiple savepoints".
> Are we still talking about the same thing?

The only difference so far is in the isolation level changeability
issue, I think. So yes, we are still talking the same.

I was thinking (much earlier, back in the days I started looking for a
useful project) that savepoints could be implementable on top of nested
transactions by means of having "named subtransactions", with special
commands like "COMMIT/ROLLBACK TO subxact-name".

But there are a lot of things to do before nested transactions become a
reality. For example there is need to abort any transaction, including
possible subtransactions, in the case of deadlock. How is this supposed
to be? Do we abort the whole transaction tree? Do we abort only the
branch of the tree that has the needed locks? I haven't even read the
deadlock code.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Nunca confiaré en un traidor. Ni siquiera si el traidor lo he creado yo"
(Barón Vladimir Harkonnen)