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 по дате отправления: