Skip site navigation (1) Skip section navigation (2)

Re: Nested transactions

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Barry Lind <blind(at)xythos(dot)com>, simon(at)2ndquadrant(dot)com,Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Nested transactions
Date: 2004-06-17 01:58:42
Message-ID: 20040617015842.GB5925@dcc.uchile.cl (view raw or flat)
Thread:
Lists: pgsql-jdbcpgsql-patches
On Wed, Jun 16, 2004 at 09:36:33PM -0400, Bruce Momjian wrote:

> And consider this case:
> 
> 	BEGIN;
> 	...
> 	SAVEPOINT x;
> 	SELECT func_call();
> 	SELECT func_call();
> 	COMMIT;
> 
> Now if func_call has a savepoint, it is really nested because it can't
> know whether the savepoint X will be used to roll back, so its status is
> dependent on the status of X.  Now, if we used savepoints in func_call,
> what happens in the second function call when we define a savepoint with
> the same name?

Hm, that's a good question.  What happens if you define two savepoints
with the same name?  According to SQL2003, the previous savepoint "is
destroyed", but it's not clear to me whether this means rolling back all
of its changes or just forgetting it.  What's clear is that you can roll
back only to the latest one.

Also, in SQL2003 there can be multiple "savepoint levels".  I think for
a first implementation it would be fine if we had only one level.  It
would, wouldn't it?

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Estoy de acuerdo contigo en que la verdad absoluta no existe...
El problema es que la mentira sí existe y tu estás mintiendo" (G. Lama)


In response to

pgsql-patches by date

Next:From: Alvaro HerreraDate: 2004-06-17 02:01:17
Subject: Re: Nested transactions
Previous:From: Alvaro HerreraDate: 2004-06-17 01:44:00
Subject: Re: Nested transactions

pgsql-jdbc by date

Next:From: Alvaro HerreraDate: 2004-06-17 02:01:17
Subject: Re: Nested transactions
Previous:From: Alvaro HerreraDate: 2004-06-17 01:44:00
Subject: Re: Nested transactions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group