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 →
-
Remove recovery.signal at recovery end when both signal files are present.
- 351265a6c7fd 19 (unreleased) landed