Re: recovery modules

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: recovery modules
Date: 2023-03-16 01:10:51
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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 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]

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).

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Yuya Watari 2023-03-16 01:30:57 Re: Making empty Bitmapsets always be NULL
Previous Message Michael Paquier 2023-03-16 01:05:52 Re: Fix fseek() detection of unseekable files on WIN32