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
Message-ID: ZBJsm6pw85FXpYFS@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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 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

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