Re: Remove Deprecated Exclusive Backup Mode

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Remove Deprecated Exclusive Backup Mode
Дата
Msg-id CA+Tgmoa_fJXnrh1jwnJ_=Xwkmy2md7m7xSKtxut3XEY6hyUs-g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Remove Deprecated Exclusive Backup Mode  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: Remove Deprecated Exclusive Backup Mode  (Christophe Pettus <xof@thebuild.com>)
Re: Remove Deprecated Exclusive Backup Mode  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-hackers
On Tue, Feb 26, 2019 at 12:20 PM Fujii Masao <masao.fujii@gmail.com> wrote:
> So, let me clarify the situations;
>
> (1) If backup_label and recovery.signal exist, the recovery starts safely.
>        This is the normal case of recovery from the base backup.
>
> (2)If backup_label.pending and recovery.signal exist, as described above,
>        PANIC error happens at the start of recovery. This case can happen
>        if the operator forgets to rename backup_label.pending, i.e.,
>        operation mistake. So, after PANIC, the operator needs to fix her or
>        his mistake (i.e., rename backup_label.pending) and restart
>        the recovery.
>
> (3) If backup_label.pending exists but recovery.signal doesn't, the server
>        ignores (or removes) backup_label.pending and do the recovery
>        starting the pg_control's REDO location. This case can happen if
>        the server crashes while an exclusive backup is in progress.
>        So crash-in-the-middle-of-backup doesn't prevent the recovery from
>        starting in this idea.

The if-conditions for 1 and 2 appear to be the same, which is confusing.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: ATTACH/DETACH PARTITION CONCURRENTLY
Следующее
От: Noah Misch
Дата:
Сообщение: Re: No-rewrite timestamp<->timestamptz conversions