From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | Mats Kindahl <mats(at)timescale(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Use of signal-unsafe functions from signal handlers |
Date: | 2022-05-24 14:15:55 |
Message-ID: | 1531973.1653401755@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Julien Rouhaud <rjuju123(at)gmail(dot)com> writes:
> Yes, but it's using ereport with FATAL level, so if it's the top level message
> the ErrorContext should be in initial state or have been reset previously, and
> if it's not then the escape hatch will reset the context. So in any case there
> will be a guarantee to have at least 8kB available in that context, that any
> palloc will be able to use to format the message.
ereport() itself is just the tip of the iceberg; even if it's safe
(which I concur it isn't), there's also the atexit/on_proc_exit
functions that are likely to be called during shutdown. So yeah,
this coding is not too safe. I'm not sure that getting rid of it
would be a net win though, as we'd replace it-might-crash hazards
with it-might-never-exit hazards, from bgworkers that neglect to
respond to ShutdownRequestPending.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2022-05-24 16:17:35 | BUG #17495: Regression in 15beta1 when filtering subquery including row_number window function |
Previous Message | Julien Rouhaud | 2022-05-24 12:37:39 | Re: Use of signal-unsafe functions from signal handlers |