Re: Nested Transactions, Abort All - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Nested Transactions, Abort All
Date
Msg-id 200407061537.i66FbIl04451@candle.pha.pa.us
Whole thread Raw
In response to Re: Nested Transactions, Abort All  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Responses Re: Nested Transactions, Abort All  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
List pgsql-hackers
Alvaro Herrera wrote:
> On Sat, Jul 03, 2004 at 02:32:44AM -0500, Thomas Swan wrote:
> > Alvaro Herrera wrote:
> 
> > >What I'd like to do is start the transaction block before the function
> > >is called if we are not in a transaction block.  This would mean that
> > >when the function calls BEGIN it won't be the first one -- it will
> > >actually start a subtransaction and will be able to end it without harm.
> > >I think this can be done automatically at the SPI level.
> >
> > Please tell me there is some sanity in this.   If I follow you
> > correctly, at no point should anyone be able to issue an explicit
> > begin/end because they are already in an explicit/implicit transaction
> > by default...  How is the user/programmer to know when this is the case?
> 
> I'm not sure I understand you.  Of course you can issue begin/end.  What
> you can't do is issue begin/end inside a function -- you always use
> subbegin/subcommit in that case.

And if you use SUBBEGIN/SUBCOMMIT in a function that isn't already call
inside from an explicit transaction, it will work because the call
itself is its own implicit transaction, right?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: client_min_messages in dumps?
Next
From: Robert Treat
Date:
Subject: investigating deadlocks