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

From Bruce Momjian
Subject Re: Nested Transactions, Abort All
Date
Msg-id 200407110025.i6B0PGK19342@candle.pha.pa.us
Whole thread Raw
In response to Re: Nested Transactions, Abort All  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Nested Transactions, Abort All  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Re: Nested Transactions, Abort All  (Dennis Bjorklund <db@zigo.dhs.org>)
Re: Nested Transactions, Abort All  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
Josh Berkus wrote:
> > Well, that involves either creating a conditional capability in the
> > backend, or in psql, neither of which will happen for 7.5.  The best we
> > can do is allow COMMIT NESTED INGORE ERROR (or COMMIT NESTED INGORE
> > ROLLBACK) and just let the script keep going. I am thinking of cases
> > where you want to drop an object you aren't sure exists in a
> > transaction.  Anything more complicated like issuing a replacement query
> > will have to wait for 7.6.
> 
> OK, I didn't realize that it was a difficult thing.   I think it should go on 
> the TODO list but you are the judge of what's a quick fix and what's not.
> 
> (BTW, aside from this limitation, I am *not* in favor of COMMIT NESTED IGNORE 
> ERROR)

OK, no one likes that idea, so let's forget it.

Do we want to allow BEGIN NESTED to start a main transaction?  Oracle
can use SAVEPOINTS all the time because it knows it is always in a
transaction, but PostgreSQL is not always.  I don't see a downside to
allowing it.  COMMIT will still commit the entire transaction, of
course.

--  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: [PATCHES] nested xacts and phantom Xids
Next
From: "Scott Marlowe"
Date:
Subject: Re: Nested Transactions, Abort All