Re: Resetting recovery target parameters in pg_createsubscriber

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Alena Vinter <dlaaren8(at)gmail(dot)com>, Ilyasov Ian <ianilyasov(at)outlook(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Resetting recovery target parameters in pg_createsubscriber
Date: 2025-10-14 18:04:22
Message-ID: CA+TgmobejeFqAWZaHe6-gzpMQdQSuMSDm4ra=tmFvj6UdaAvvw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 8, 2025 at 7:43 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> With all that in mind, I came
> up with the following solution, which is able to fix what you want to
> address (aka not load any of the recovery parameters written by the
> tool if you reactivate a standby with a new signal file), while also
> satisfying my condition, which is to keep a track of the parameters
> written.

I'd like to back up one more step: why do we think that this is even a
valid scenario in the first place? The original scenario involves
running pg_createsubscriber and then putting the server back into
recovery mode. But why is it valid to just put the server back into
recovery mode at that point? That doesn't seem like something that you
can just go do and expect it to work, especially if you don't check
that other parameters have the values that you want. Generally,
recovery is a one-time event, and once you exit, you only reenter on a
newly-taken backup or after a crash or a pg_rewind. There are, of
course, other times when you can force a server back into recovery
without anything bad happening, but it's not my impression that we
support that in general; it's something you can choose to do as an
expert operator if you are certain that it's OK in your scenario.

So my question is: why should we do anything at all about this?

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2025-10-14 18:09:43 Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
Previous Message Greg Burd 2025-10-14 17:46:01 Re: Expanding HOT updates for expression and partial indexes