Re: backup_label in a crash recovery

>>>>> "Albe" == "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)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)