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

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 →
  1. Remove recovery.signal at recovery end when both signal files are present.