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

Re: Nested Transactions, Abort All

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Mike Benoit <ipso(at)snappymail(dot)ca>
Cc: Thomas Swan <tswan(at)idigx(dot)com>,PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Nested Transactions, Abort All
Date: 2004-07-02 01:56:02
Message-ID: 20040702015602.GA17121@dcc.uchile.cl (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Jul 01, 2004 at 04:47:09PM -0700, Mike Benoit wrote:
> On Thu, 2004-07-01 at 18:38 -0400, Alvaro Herrera wrote:
> > On Thu, Jul 01, 2004 at 02:01:37PM -0500, Thomas Swan wrote:

> > If we change the syntax, say by using SUBCOMMIT/SUBABORT for
> > subtransactions, then using a simple ABORT would abort the whole
> > transaction tree.
> 
> But then we're back to the application having to know if its in a
> regular transaction or a sub-transaction aren't we? To me that sounds
> just as bad. 

I don't get it.  You want to argue that the application should be
ignorant of whether it was in a transaction or not?

What I am saying is that independent of what the current nesting level
is, issuing ABORT would close all open subtransactions, close (roll
back) the main transaction too, and return to the default
not-in-a-transaction state.

Of course, issuing a single COMMIT would also commit all open
subtransactions and the main transaction too.

In contrast, issuing SUBCOMMIT or SUBABORT would commit/abort only the
current subtransaction.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Ellos andaban todos desnudos como su madre los parió, y también las mujeres,
aunque no vi más que una, harto moza, y todos los que yo vi eran todos
mancebos, que ninguno vi de edad de más de XXX años" (Cristóbal Colón)


In response to

pgsql-hackers by date

Next:From: Christopher Kings-LynneDate: 2004-07-02 02:05:57
Subject: Re: Adding column comment to information_schema.columns
Previous:From: Scott MarloweDate: 2004-07-02 01:26:21
Subject: Re: Quick question regarding tablespaces

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