Re: Resetting recovery target parameters in pg_createsubscriber

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Resetting recovery target parameters in pg_createsubscriber
Дата
Msg-id CA+TgmobejeFqAWZaHe6-gzpMQdQSuMSDm4ra=tmFvj6UdaAvvw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Resetting recovery target parameters in pg_createsubscriber  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Wed, Oct 8, 2025 at 7:43 AM Michael Paquier <michael@paquier.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



В списке pgsql-hackers по дате отправления: