Hi, On 2026-01-14 08:26:24 -0500, Robert Haas wrote: > On Tue, Jan 13, 2026 at 4:47 PM Andres Freund <[email protected]> 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
