Re: Nested Transactions, Abort All

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org>
Cc: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Thomas Swan <tswan(at)idigx(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Nested Transactions, Abort All
Date: 2004-07-07 08:59:45
Message-ID: 40EBBB81.9030707@opencloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dennis Bjorklund 2004-07-07 09:26:45 Re: Nested Transactions, Abort All
Previous Message Dennis Bjorklund 2004-07-07 08:39:53 Re: Nested Transactions, Abort All