Re: Nested Transactions, Abort All - Mailing list 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
AFAICT.

> 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]dcc.uchile.cl>)
"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)