Re: Remove Deprecated Exclusive Backup Mode
От | David Steele |
---|---|
Тема | Re: Remove Deprecated Exclusive Backup Mode |
Дата | |
Msg-id | 064e4032-4e5d-8b17-0a71-0a0868e60949@pgmasters.net обсуждение исходный текст |
Ответ на | Re: Remove Deprecated Exclusive Backup Mode (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
On 3/5/19 12:36 AM, Bruce Momjian wrote: > On Thu, Feb 28, 2019 at 05:08:24PM +0200, David Steele wrote: >> On 2/28/19 4:44 PM, Fujii Masao wrote: >>> 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. >> >> It is problematic because we have a message encouraging users to delete >> backup_label when in fact they should be creating recovery.signal. > > Should we issue a client NOTICE/WARNING message as part of > pg_start_backup to indicate what to do if the server crashes before > pg_stop_backup()? I'm not in favor of this since it will just encourage users to change their log level and possibly miss important notices/warnings. Regards, -- -David david@pgmasters.net
В списке pgsql-hackers по дате отправления: