Re: backup_label in a crash recovery - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: backup_label in a crash recovery
Date
Msg-id 873a4vfynl.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: backup_label in a crash recovery  ("Albe Laurenz" <laurenz.albe@wien.gv.at>)
Responses Re: backup_label in a crash recovery
Re: backup_label in a crash recovery
List pgsql-hackers
>>>>> "Albe" == "Albe Laurenz" <laurenz.albe@wien.gv.at> writes:
Albe> Removing postmaster.pid can lead to a corrupt database.Albe> Removing backup_label means that one of your backups
willgoAlbe> wrong, and a subsequent pg_stop_backup() will throw an error.
 
Albe> If you have a cluster failover during an online backup, I thinkAlbe> any reasonable person would suspect that the
backupwent wrong.Albe> And if nothing else does, the error on pg_stop_backup() willAlbe> tell you.[...]Albe> Is there a
flawin 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)


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: EOL for 7.4?
Next
From: Heikki Linnakangas
Date:
Subject: Re: new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)