public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Kyotaro Horiguchi <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Subject: Re: Requiring recovery.signal or standby.signal when recovering with a backup_label
Date: Mon, 6 Nov 2023 16:05:56 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<CA+TgmoYmWhN4u4zxmdYciaHJZdqkGKzpn==sbSOeRP8PJFSvoA@mail.gmail.com>
<[email protected]>
<[email protected]>
On Thu, Nov 02, 2023 at 11:03:35AM +0900, Kyotaro Horiguchi wrote:
> At Wed, 1 Nov 2023 08:39:17 +0900, Michael Paquier <[email protected]> wrote in
>> See in StartupXLOG(), around the comment "complain if we did not roll
>> forward far enough to reach". This complains if archive recovery has
>> been requested *or* if we retrieved a backup end LSN from the
>> backup_label.
>
> Please note that backupStartPoint is not reset even when reaching the
> backup end point during crash recovery. If backup_label enforces
> archive recovery, I think this point won't be an issue as you
> mentioned. For the record, my earlier proposal aimed to detect
> reaching the end point even during crash recovery.
Good point. Not doing ReachedEndOfBackup() at the end of crash
recovery feels inconsistent, especially since we care about some of
these fields in this case.
If a .signal file is required when we read a backup_label, yes that
would not be a problem because we'd always link backupEndPoint's
destiny with a requested archive recovery, but there seem to be little
love for enforcing that based on the feedback of this thread, so..
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../[email protected]/2-signature.asc)
download
view thread (2+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Requiring recovery.signal or standby.signal when recovering with a backup_label
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox