Re: Resetting recovery target parameters in pg_createsubscriber
| От | Robert Haas |
|---|---|
| Тема | Re: Resetting recovery target parameters in pg_createsubscriber |
| Дата | |
| Msg-id | CA+TgmoaveCRuuBA86K_ieW5vk0gPb2x-FDmm=K3e1YMV=7bPcw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Resetting recovery target parameters in pg_createsubscriber (Michael Paquier <michael@paquier.xyz>) |
| Список | pgsql-hackers |
On Wed, Dec 3, 2025 at 12:11 AM Michael Paquier <michael@paquier.xyz> wrote: > Robert, does this line of arguments address the concerns you had > upthread? Or do you still see a reason why not cleaning up these > recovery parameters would not be a good idea? > > I don't see a strong need for a backpatch here as the approach I have > mentioned with a secondary configuration file, and an > include_if_exists would be a kind of design change for the tool > itself. So this would qualify as a HEAD-only thing, if of course > you wouldd agree with the change to clean up the recovery parameters. As I see it, there's no bug here, because I don't think we've made any promise to the user that they don't need to check what recovery parameters are configured before running recovery. However, your proposal seems like it could make life more convenient for users, which seems like a good thing to do. The revised test case doesn't, in my opinion, represent a scenario that absolutely has to work without user intervention, but it's nicer if it does. So, I would see committing this as a feature improvement but not back-patching it as a reasonable way forward. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: