Lakshmi Narayana Velayudam writes:
> Just as an info for future readers, it is indeed a bug for two reasons
No, it isn't. There's twenty years' worth of successful usage of
the old coding pattern that says you're wrong.
regards, tom lane
On Thu, Aug 22, 2024 at 9:50 PM Tom Lane wrote:
>
> > The previous postmaster coding blocked signals
> > everywhere except immediately around the main loop's select() call,
> > so there wasn't any real hazard of signal handlers interrupting
> > anything of concern. We redid it for cleanliness, n
Lakshmi Narayana Velayudam writes:
> My Bad Nathan, was looking at PG 11, 14 codes. Just to be sure, calling
> *ProcessConfigFile *is a bug from a signal handler is a bug, right?
No, it was not. The previous postmaster coding blocked signals
everywhere except immediately around the main loop's s
On Thu, Aug 22, 2024 at 8:46 PM Nathan Bossart
wrote:
>
> > I think this is no longer true as of v16, thanks to commit 7389aad [0].
>
My Bad Nathan, was looking at PG 11, 14 codes. Just to be sure, calling
*ProcessConfigFile *is a bug from a signal handler is a bug, right? Since
it uses AllocSet
On Thu, Aug 22, 2024 at 05:37:13PM +0530, Lakshmi Narayana Velayudam wrote:
> Later I have seen almost
> all postgresql processes/bgworkers use signal handler to set a
> variable *ConfigReloadPending
> *which will later be read in main code to process guc changes but for
> postmaster *ProcessConfig
Hi pgsql hacker,
Recently I have been trying to understand why GUC changes will be visible
even though they are done in the signal handler as part of
*ProcessConfigfile* (done in some extension code). Later I have seen almost
all postgresql processes/bgworkers use signal handler to set a
variable
