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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Nikolay Samokhvalov <nik(at)postgres(dot)ai>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: recovery.signal not cleaned up when both signal files are present
Date: 2026-02-09 23:37:10
Message-ID: aYpvppdC7yVtxviQ@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jelte Fennema-Nio 2026-02-09 23:55:56 Re: libpq: Bump protocol version to version 3.2 at least until the first/second beta
Previous Message Peter Geoghegan 2026-02-09 23:14:27 Problems with get_actual_variable_range's VISITED_PAGES_LIMIT