Re: Fatal Errors - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fatal Errors
Date
Msg-id 13379.1222704897@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fatal Errors  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Fatal Errors  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> * Might we make AbortTransaction critical just as far as the
> END_CRIT_SECTION after XLogInsert in RecordTransactionAbort(), but no
> further? Don't expect yes, but seems worth recording thoughts.

The problem is that pretty much everything that proc_exit runs would
have to become critical, AFAICS.  And a lot of that code is explicitly
intended not to be critical --- that's why we split it up into multiple
proc_exit callbacks.  If one fails we pick up with the next, after a
recursive call to elog().

In any case it is clear that there will be failure cases where an
abort record cannot be written --- out of disk space for WAL being
one obvious example.  Are we sure that we can, or want to, guarantee
that those all result in PANIC?  (We do already PANIC on out of disk
space for WAL, but I'm not so sure about generalizing that to any
possible failure.)

>> Thought you were trying to get rid of the shutdown checkpoint during
>> restart?

> Yes, but if I do there would still be a WAL record of some kind there to
> allow us to confirm the change of tli.

> Anyway, I thought you wanted me to keep it now?

No, I don't have a strong opinion one way or the other on that bit.
But an ordinary crash and restart shouldn't generate a tli change.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: Ad-hoc table type?
Next
From: Simon Riggs
Date:
Subject: Re: Fatal Errors