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 21:30:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Jul 02, 2004 at 03:32:12PM -0500, Thomas Swan wrote:
> Alvaro Herrera wrote:
> >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.
> This is the reason the outermost block is irrelevant to the point.  
> Inner transactions (including the implicit ones mentioned) commit only 
> if their parent transactions commit.   If there is an implicit 
> begin/commit, then everything underneath should be subbegin/subcommit.   
> If it is sometimes implicit then the subbegin/begin state is 
> non-deterministic.   Without the underlying or stack depth, it is 
> difficult to predict.

You can't have subtransactions inside an implicit transaction block, so
this answers all your concerns here I think.  It just doesn't make
sense.  How would you call a subtransaction in a implicit transaction?
Don't tell me to use BEGIN because that'd start an explicit transaction
block ...

> In psql, autocommit (on/off) behavoir becomes a little muddy if you go
> with the SUBBEGIN and SUBCOMMIT construct.

Au contraire ... autocommit is easier to support with separate syntax

> psql will tell me how deep I am in transactions?

Yes, there should be a way to know this, if only for showing it in the
prompt.  It's not there at present.

> >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?
> That's an rather big assumption?  It may not be the app, it may include 
> stored procedures and functions as well.

I said in some other thread that a function can not call BEGIN, only
SUBBEGIN (there is a reason besides this one, and it is that it just
doesn't work to use BEGIN in a function when not in a transaction block
-- you can try it with current sources).

At this point you can claim that in this case you would not be able to
call a function that uses subtransactions when not in a transaction
block; that's why we need to automatically start a transaction block to
call a function, if not already in one.

> If you have the nesting level, then you know how many commits/rollbacks 
> to perform to get to an entrance state.

Why bother?  Just issue one and you are done.

Alvaro Herrera (<alvherre[a]>)
"El sentido de las cosas no viene de las cosas, sino de
las inteligencias que las aplican a sus problemas diarios
en busca del progreso." (Ernesto Hernández-Novich)

In response to


pgsql-hackers by date

Next:From: Jeroen T. VermeulenDate: 2004-07-02 21:51:01
Subject: Re: Nested Transactions, Abort All
Previous:From: Robert TreatDate: 2004-07-02 21:03:19
Subject: Re: working on support triggers on columns

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