Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group