Re: Nested Transactions, Abort All

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)