Re: Nested Transactions, Abort All

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: Thomas Swan <tswan(at)idigx(dot)com>, Andreas Pflug <pgadmin(at)pse-consulting(dot)de>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Nested Transactions, Abort All
Date: 2004-07-09 19:03:36
Message-ID: 1089399815.17493.597.camel@stromboli
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2004-07-09 at 16:47, Alvaro Herrera wrote:
> On Fri, Jul 09, 2004 at 10:38:15AM -0500, Thomas Swan wrote:
>
> > visibility issue and how far do you unwind the depth of subtransactions
> > or transactions?
> >
> > BEGIN
> > UPDATE A
> > SAVEPOINT X
> > BEGIN
> > BEGIN
> > UPDATE B
> > BEGIN
> > UPDATE C
> > ROLLBACK TO SAVEPOINT X
>
> What happens here is that the user will go nuts. We will have a
> prominent entry in the docs: "using both nested transactions and
> savepoints inside a transaction can cause confusion. We recommend you
> stick to one or the other." Or something like that.
>
> (What would really happen: when ROLLBACK TO SAVEPOINT X is executed,
> nested transactions created after the SAVEPOINT will be closed.)
>
> So this is another reason why we should use COMMIT to close a nested
> transaction: it may refer to a transaction that is already closed
> because the user got confused.

Agreed.

Could we put two modes of operation in?
i.e. if you use SAVEPOINTs/ROLLBACK TO SAVEPOINT, then you're not
allowed to use nested transactions (and vice versa - so they are
mutually exclusive)...

Best Regards, Simon Riggs

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dennis Bjorklund 2004-07-09 19:07:58 Re: Nested Transactions, Abort All
Previous Message Simon Riggs 2004-07-09 18:56:05 Re: PITR Redo Create Database fails