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. Indeed, if I didn't know much about databases and were faced with the task of restoring a PostgreSQL database from backup in a hurry, that is probably what I would do. Having thought some about the whole problem area, I believe that there is no safe way to disambiguate a backup from a server crashed in backup mode. The non-exclusive backup mode actually suffers from a similar problem --- if you don't add "backup_label" to the backup afterwards, it will lead to database corruption. The only fool-proof tool we have in core is pg_basebackup. Any really good backup solution that wishes to integrate with a third- party backup tool will have to get that tool to include "backup_label" with the backup itself. For that, it would need to know the contents of "backup_label" *before* pg_stop_backup(). Is there a good reason why it is pg_stop_backup() and not pg_start_backup() that provides that information? Yours, Laurenz Albe
