Re: recovery.signal not cleaned up when both signal files are present

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Nikolay Samokhvalov <nik@postgres.ai>, pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-02-09T23:37:10Z
Lists: pgsql-hackers
On Tue, Feb 10, 2026 at 12:41:48AM +0900, Fujii Masao wrote:
> +1 on also cleaning up recovery.signal when both signal files are present.
> 
> The documentation states that standby.signal takes precedence if both
> files exist,
> and this configuration is not described as unacceptable. So, it doesn't seem ok
> to prevent the server from starting in this case.

If both are present, startup should be OK and we should be in standby
mode.  Like reported, it really sounds like a problem to me to enforce
unnecessary TLI jumps because a recovery.signal is still around after
a standby promotion.  So, yes, removing it would be a good thing.
However I would argue against a backpatch as there is a risk of
slightly breaking existing recovery flows as well.  Doing such a 
change like that on HEAD is OK.  This area of the code has always been
really sensitive to deal with in stable branches, particularly slight
changes in recovery behavior that could damage deployments (aka
monitoring) after a minor version upgrade.
--
Michael

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Remove recovery.signal at recovery end when both signal files are present.