Re: Remove Deprecated Exclusive Backup Mode

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: Remove Deprecated Exclusive Backup Mode
Дата
Msg-id CAHGQGwHgF15OUB-gN+xtHRTp2=8r0Z+ZwARqE51-Ts3ywXcUuA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Remove Deprecated Exclusive Backup Mode  (Laurenz Albe <laurenz.albe@cybertec.at>)
Ответы Re: Remove Deprecated Exclusive Backup Mode  (Stephen Frost <sfrost@snowman.net>)
Re: Remove Deprecated Exclusive Backup Mode  (David Steele <david@pgmasters.net>)
Список pgsql-hackers
On Wed, Feb 27, 2019 at 4:35 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>
> Fujii Masao wrote:
> > So, let me clarify the situations;
> >
> > (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
>
> That's where I see the problem with your idea.
>
> It is fairly easy for someone to restore a backup and then just start
> the server without first creating "recovery.signal", and that would
> lead to data corruption.

Isn't this case problematic even when a backup was taken by pg_basebackup?
Because of lack of recovery.signal, no archived WAL files are replayed and
the database may not reach to the latest point.

Regards,

-- 
Fujii Masao


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

Предыдущее
От: Alexander Kuzmenkov
Дата:
Сообщение: Re: Optimze usage of immutable functions as relation
Следующее
От: Joe Conway
Дата:
Сообщение: Re: Row Level Security − leakproof-ness and performance implications