| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| 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-10 03:26:36 |
| Message-ID: | CAHGQGwGkwXMmL802fUH=P09bNZBtBwNhbutA+KFxObZPPMQQvQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Feb 10, 2026 at 8:37 AM Michael Paquier <michael(at)paquier(dot)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
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Remove-recovery.signal-at-recovery-end-when-both-.patch | application/octet-stream | 2.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-02-10 03:56:51 | Re: Add expressions to pg_restore_extended_stats() |
| Previous Message | jian he | 2026-02-10 03:05:07 | Re: jsonb subscripting vs SQL/JSON array accessor semantics (SQL:2023) |