Re: Nested Transactions, Abort All

From: Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
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 09:26:45
Message-ID: Pine.LNX.4.44.0407071100150.2838-100000@zigo.dhs.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 7 Jul 2004, Oliver Jowett wrote:

> > 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.

If you translate it directly using only the primitives of the current
subbegin/subabort, yes. But that is not the only way to implement it. And
even if that was the first implementation due to not having time to make
it better before 7.5, then I still prefer a standard syntax that can be
improved then a non standard feature to be maintained for all future.

This is about the API to present to the user. The savepoint syntax is
standard, if we should invent our own way it should be for some real
benefit.

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

Yes, it does. But surely they can be nested so an inner use of name foo
hides an outer use of name foo. I'm not pretending to know all about the
standard savepoints, so I just assume they can be nested.

> 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,

So you do not want to use the standard syntax in order to save some tokens
in the source?

Also notice that the first and last statement is the same no matter if you
want to rollback or not. So it would be something like (with a nicer
savepoint name then yours):

SAVEPOINT insert;

INSERT INTO ....

... possible more work ...

if (some_error)
ROLLBACK TO SAVEPOINT insert;

RELEASE SAVEPOINT insert;

I really don't see this as anything ugly with this. Maybe it doesn't fit
the current implementation, then lets change the implementation and not
just make an extension that fits a implementation.

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

I'd like to use the ansi standard and hopefully portable syntax. I don't
see any real gains by having our own syntax. If the goal is just to save
some tokens I definetly see no reason. There might still be something more
to subtransactions, but I really have not seen it.

At the very least if we add extensions I would like to have a clear and
stated reason why it should be used instead of the standard feature. Every
time we add some syntax it has to be maintained forever and we lock in
users into postgresql. Something I don't like.

--
/Dennis Björklund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yannick Lecaillez 2004-07-07 10:39:34 Re: Postgresql on SAN
Previous Message Oliver Jowett 2004-07-07 08:59:45 Re: Nested Transactions, Abort All