Hi,
On 2026-01-14 08:26:24 -0500, Robert Haas wrote:
> On Tue, Jan 13, 2026 at 4:47 PM Andres Freund <andres@anarazel.de> wrote:
> > I'm pretty sure that doesn't generally happen. There's promotion to FATAL if
> > the top-level sigsetjmp() hasn't yet run (c.f. the check for
> > PG_exception_stack in errstart()), but once it has been reached, it stays
> > configured.
>
> All right, then I guess I don't fully understand how the
> error-outside-of-a-transaction case is handled.
For those we just rely on the error cleanup inside the top-level sigsetmp()
blocks... Which of course is a pretty random subset of cleanups that also
differs between process types, which is quite ... not great.
> But I still think that
> code like this needs to run in a transaction to avoid unexpected and
> undesirable results. Do you see it differently?
I'm waffling on it a bit, tbh. I think doing it for something like backends it
could make sense, but e.g. for something like checkpointer, that normally
never runs a transaction, it seems like a bad idea. Mainly because processes
that don't run transactions won't have an AbortCurrentTransaction() or such in
their top-level sigsetjmp() and thus would never abort the transaction that we
started, if there were an error while doing the reporting.
Greetings,
Andres Freund
