Re: Use of signal-unsafe functions from signal handlers

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

In response to

Responses

Browse pgsql-bugs by date

  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