Re: Basic subtransaction facility

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Manfred Koizar <mkoi-pg(at)aon(dot)at>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Basic subtransaction facility
Date: 2004-04-29 20:03:10
Message-ID: 20040429200309.GF4503@dcc.uchile.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

On Thu, Apr 29, 2004 at 06:42:31PM +0200, Manfred Koizar wrote:
> On Wed, 28 Apr 2004 12:02:44 -0400, Alvaro Herrera
> <alvherre(at)dcc(dot)uchile(dot)cl> wrote:
> >In fact, I think we should mark ERROR as aborting the whole transaction
> >tree, and create a new level which would abort the innermost
> >subtransaction. We would then change whatever is appropiate to the new
> >elevel. Doing otherwise would leave us open to unexpected conditions
> >causing only subtrans abort, which could lead to unreliable behavior.
>
> Why? Subtransaction commit propagates an error state to the parent
> transaction. And if a subtransaction is rolled back the parent can
> continue cleanly no matter what was the reason for the subtrans abort.

Not necessarily; consider can't-happen conditions, like everything that
is marked elog(ERROR) rather than ereport(ERROR). Corrupt hashes,
should-exist catalog entries that are not there, etc. They should not
be frequent, be we should be prepared for them.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"La virtud es el justo medio entre dos defectos" (Aristóteles)

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Alvaro Herrera 2004-04-29 20:04:10 Re: Basic subtransaction facility
Previous Message Tom Lane 2004-04-29 19:17:32 Re: SECURITY DEFINER not being propagated...