Re: Static snapshot data - Mailing list pgsql-hackers
From | Alvaro Herrera |
---|---|
Subject | Re: Static snapshot data |
Date | |
Msg-id | 20030517231425.GA4208@dcc.uchile.cl Whole thread Raw |
In response to | Re: Static snapshot data (Manfred Koizar <mkoi-pg@aon.at>) |
Responses |
Re: Static snapshot data
Re: Static snapshot data |
List | pgsql-hackers |
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@dcc.uchile.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 transactionis 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)
pgsql-hackers by date: