Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module

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

In response to

Browse pgsql-hackers by date

  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