Bruce Momjian <pgman@candle.pha.pa.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
