Re: recovery modules
От | Michael Paquier |
---|---|
Тема | Re: recovery modules |
Дата | |
Msg-id | ZBJsm6pw85FXpYFS@paquier.xyz обсуждение исходный текст |
Ответ на | Re: recovery modules (Nathan Bossart <nathandbossart@gmail.com>) |
Список | pgsql-hackers |
On Tue, Mar 14, 2023 at 09:13:09PM -0700, Nathan Bossart wrote: > However, that's not what happens when hot_standby is off. In that case, > the postmaster.pid file is updated with PM_STATUS_STANDBY once recovery > starts, which wait_for_postmaster_start() interprets as "ready." I see > this was reported before [0], but that discussion fizzled out. IIUC it was > done this way to avoid infinite waits when hot_standby is off and standby > mode is enabled. I could be missing something obvious, but that doesn't > seem necessary when hot_standby is off and recovery mode is enabled because > recovery should end at some point (never mind the halting problem). I'm > still digging into this and may spin off a new thread if I can conjure up a > proposal. > > [0] https://postgr.es/m/CAMkU%3D1wrMqPggnEfszE-c3PPLmKgRK17_qr7tmxBECYEbyV-4Q%40mail.gmail.com These days, knowing hot_standby is on by default, and that users would recover up to the end-of-backup record of just use read replicas, do we have a strong case for keeping this GUC parameter at all? It does not strike me that we really need to change a five-year-old behavior if there has been few complaints about it. I agree that it is confusing as it stands, but the long-term simplifications may be worth it in the recovery code (aka less booleans needed to track the flow of the startup process, and less confusion around that). -- Michael
Вложения
В списке pgsql-hackers по дате отправления: