Re: [HACKERS] Reading backup label file for checkpoint and redolocation during crash recovery - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: [HACKERS] Reading backup label file for checkpoint and redolocation during crash recovery
Date
Msg-id CABUevEwj-CbFs1a-qAmGbYWvjKxibBn+EL1O2CeJDN6WOZFpvg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Reading backup label file for checkpoint and redolocation during crash recovery  (Stephen Frost <sfrost@snowman.net>)
Responses Re: [HACKERS] Reading backup label file for checkpoint and redolocation during crash recovery
List pgsql-hackers
On Mon, Sep 25, 2017 at 7:43 PM, Stephen Frost <sfrost@snowman.net> wrote:
Greetings Satya,

* Satyanarayana Narlapuram (Satyanarayana.Narlapuram@microsoft.com) wrote:
> During crash recovery, last checkpoint record information is obtained from the backup label if present, instead of getting it from the control file. This behavior is causing PostgreSQL database cluster not to come up until the backup label file is deleted (as the error message says).
>
> if (checkPoint.redo < checkPointLoc)
>                       {
>                              if (!ReadRecord(xlogreader, checkPoint.redo, LOG, false))
>                                     ereport(FATAL,
>                                                   (errmsg("could not find redo location referenced by checkpoint record"),
>                                                   errhint("If you are not restoring from a backup, try removing the file \"%s/backup_label\".", DataDir)));
>                       }
>
> If we are recovering from a dump file, reading from the backup label files makes sense as the control file could be archived after a few checkpoints. But this is not the case for crash recovery, and is always safe to read the checkpoint record information from the control file.
> Is this behavior kept this way as there is no clear way to distinguish between the recovery from the dump and the regular crash recovery?

This is why the exclusive backup method has been deprecated in PG10 in
favor of the non-exclusive backup method, which avoids this by not
creating a backup label file (it's up to the backup software to store
the necessary information and create the file for use during recovery).


Actally, it was deprecated already in 9.6, not just 10.


--

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Built-in plugin for logical decoding output
Next
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] psql \d sequence display