Re: Remove Deprecated Exclusive Backup Mode
От | Bruce Momjian |
---|---|
Тема | Re: Remove Deprecated Exclusive Backup Mode |
Дата | |
Msg-id | 20190304223609.fdat5vdsadpe6b7n@momjian.us обсуждение исходный текст |
Ответ на | Re: Remove Deprecated Exclusive Backup Mode (David Steele <david@pgmasters.net>) |
Ответы |
Re: Remove Deprecated Exclusive Backup Mode
|
Список | pgsql-hackers |
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()? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
В списке pgsql-hackers по дате отправления: