>>>>> "Albe" == "Albe Laurenz" <laurenz.a...@wien.gv.at> writes:
Albe> Removing postmaster.pid can lead to a corrupt database. Albe> Removing backup_label means that one of your backups will go Albe> wrong, and a subsequent pg_stop_backup() will throw an error. Albe> If you have a cluster failover during an online backup, I think Albe> any reasonable person would suspect that the backup went wrong. Albe> And if nothing else does, the error on pg_stop_backup() will Albe> tell you. [...] Albe> Is there a flaw in my reasoning? Yes. Imagine the following scenario: the system crashed while pg_start_backup was in effect (so backup_label exists), and the postmaster is about to start up. i.e. you're at the point where you might naively imagine that you can delete the backup_label. How do you distinguish between these two scenarios: 1) you're starting up in a data dir where you crashed in the middle of a backup 2) you're starting up in a data dir that is a restore of a base backup, but no recovery.conf has been created (hint: you can't) If in scenario 2, you remove the backup_label and proceed with recovery, there is a significant chance (depending on the timing, and if you didn't exclude pg_xlog from the backup) that recovery will _think_ it succeeds but actually leaves you with a corrupt data directory. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
