| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Rahila Syed <rahilasyed90(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Enhancing Memory Context Statistics Reporting |
| Date: | 2026-01-14 13:32:36 |
| Message-ID: | edtgos7lfl5corqtarukyqkk4ok5a4as23gggbetjs26ohvybu@yzciht4c3m3e |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2026-01-14 08:26:24 -0500, Robert Haas wrote:
> On Tue, Jan 13, 2026 at 4:47 PM Andres Freund <andres(at)anarazel(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2026-01-14 13:56:36 | Re: Segmentation fault on proc exit after dshash_find_or_insert |
| Previous Message | Robert Haas | 2026-01-14 13:26:24 | Re: Enhancing Memory Context Statistics Reporting |