| 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: | Whole Thread | Raw Message | 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 |