Date: Fri, 29 Apr 2022 12:18:15 -0700
From: Andres Freund <andres@anarazel.de>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	bharath.rupireddyforpostgres@gmail.com,
	pgsql-hackers@postgresql.org
Subject: Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module
Message-ID: <20220429191815.xewxjlpmq7mxhsr2@alap3.anarazel.de>
References: <ce414f11-1418-511c-c840-a3cdd7f2b232@oss.nttdata.com>
 <6b561c73-27ce-7079-b6e5-440e49653810@oss.nttdata.com>
 <d8c0c608-021b-3c73-fffd-3240829ee986@oss.nttdata.com>
 <20201216.162459.1543880840255001035.horikyota.ntt@gmail.com>
 <68571154-5bd5-dc00-1322-92bbf92de806@oss.nttdata.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <68571154-5bd5-dc00-1322-92bbf92de806@oss.nttdata.com>
Archived-At: <https://www.postgresql.org/message-id/20220429191815.xewxjlpmq7mxhsr2%40alap3.anarazel.de>
Precedence: bulk

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