Re: Resetting recovery target parameters in pg_createsubscriber
Вложения
В списке pgsql-hackers по дате отправления:
| От | Michael Paquier |
|---|---|
| Тема | Re: Resetting recovery target parameters in pg_createsubscriber |
| Дата | |
| Msg-id | aS_Gi_7pACVcg0sX@paquier.xyz обсуждение |
| Ответ на | Re: Resetting recovery target parameters in pg_createsubscriber (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: Resetting recovery target parameters in pg_createsubscriber
|
| Список | pgsql-hackers |
On Wed, Nov 19, 2025 at 02:49:29PM -0500, Robert Haas wrote: > On Thu, Nov 13, 2025 at 7:46 AM Alena Vinter <dlaaren8@gmail.com> wrote: >> The root cause is that `pg_createsubscriber` leaves behind recovery >> parameters that interfere with the new standby's startup process, >> causing recovery to stop before reaching a consistency point. > > Yes, I agree this is a much better scenario to test. Thanks. 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. -- Michael
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера