Re: Use of signal-unsafe functions from signal handlers - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Use of signal-unsafe functions from signal handlers
Date
Msg-id 1531973.1653401755@sss.pgh.pa.us
Whole thread Raw
In response to Re: Use of signal-unsafe functions from signal handlers  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: Use of signal-unsafe functions from signal handlers
List pgsql-bugs
Julien Rouhaud <rjuju123@gmail.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



pgsql-bugs by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Use of signal-unsafe functions from signal handlers
Next
From: PG Bug reporting form
Date:
Subject: BUG #17495: Regression in 15beta1 when filtering subquery including row_number window function