Re: recovery.signal not cleaned up when both signal files are present
Fujii Masao <masao.fujii@gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Nikolay Samokhvalov <nik@postgres.ai>,
pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-02-10T03:26:36Z
Lists: pgsql-hackers
Attachments
- v1-0001-Remove-recovery.signal-at-recovery-end-when-both-.patch (application/octet-stream) patch v1-0001
On Tue, Feb 10, 2026 at 8:37 AM Michael Paquier <michael@paquier.xyz> wrote: > > 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. +1 to apply this change only to the master branch. Patch attached. Regards, -- Fujii Masao
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