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

Re: Nested transactions

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Barry Lind <blind(at)xythos(dot)com>
Cc: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>,Simon Riggs <simon(at)2ndquadrant(dot)com>,Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Nested transactions
Date: 2004-06-17 22:01:49
Message-ID: 200406172201.i5HM1ns22285@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-jdbcpgsql-patches
> The problem I see with moving towards supporting savepoints with the 
> current proposal is with how commit works:
> 
> Consider:
> 
> begin;
>   	insert into foo values (1);
>   	savepoint dammit;
>   	insert into foo values (2);
>   	select foo;
>   	insert into foo values (3);
> commit;
> 
> This one commit needs to commit the top level transaction.  But if the 
> savepoint command is really starting a sub transaction then that commit 
> would only commit the subtransaction not the top level transaction.  I 
> don't see how you can use COMMIT to sometimes mean commit the 
> subtransaction and other times have it mean commit the top level 
> transaction.
> 
> I don't have a problem with the under the covers functionality in this 
> patch, it is how begin/commit are changed to support the underlying 
> functionality that concerns me.  IMHO we should not change the behavior 
> of begin/commit for nested transactions (leave them do what they have 
> always done - i.e. control the top level transaction state), but 
> introduce new syntax for subtransactions control.

Well, because their was only one BEGIN, the commit commits all open
subtransactions.  The code will have to track the number of BEGIN's used
and will have to roll all savepoints into the next commit.  However, it
is only the commit that matches the outermost begin that has this
behavior. Consider this:

> begin;
>   	insert into foo values (1);
>       savepoint aa;
>       begin;
>   	savepoint dammit;
>   	insert into foo values (2);
>       commit;
>   	select foo;
>       rollback dammit;
>       rollback aa;
>   	insert into foo values (3);
> commit;

OK, the inner commit does not close the aa subtransaction.  One big
question is whether it closes the dammit subtransaction.  And is
rollback to aa valid (I think so), and what about rollback dammit, which
was defined in a subtransaction (I think we have to disallow that).

Did I make a mistake by promoting subtransactions rather than
savepoints?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

Responses

pgsql-patches by date

Next:From: Alvaro HerreraDate: 2004-06-18 01:33:28
Subject: nested xacts and phantom Xids
Previous:From: Simon RiggsDate: 2004-06-17 21:19:24
Subject: Re: Nested transactions

pgsql-jdbc by date

Next:From: Kris JurkaDate: 2004-06-17 22:02:23
Subject: JDK 1.5 beta2 and generics
Previous:From: Paul BalanoiuDate: 2004-06-17 21:48:02
Subject: Re: jar file with 7.3.6 postgresql?

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