Re: Nested Transactions, Abort All

Oliver Jowett <oliver@opencloud.com>

From: Oliver Jowett <oliver@opencloud.com>
To: Dennis Bjorklund <db@zigo.dhs.org>
Cc: Alvaro Herrera <alvherre@dcc.uchile.cl>, Thomas Swan <tswan@idigx.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2004-07-07T08:59:45Z
Lists: pgsql-hackers
Dennis Bjorklund wrote:
> On Wed, 7 Jul 2004, Oliver Jowett wrote:
> 
> 
>>So how do you propose supporting simple rollback of a subtransaction? It 
>>seems like an extension regardless of how it's done.
> 
> 
> If I understand you correctly what you want is a ROLLBACK TO SAVEPOINT
> foo; followed by a RELEASE SAVEPOINT foo; 

Ugh.. nasty syntax and an extra empty transaction.

Also, how do you get an anonymous subtransaction? SAVEPOINT syntax would 
seem to always require a name.

One of the use cases for subtransactions was to avoid rollback of the 
entire transaction if there's an error in a single command -- you wrap 
each command in a subtransaction and roll it back if it fails. If we 
only have SAVEPOINT syntax this looks like:

   -- Success case
   SAVEPOINT s_12345
    INSERT INTO foo(...) VALUES (...)
   RELEASE SAVEPOINT s_12345

   -- Error case
   SAVEPOINT s_12346
    INSERT INTO foo(...) VALUES (...)
   ROLLBACK TO SAVEPOINT s_12346
   RELEASE SAVEPOINT s_12346

   -- Repeat ad nauseam

This is pretty ugly. Given that the underlying mechanism is nested 
subtransactions, why should it be necessary to jump through those sort 
of hoops to gain access to them?

If you don't like adding extra commands, what about extending the 
standard transaction control commands ("BEGIN NESTED" etc) instead?

-O