Re: Reading backup label file for checkpoint and redo location during crash recovery

From: Andres Freund <andres(at)anarazel(dot)de>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Satyanarayana Narlapuram <Satyanarayana(dot)Narlapuram(at)microsoft(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reading backup label file for checkpoint and redo location during crash recovery
Date: 2017-09-25 17:48:38
Message-ID: 20170925174838.7oi6mvymm7bhyrmw@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2017-09-25 13:43:32 -0400, Stephen Frost wrote:
> Greetings Satya,
>
> * Satyanarayana Narlapuram (Satyanarayana(dot)Narlapuram(at)microsoft(dot)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).
>
> Please see:
>
> https://www.postgresql.org/docs/10/static/continuous-archiving.html
>
> In particular, section 25.3.3.

Might not be obvious for the more casual contributor:

And even before then, using pg_basebackup / the streaming replication
protocol version of creating a base backup, it was avoided.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2017-09-25 17:50:13 Re: logical replication and statistics
Previous Message Tom Lane 2017-09-25 17:47:04 Re: Server crash due to SIGBUS(Bus Error) when trying to access the memory created using dsm_create().