From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, bharath(dot)rupireddyforpostgres(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module |
Date: | 2022-04-29 19:18:15 |
Message-ID: | 20220429191815.xewxjlpmq7mxhsr2@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2020-12-16 18:12:39 +0900, Fujii Masao wrote:
> - /* Wait to be signaled by UnpinBuffer() */
> + /*
> + * Wait to be signaled by UnpinBuffer().
> + *
> + * We assume that only UnpinBuffer() and the timeout requests established
> + * above can wake us up here. WakeupRecovery() called by walreceiver or
> + * SIGHUP signal handler, etc cannot do that because it uses the different
> + * latch from that ProcWaitForSignal() waits on.
> + */
> ProcWaitForSignal(PG_WAIT_BUFFER_PIN);
>
> /*
Isn't this comment bogus? The latch could e.g. be set by
procsignal_sigusr1_handler(), which the startup process uses. Or it could
already be set, when entering ResolveRecoveryConflictWithBufferPin().
Why is it even relevant that we only get woken up by UnpinBuffer()?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-04-29 19:31:50 | Re: fix cost subqueryscan wrong parallel cost |
Previous Message | David G. Johnston | 2022-04-29 19:06:58 | Re: fix cost subqueryscan wrong parallel cost |