Re: Basic subtransaction facility

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

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Manfred Koizar wrote:
>> 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.

> I think his point was that there are some errors that should abort the
> outer transaction too. I think Alvaro mentioned out of memory, but that
> is a FATAL error.

Nonsense. In the first place, out-of-memory hasn't been FATAL for
years. In the second, there is no reason to think that we can't
continue the outer transaction(s), as aborting the innermost one is
likely to free quite a lot of memory. (And if it doesn't, well, the
outer one will get its own out-of-memory ERROR soon enough.)

In general I tend to agree with Manfred's point: if you have reason to
suspect global corruption of a backend's state then you should do FATAL
(or possibly PANIC). If you do not suspect this then you ought to just
ERROR. I do not see the use-case for abort-all-levels-of-xact-but-
don't-exit.

regards, tom lane

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2004-04-29 19:17:32 Re: SECURITY DEFINER not being propagated...
Previous Message Peter Eisentraut 2004-04-29 17:29:07 Re: Basic subtransaction facility