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.a...@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
da...@pgmasters.net
