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

Re: Nested Transactions, Abort All

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Thomas Swan <tswan(at)idigx(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Nested Transactions, Abort All
Date: 2004-07-02 19:38:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Jul 02, 2004 at 01:37:46PM -0500, Thomas Swan wrote:
> Alvaro Herrera wrote:

> >>Then again, since a statement is always transactionally wrapped, would
> >>it be required to always issue SUBBEGIN if issued from within a
> >>function?  This would address my concern.
> Isn't this counterintuitive.   It seems that BEGIN and COMMIT/ABORT 
> should be sufficient regardless of the level.  If you are inside a 
> current transaction those commands start a new transaction inside of the 
> current transaction level, just like pushing on and popping off elements 
> on a stack.  

No, the first level is quite different from any other, and that's why it
should use a different syntax.  Really any level above level 1 is not a
transaction at all; it's a unit that you can rollback independently but
nothing more; you can't commit it independently.  I think a better term
than "subtransaction" or "nested transaction" is "rollback unit" or some

> Some functions and procedures may not be called inside of transactions  
> or subtransactions.

No.  Some functions cannot be called inside a transaction block.
Whether you are or not inside a subtransaction within the transaction
block is not important.  In fact, the application doesn't care what
nesting level it is in; the only thing that it cares about is if it is
in a transaction block or not.

Please note that I'm using the term "transaction block" and not
"transaction."  The distinction is important because everything is
always inside a transaction, though it may be an implicit one.  A
transaction block, on the other hand, is always an explicit thing.
And a subtransaction is also an explicit thing.

> Unless you have some way to tell (by query) the state you are in is a 
> subtransaction and how many levels you are deep into the nested 
> transaction, deciding whether to use SUBBEGIN and SUBCOMMIT/SUBABORT vs 
> the traditional BEGIN COMMIT/ABORT becomes nondeterministic.

The application always has to keep track if it is inside a transaction
block or not.  This has always been true and it continues to be so.
Whether you are inside a subtransaction or not is not really important.
If you want to commit the whole transaction block just issue COMMIT, and
all levels will be committed.  Similarly if you want to abort.  But if
you want to retry a subtransaction which has just failed you better know
whether you are on a subtransaction or not ... I mean if the app
doesn't know that then it isn't using subtransactions, is it?

Knowing just the nesting level will not help you -- the app has to know
_what_ to retry.  And if it isn't going to retry anything then there's
no point in using subtransactions at all.

Alvaro Herrera (<alvherre[a]>)
"Cuando mañana llegue pelearemos segun lo que mañana exija" (Mowgli)

In response to


pgsql-hackers by date

Next:From: Thomas SwanDate: 2004-07-02 20:32:12
Subject: Re: Nested Transactions, Abort All
Previous:From: Mike MascariDate: 2004-07-02 19:33:34
Subject: Re: Nested Transactions, Abort All

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