Re: Requiring recovery.signal or standby.signal when recovering with a backup_label

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Requiring recovery.signal or standby.signal when recovering with a backup_label
Дата
Msg-id ZUiQVHtIKF72s3fJ@paquier.xyz
обсуждение исходный текст
Ответ на Re: Requiring recovery.signal or standby.signal when recovering with a backup_label  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список pgsql-hackers
On Thu, Nov 02, 2023 at 11:03:35AM +0900, Kyotaro Horiguchi wrote:
> At Wed, 1 Nov 2023 08:39:17 +0900, Michael Paquier <michael@paquier.xyz> 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Compiling warnings on old GCC
Следующее
От: "Andrey M. Borodin"
Дата:
Сообщение: Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock