Rename backup_label to recovery_control
Hackers,
I was recently discussing the complexities of dealing with pg_control
and backup_label with some hackers at PGConf NYC, when David Christensen
commented that backup_label was not a very good name since it gives the
impression of being informational and therefore something the user can
delete. In fact, we see this happen quite a lot, and there have been
some other discussions about it recently, see [1]/messages/by-id/1330cb48-4e47-03ca-f2fb-b144b49514d8@pgmasters.net and [2]/messages/by-id/CAM_vCudkSjr7NsNKSdjwtfAm9dbzepY6beZ5DP177POKy8=2aw@mail.gmail.com. I bounced the
idea of a rename off various hackers at the conference and in general
people seemed to think it was a good idea.
Attached is a patch to rename backup_label to recovery_control. The
purpose is to make it more obvious that the file should not be deleted.
I'm open to other names, e.g. recovery.control. That makes the naming
distinct from tablespace_map, which is perhaps a good thing, but is also
more likely to be confused with recovery.signal.
I did a pretty straight-forward search and replace on comments and
documentation with only light editing. If this seems like a good idea
and we choose a final name, I'll do a more thorough pass through the
comments and docs to try and make the usage more consistent.
Note that there is one usage of backup label that remains, i.e. the text
that the user can set to describe the backup.
Regards,
-David
[1]: /messages/by-id/1330cb48-4e47-03ca-f2fb-b144b49514d8@pgmasters.net
/messages/by-id/1330cb48-4e47-03ca-f2fb-b144b49514d8@pgmasters.net
[2]: /messages/by-id/CAM_vCudkSjr7NsNKSdjwtfAm9dbzepY6beZ5DP177POKy8=2aw@mail.gmail.com
/messages/by-id/CAM_vCudkSjr7NsNKSdjwtfAm9dbzepY6beZ5DP177POKy8=2aw@mail.gmail.com
Attachments:
v01-rename-backup-label-to-recovery-control.patchtext/plain; charset=UTF-8; name=v01-rename-backup-label-to-recovery-control.patchDownload
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 8cb24d6ae54..958755f9eee 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -937,7 +937,7 @@ SELECT * FROM pg_backup_stop(wait_for_archive => true);
<para>
<function>pg_backup_stop</function> will return one row with three
values. The second of these fields should be written to a file named
- <filename>backup_label</filename> in the root directory of the backup. The
+ <filename>recovery_control</filename> in the root directory of the backup. The
third field should be written to a file named
<filename>tablespace_map</filename> unless the field is empty. These files are
vital to the backup working and must be written byte for byte without
@@ -1062,7 +1062,7 @@ SELECT * FROM pg_backup_stop(wait_for_archive => true);
</para>
<para>
- The backup label
+ The recovery control
file includes the label string you gave to <function>pg_backup_start</function>,
as well as the time at which <function>pg_backup_start</function> was run, and
the name of the starting WAL file. In case of confusion it is therefore
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index affd1254bb7..b4f158606cd 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -26763,12 +26763,12 @@ LOG: Grand total: 1651920 bytes in 201 blocks; 622360 free (88 chunks); 1029560
</optional> )
<returnvalue>record</returnvalue>
( <parameter>lsn</parameter> <type>pg_lsn</type>,
- <parameter>labelfile</parameter> <type>text</type>,
+ <parameter>recoveryctlfile</parameter> <type>text</type>,
<parameter>spcmapfile</parameter> <type>text</type> )
</para>
<para>
Finishes performing an on-line backup. The desired contents of the
- backup label file and the tablespace map file are returned as part of
+ recovery control file and the tablespace map file are returned as part of
the result of the function and must be written to files in the
backup area. These files must not be written to the live data directory
(doing so will cause PostgreSQL to fail to restart in the event of a
@@ -26803,7 +26803,7 @@ LOG: Grand total: 1651920 bytes in 201 blocks; 622360 free (88 chunks); 1029560
The result of the function is a single record.
The <parameter>lsn</parameter> column holds the backup's ending
write-ahead log location (which again can be ignored). The second
- column returns the contents of the backup label file, and the third
+ column returns the contents of the recovery control file, and the third
column returns the contents of the tablespace map file. These must be
stored as part of the backup and are required as part of the restore
process.
diff --git a/doc/src/sgml/ref/pg_rewind.sgml b/doc/src/sgml/ref/pg_rewind.sgml
index 8e0000d39fb..4af18dae589 100644
--- a/doc/src/sgml/ref/pg_rewind.sgml
+++ b/doc/src/sgml/ref/pg_rewind.sgml
@@ -400,7 +400,7 @@ GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text, bigint, bigint, b
<filename>pg_serial/</filename>, <filename>pg_snapshots/</filename>,
<filename>pg_stat_tmp/</filename>, and <filename>pg_subtrans/</filename>
are omitted from the data copied from the source cluster. The files
- <filename>backup_label</filename>,
+ <filename>recovery_control</filename>,
<filename>tablespace_map</filename>,
<filename>pg_internal.init</filename>,
<filename>postmaster.opts</filename>, and
@@ -410,7 +410,7 @@ GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text, bigint, bigint, b
</step>
<step>
<para>
- Create a <filename>backup_label</filename> file to begin WAL replay at
+ Create a <filename>recovery_control</filename> file to begin WAL replay at
the checkpoint created at failover and configure the
<filename>pg_control</filename> file with a minimum consistency LSN
defined as the result of <literal>pg_current_wal_insert_lsn()</literal>
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index c0e4ca50899..510168fb280 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -5199,8 +5199,8 @@ StartupXLOG(void)
/*
* Prepare for WAL recovery if needed.
*
- * InitWalRecovery analyzes the control file and the backup label file, if
- * any. It updates the in-memory ControlFile buffer according to the
+ * InitWalRecovery analyzes the control file and the recovery_control file,
+ * if any. It updates the in-memory ControlFile buffer according to the
* starting checkpoint, and sets InRecovery and ArchiveRecoveryRequested.
* It also applies the tablespace map file, if any.
*/
@@ -5349,7 +5349,7 @@ StartupXLOG(void)
UpdateControlFile();
/*
- * If there was a backup label file, it's done its job and the info
+ * If there was a recovery control file, it's done its job and the info
* has now been propagated into pg_control. We must get rid of the
* label file so that if we crash during recovery, we'll pick up at
* the latest recovery restartpoint instead of going all the way back
@@ -5358,8 +5358,8 @@ StartupXLOG(void)
*/
if (haveBackupLabel)
{
- unlink(BACKUP_LABEL_OLD);
- durable_rename(BACKUP_LABEL_FILE, BACKUP_LABEL_OLD, FATAL);
+ unlink(RECOVERY_CONTROL_OLD);
+ durable_rename(RECOVERY_CONTROL_FILE, RECOVERY_CONTROL_OLD, FATAL);
}
/*
@@ -5512,7 +5512,7 @@ StartupXLOG(void)
* backup-from-replica (which can't inject records into the WAL stream),
* that point is when we reach the minRecoveryPoint in pg_control (which
* we purposefully copy last when backing up from a replica). For
- * pg_rewind (which creates a backup_label with a method of "pg_rewind")
+ * pg_rewind (which creates a recovery_control with a method of "pg_rewind")
* or snapshot-style backups (which don't), backupEndRequired will be set
* to false.
*
diff --git a/src/backend/access/transam/xlogbackup.c b/src/backend/access/transam/xlogbackup.c
index 21d68133ae1..8a046b4ed48 100644
--- a/src/backend/access/transam/xlogbackup.c
+++ b/src/backend/access/transam/xlogbackup.c
@@ -18,10 +18,10 @@
#include "access/xlogbackup.h"
/*
- * Build contents for backup_label or backup history file.
+ * Build contents for recovery_control or backup history file.
*
* When ishistoryfile is true, it creates the contents for a backup history
- * file, otherwise it creates contents for a backup_label file.
+ * file, otherwise it creates contents for a recovery_control file.
*
* Returns the result generated as a palloc'd string.
*/
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 45a70668b1c..5089bc44d0b 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -53,7 +53,7 @@ static MemoryContext backupcontext = NULL;
* pg_backup_start: set up for taking an on-line backup dump
*
* Essentially what this does is to create the contents required for the
- * backup_label file and the tablespace map.
+ * recovery_control file and the tablespace map.
*
* Permission checking for this function is managed through the normal
* GRANT system.
@@ -113,13 +113,14 @@ pg_backup_start(PG_FUNCTION_ARGS)
* allows the user to choose if they want to wait for the WAL to be archived
* or if we should just return as soon as the WAL record is written.
*
- * This function stops an in-progress backup, creates backup_label contents and
- * it returns the backup stop LSN, backup_label and tablespace_map contents.
+ * This function stops an in-progress backup, creates recovery_control contents
+ * and it returns the backup stop LSN, recovery_control and tablespace_map
+ * contents.
*
- * The backup_label contains the user-supplied label string (typically this
+ * recovery_control contains the user-supplied label string (typically this
* would be used to tell where the backup dump will be stored), the starting
* time, starting WAL location for the dump and so on. It is the caller's
- * responsibility to write the backup_label and tablespace_map files in the
+ * responsibility to write recovery_control and tablespace_map files in the
* data folder that will be restored from this backup.
*
* Permission checking for this function is managed through the normal
@@ -133,7 +134,7 @@ pg_backup_stop(PG_FUNCTION_ARGS)
Datum values[PG_BACKUP_STOP_V2_COLS] = {0};
bool nulls[PG_BACKUP_STOP_V2_COLS] = {0};
bool waitforarchive = PG_GETARG_BOOL(0);
- char *backup_label;
+ char *recovery_control;
SessionBackupState status = get_backup_status();
/* Initialize attributes information in the tuple descriptor */
@@ -152,15 +153,15 @@ pg_backup_stop(PG_FUNCTION_ARGS)
/* Stop the backup */
do_pg_backup_stop(backup_state, waitforarchive);
- /* Build the contents of backup_label */
- backup_label = build_backup_content(backup_state, false);
+ /* Build the contents of recovery_control */
+ recovery_control = build_backup_content(backup_state, false);
values[0] = LSNGetDatum(backup_state->stoppoint);
- values[1] = CStringGetTextDatum(backup_label);
+ values[1] = CStringGetTextDatum(recovery_control);
values[2] = CStringGetTextDatum(tablespace_map->data);
/* Deallocate backup-related variables */
- pfree(backup_label);
+ pfree(recovery_control);
/* Clean up the session-level state and its memory context */
backup_state = NULL;
diff --git a/src/backend/access/transam/xlogrecovery.c b/src/backend/access/transam/xlogrecovery.c
index becc2bda62e..fb6c43d7bd8 100644
--- a/src/backend/access/transam/xlogrecovery.c
+++ b/src/backend/access/transam/xlogrecovery.c
@@ -6,7 +6,7 @@
* This source file contains functions controlling WAL recovery.
* InitWalRecovery() initializes the system for crash or archive recovery,
* or standby mode, depending on configuration options and the state of
- * the control file and possible backup label file. PerformWalRecovery()
+ * the control file and possible recovery control file. PerformWalRecovery()
* performs the actual WAL replay, calling the rmgr-specific redo routines.
* FinishWalRecovery() performs end-of-recovery checks and cleanup actions,
* and prepares information needed to initialize the WAL for writes. In
@@ -152,10 +152,10 @@ static bool recovery_signal_file_found = false;
/*
* CheckPointLoc is the position of the checkpoint record that determines
- * where to start the replay. It comes from the backup label file or the
+ * where to start the replay. It comes from the recovery control file or the
* control file.
*
- * RedoStartLSN is the checkpoint's REDO location, also from the backup label
+ * RedoStartLSN is the checkpoint's REDO location, also from the recovery control
* file or the control file. In standby mode, XLOG streaming usually starts
* from the position where an invalid record was found. But if we fail to
* read even the initial checkpoint record, we use the REDO location instead
@@ -388,9 +388,10 @@ static void ApplyWalRecord(XLogReaderState *xlogreader, XLogRecord *record, Time
static void EnableStandbyMode(void);
static void readRecoverySignalFile(void);
static void validateRecoveryParameters(void);
-static bool read_backup_label(XLogRecPtr *checkPointLoc,
- TimeLineID *backupLabelTLI,
- bool *backupEndRequired, bool *backupFromStandby);
+static bool read_recovery_control(XLogRecPtr *checkPointLoc,
+ TimeLineID *backupLabelTLI,
+ bool *backupEndRequired,
+ bool *backupFromStandby);
static bool read_tablespace_map(List **tablespaces);
static void xlogrecovery_redo(XLogReaderState *record, TimeLineID replayTLI);
@@ -492,7 +493,7 @@ EnableStandbyMode(void)
* Prepare the system for WAL recovery, if needed.
*
* This is called by StartupXLOG() which coordinates the server startup
- * sequence. This function analyzes the control file and the backup label
+ * sequence. This function analyzes the control file and recovery control
* file, if any, and figures out whether we need to perform crash recovery or
* archive recovery, and how far we need to replay the WAL to reach a
* consistent state.
@@ -609,13 +610,13 @@ InitWalRecovery(ControlFileData *ControlFile, bool *wasShutdown_ptr,
replay_image_masked = (char *) palloc(BLCKSZ);
primary_image_masked = (char *) palloc(BLCKSZ);
- if (read_backup_label(&CheckPointLoc, &CheckPointTLI, &backupEndRequired,
- &backupFromStandby))
+ if (read_recovery_control(&CheckPointLoc, &CheckPointTLI,
+ &backupEndRequired, &backupFromStandby))
{
List *tablespaces = NIL;
/*
- * Archive recovery was requested, and thanks to the backup label
+ * Archive recovery was requested, and thanks to the recovery control
* file, we know how far we need to replay to reach consistency. Enter
* archive recovery directly.
*/
@@ -624,7 +625,7 @@ InitWalRecovery(ControlFileData *ControlFile, bool *wasShutdown_ptr,
EnableStandbyMode();
/*
- * When a backup_label file is present, we want to roll forward from
+ * When a recovery_control file is present, we want to roll forward from
* the checkpoint it identifies, rather than using pg_control.
*/
record = ReadCheckpointRecord(xlogprefetcher, CheckPointLoc,
@@ -641,7 +642,7 @@ InitWalRecovery(ControlFileData *ControlFile, bool *wasShutdown_ptr,
/*
* Make sure that REDO location exists. This may not be the case
* if there was a crash during an online backup, which left a
- * backup_label around that references a WAL segment that's
+ * recovery_control around that references a WAL segment that's
* already been archived.
*/
if (checkPoint.redo < CheckPointLoc)
@@ -652,8 +653,8 @@ InitWalRecovery(ControlFileData *ControlFile, bool *wasShutdown_ptr,
ereport(FATAL,
(errmsg("could not find redo location referenced by checkpoint record"),
errhint("If you are restoring from a backup, touch \"%s/recovery.signal\" and add required recovery options.\n"
- "If you are not restoring from a backup, try removing the file \"%s/backup_label\".\n"
- "Be careful: removing \"%s/backup_label\" will result in a corrupt cluster if restoring from a backup.",
+ "If you are not restoring from a backup, try removing the file \"%s/recovery_control\".\n"
+ "Be careful: removing \"%s/recovery_control\" will result in a corrupt cluster if restoring from a backup.",
DataDir, DataDir, DataDir)));
}
}
@@ -662,8 +663,8 @@ InitWalRecovery(ControlFileData *ControlFile, bool *wasShutdown_ptr,
ereport(FATAL,
(errmsg("could not locate required checkpoint record"),
errhint("If you are restoring from a backup, touch \"%s/recovery.signal\" and add required recovery options.\n"
- "If you are not restoring from a backup, try removing the file \"%s/backup_label\".\n"
- "Be careful: removing \"%s/backup_label\" will result in a corrupt cluster if restoring from a backup.",
+ "If you are not restoring from a backup, try removing the file \"%s/recovery_control\".\n"
+ "Be careful: removing \"%s/recovery_control\" will result in a corrupt cluster if restoring from a backup.",
DataDir, DataDir, DataDir)));
wasShutdown = false; /* keep compiler quiet */
}
@@ -707,14 +708,14 @@ InitWalRecovery(ControlFileData *ControlFile, bool *wasShutdown_ptr,
else
{
/*
- * If tablespace_map file is present without backup_label file, there
+ * If tablespace_map file is present without recovery_control file, there
* is no use of such file. There is no harm in retaining it, but it
* is better to get rid of the map file so that we don't have any
* redundant file in data directory and it will avoid any sort of
* confusion. It seems prudent though to just rename the file out of
* the way rather than delete it completely, also we ignore any error
* that occurs in rename operation as even if map file is present
- * without backup_label file, it is harmless.
+ * without recovery_control file, it is harmless.
*/
if (stat(TABLESPACE_MAP, &st) == 0)
{
@@ -722,13 +723,13 @@ InitWalRecovery(ControlFileData *ControlFile, bool *wasShutdown_ptr,
if (durable_rename(TABLESPACE_MAP, TABLESPACE_MAP_OLD, DEBUG1) == 0)
ereport(LOG,
(errmsg("ignoring file \"%s\" because no file \"%s\" exists",
- TABLESPACE_MAP, BACKUP_LABEL_FILE),
+ TABLESPACE_MAP, RECOVERY_CONTROL_FILE),
errdetail("File \"%s\" was renamed to \"%s\".",
TABLESPACE_MAP, TABLESPACE_MAP_OLD)));
else
ereport(LOG,
(errmsg("ignoring file \"%s\" because no file \"%s\" exists",
- TABLESPACE_MAP, BACKUP_LABEL_FILE),
+ TABLESPACE_MAP, RECOVERY_CONTROL_FILE),
errdetail("Could not rename file \"%s\" to \"%s\": %m.",
TABLESPACE_MAP, TABLESPACE_MAP_OLD)));
}
@@ -943,7 +944,7 @@ InitWalRecovery(ControlFileData *ControlFile, bool *wasShutdown_ptr,
if (dbstate_at_startup != DB_IN_ARCHIVE_RECOVERY &&
dbstate_at_startup != DB_SHUTDOWNED_IN_RECOVERY)
ereport(FATAL,
- (errmsg("backup_label contains data inconsistent with control file"),
+ (errmsg("recovery_control contains data inconsistent with control file"),
errhint("This means that the backup is corrupted and you will "
"have to use another backup for recovery.")));
ControlFile->backupEndPoint = ControlFile->minRecoveryPoint;
@@ -1147,27 +1148,27 @@ validateRecoveryParameters(void)
}
/*
- * read_backup_label: check to see if a backup_label file is present
+ * read_recovery_control: check to see if a recovery_control file is present
*
- * If we see a backup_label during recovery, we assume that we are recovering
+ * If we see recovery_control during recovery, we assume that we are recovering
* from a backup dump file, and we therefore roll forward from the checkpoint
* identified by the label file, NOT what pg_control says. This avoids the
* problem that pg_control might have been archived one or more checkpoints
* later than the start of the dump, and so if we rely on it as the start
* point, we will fail to restore a consistent database state.
*
- * Returns true if a backup_label was found (and fills the checkpoint
+ * Returns true if recovery_control was found (and fills the checkpoint
* location and TLI into *checkPointLoc and *backupLabelTLI, respectively);
- * returns false if not. If this backup_label came from a streamed backup,
- * *backupEndRequired is set to true. If this backup_label was created during
- * recovery, *backupFromStandby is set to true.
+ * returns false if not. If this recovery_control came from a streamed backup,
+ * *backupEndRequired is set to true. If this recovery_control was created
+ * during recovery, *backupFromStandby is set to true.
*
* Also sets the global variables RedoStartLSN and RedoStartTLI with the LSN
* and TLI read from the backup file.
*/
static bool
-read_backup_label(XLogRecPtr *checkPointLoc, TimeLineID *backupLabelTLI,
- bool *backupEndRequired, bool *backupFromStandby)
+read_recovery_control(XLogRecPtr *checkPointLoc, TimeLineID *backupLabelTLI,
+ bool *backupEndRequired, bool *backupFromStandby)
{
char startxlogfilename[MAXFNAMELEN];
TimeLineID tli_from_walseg,
@@ -1190,14 +1191,14 @@ read_backup_label(XLogRecPtr *checkPointLoc, TimeLineID *backupLabelTLI,
/*
* See if label file is present
*/
- lfp = AllocateFile(BACKUP_LABEL_FILE, "r");
+ lfp = AllocateFile(RECOVERY_CONTROL_FILE, "r");
if (!lfp)
{
if (errno != ENOENT)
ereport(FATAL,
(errcode_for_file_access(),
errmsg("could not read file \"%s\": %m",
- BACKUP_LABEL_FILE)));
+ RECOVERY_CONTROL_FILE)));
return false; /* it's not there, all is fine */
}
@@ -1210,14 +1211,14 @@ read_backup_label(XLogRecPtr *checkPointLoc, TimeLineID *backupLabelTLI,
&hi, &lo, &tli_from_walseg, startxlogfilename, &ch) != 5 || ch != '\n')
ereport(FATAL,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
- errmsg("invalid data in file \"%s\"", BACKUP_LABEL_FILE)));
+ errmsg("invalid data in file \"%s\"", RECOVERY_CONTROL_FILE)));
RedoStartLSN = ((uint64) hi) << 32 | lo;
RedoStartTLI = tli_from_walseg;
if (fscanf(lfp, "CHECKPOINT LOCATION: %X/%X%c",
&hi, &lo, &ch) != 3 || ch != '\n')
ereport(FATAL,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
- errmsg("invalid data in file \"%s\"", BACKUP_LABEL_FILE)));
+ errmsg("invalid data in file \"%s\"", RECOVERY_CONTROL_FILE)));
*checkPointLoc = ((uint64) hi) << 32 | lo;
*backupLabelTLI = tli_from_walseg;
@@ -1252,7 +1253,7 @@ read_backup_label(XLogRecPtr *checkPointLoc, TimeLineID *backupLabelTLI,
* Parse START TIME and LABEL. Those are not mandatory fields for recovery
* but checking for their presence is useful for debugging and the next
* sanity checks. Cope also with the fact that the result buffers have a
- * pre-allocated size, hence if the backup_label file has been generated
+ * pre-allocated size, hence if the recovery_control file has been generated
* with strings longer than the maximum assumed here an incorrect parsing
* happens. That's fine as only minor consistency checks are done
* afterwards.
@@ -1260,12 +1261,12 @@ read_backup_label(XLogRecPtr *checkPointLoc, TimeLineID *backupLabelTLI,
if (fscanf(lfp, "START TIME: %127[^\n]\n", backuptime) == 1)
ereport(DEBUG1,
(errmsg_internal("backup time %s in file \"%s\"",
- backuptime, BACKUP_LABEL_FILE)));
+ backuptime, RECOVERY_CONTROL_FILE)));
if (fscanf(lfp, "LABEL: %1023[^\n]\n", backuplabel) == 1)
ereport(DEBUG1,
(errmsg_internal("backup label %s in file \"%s\"",
- backuplabel, BACKUP_LABEL_FILE)));
+ backuplabel, RECOVERY_CONTROL_FILE)));
/*
* START TIMELINE is new as of 11. Its parsing is not mandatory, still use
@@ -1276,20 +1277,20 @@ read_backup_label(XLogRecPtr *checkPointLoc, TimeLineID *backupLabelTLI,
if (tli_from_walseg != tli_from_file)
ereport(FATAL,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
- errmsg("invalid data in file \"%s\"", BACKUP_LABEL_FILE),
+ errmsg("invalid data in file \"%s\"", RECOVERY_CONTROL_FILE),
errdetail("Timeline ID parsed is %u, but expected %u.",
tli_from_file, tli_from_walseg)));
ereport(DEBUG1,
(errmsg_internal("backup timeline %u in file \"%s\"",
- tli_from_file, BACKUP_LABEL_FILE)));
+ tli_from_file, RECOVERY_CONTROL_FILE)));
}
if (ferror(lfp) || FreeFile(lfp))
ereport(FATAL,
(errcode_for_file_access(),
errmsg("could not read file \"%s\": %m",
- BACKUP_LABEL_FILE)));
+ RECOVERY_CONTROL_FILE)));
return true;
}
diff --git a/src/backend/backup/basebackup.c b/src/backend/backup/basebackup.c
index 7d025bcf382..a51da2dd5d7 100644
--- a/src/backend/backup/basebackup.c
+++ b/src/backend/backup/basebackup.c
@@ -191,10 +191,10 @@ static const struct exclude_list_item excludeFiles[] =
{RELCACHE_INIT_FILENAME, true},
/*
- * backup_label and tablespace_map should not exist in a running cluster
+ * recovery_control and tablespace_map should not exist in a running cluster
* capable of doing an online backup, but exclude them just in case.
*/
- {BACKUP_LABEL_FILE, false},
+ {RECOVERY_CONTROL_FILE, false},
{TABLESPACE_MAP, false},
/*
@@ -326,15 +326,15 @@ perform_base_backup(basebackup_options *opt, bbsink *sink)
{
struct stat statbuf;
bool sendtblspclinks = true;
- char *backup_label;
+ char *recovery_control;
bbsink_begin_archive(sink, "base.tar");
- /* In the main tar, include the backup_label first... */
- backup_label = build_backup_content(backup_state, false);
- sendFileWithContent(sink, BACKUP_LABEL_FILE,
- backup_label, &manifest);
- pfree(backup_label);
+ /* In the main tar, include the recovery_control first... */
+ recovery_control = build_backup_content(backup_state, false);
+ sendFileWithContent(sink, RECOVERY_CONTROL_FILE,
+ recovery_control, &manifest);
+ pfree(recovery_control);
/* Then the tablespace_map file, if required... */
if (opt->sendtblspcmapfile)
@@ -1053,7 +1053,7 @@ sendFileWithContent(bbsink *sink, const char *filename, const char *content,
len = strlen(content);
/*
- * Construct a stat struct for the backup_label file we're injecting in
+ * Construct a stat struct for the recovery_control file we're injecting in
* the tar.
*/
/* Windows doesn't have the concept of uid and gid */
diff --git a/src/backend/catalog/system_functions.sql b/src/backend/catalog/system_functions.sql
index 07c0d89c4f8..01e03a0343d 100644
--- a/src/backend/catalog/system_functions.sql
+++ b/src/backend/catalog/system_functions.sql
@@ -390,7 +390,7 @@ CREATE OR REPLACE FUNCTION
CREATE OR REPLACE FUNCTION pg_backup_stop (
wait_for_archive boolean DEFAULT true, OUT lsn pg_lsn,
- OUT labelfile text, OUT spcmapfile text)
+ OUT recoveryctlfile text, OUT spcmapfile text)
RETURNS record STRICT VOLATILE LANGUAGE internal as 'pg_backup_stop'
PARALLEL RESTRICTED;
diff --git a/src/bin/pg_basebackup/t/010_pg_basebackup.pl b/src/bin/pg_basebackup/t/010_pg_basebackup.pl
index b9f5e1266b4..5e13950b193 100644
--- a/src/bin/pg_basebackup/t/010_pg_basebackup.pl
+++ b/src/bin/pg_basebackup/t/010_pg_basebackup.pl
@@ -171,7 +171,7 @@ SKIP:
# Write some files to test that they are not copied.
foreach my $filename (
- qw(backup_label tablespace_map postgresql.auto.conf.tmp
+ qw(recovery_control tablespace_map postgresql.auto.conf.tmp
current_logfiles.tmp global/pg_internal.init.123))
{
open my $file, '>>', "$pgdata/$filename";
@@ -261,14 +261,14 @@ foreach my $filename (@tempRelationFiles)
"base/$postgresOid/$filename not copied");
}
-# Make sure existing backup_label was ignored.
-isnt(slurp_file("$tempdir/backup/backup_label"),
- 'DONOTCOPY', 'existing backup_label not copied');
+# Make sure existing recovery_control was ignored.
+isnt(slurp_file("$tempdir/backup/recovery_control"),
+ 'DONOTCOPY', 'existing recovery_control not copied');
rmtree("$tempdir/backup");
-# Now delete the bogus backup_label file since it will interfere with startup
-unlink("$pgdata/backup_label")
- or BAIL_OUT("unable to unlink $pgdata/backup_label");
+# Now delete the bogus recovery_control since it will interfere with startup
+unlink("$pgdata/recovery_control")
+ or BAIL_OUT("unable to unlink $pgdata/recovery_control");
$node->command_ok(
[
diff --git a/src/bin/pg_ctl/pg_ctl.c b/src/bin/pg_ctl/pg_ctl.c
index 807d7023a99..c480d80e25f 100644
--- a/src/bin/pg_ctl/pg_ctl.c
+++ b/src/bin/pg_ctl/pg_ctl.c
@@ -2447,7 +2447,7 @@ main(int argc, char **argv)
snprintf(postopts_file, MAXPGPATH, "%s/postmaster.opts", pg_data);
snprintf(version_file, MAXPGPATH, "%s/PG_VERSION", pg_data);
snprintf(pid_file, MAXPGPATH, "%s/postmaster.pid", pg_data);
- snprintf(backup_file, MAXPGPATH, "%s/backup_label", pg_data);
+ snprintf(backup_file, MAXPGPATH, "%s/recovery_control", pg_data);
/*
* Set mask based on PGDATA permissions,
diff --git a/src/bin/pg_rewind/filemap.c b/src/bin/pg_rewind/filemap.c
index ecadd69dc53..5bd076f84c9 100644
--- a/src/bin/pg_rewind/filemap.c
+++ b/src/bin/pg_rewind/filemap.c
@@ -139,12 +139,12 @@ static const struct exclude_list_item excludeFiles[] =
{"pg_internal.init", true}, /* defined as RELCACHE_INIT_FILENAME */
/*
- * If there is a backup_label or tablespace_map file, it indicates that a
- * recovery failed and this cluster probably can't be rewound, but exclude
+ * If there is a recovery_control or tablespace_map file, it indicates that
+ * a recovery failed and this cluster probably can't be rewound, but exclude
* them anyway if they are found.
*/
- {"backup_label", false}, /* defined as BACKUP_LABEL_FILE */
- {"tablespace_map", false}, /* defined as TABLESPACE_MAP */
+ {"recovery_control", false}, /* defined as RECOVERY_CONTROL_FILE */
+ {"tablespace_map", false}, /* defined as TABLESPACE_MAP */
/*
* If there's a backup_manifest, it belongs to a backup that was used to
diff --git a/src/bin/pg_rewind/pg_rewind.c b/src/bin/pg_rewind/pg_rewind.c
index bfd44a284e2..8359a4a4dc2 100644
--- a/src/bin/pg_rewind/pg_rewind.c
+++ b/src/bin/pg_rewind/pg_rewind.c
@@ -651,10 +651,10 @@ perform_rewind(filemap_t *filemap, rewind_source *source,
}
if (showprogress)
- pg_log_info("creating backup label and updating control file");
+ pg_log_info("creating recovery control and updating control file");
/*
- * Create a backup label file, to tell the target where to begin the WAL
+ * Create recovery control file, to tell the target where to begin the WAL
* replay. Normally, from the last common checkpoint between the source
* and the target. But if the source is a standby server, it's possible
* that the last common checkpoint is *after* the standby's restartpoint.
@@ -729,7 +729,7 @@ perform_rewind(filemap_t *filemap, rewind_source *source,
static void
sanityChecks(void)
{
- /* TODO Check that there's no backup_label in either cluster */
+ /* TODO Check that there's no recovery_control in either cluster */
/* Check system_identifier match */
if (ControlFile_target.system_identifier != ControlFile_source.system_identifier)
@@ -953,7 +953,7 @@ findCommonAncestorTimeline(TimeLineHistoryEntry *a_history, int a_nentries,
/*
- * Create a backup_label file that forces recovery to begin at the last common
+ * Create recovery_control file that forces recovery to begin at the last common
* checkpoint.
*/
static void
@@ -971,7 +971,7 @@ createBackupLabel(XLogRecPtr startpoint, TimeLineID starttli, XLogRecPtr checkpo
XLogFileName(xlogfilename, starttli, startsegno, WalSegSz);
/*
- * Construct backup label file
+ * Construct recovery control file
*/
stamp_time = time(NULL);
tmp = localtime(&stamp_time);
@@ -988,10 +988,10 @@ createBackupLabel(XLogRecPtr startpoint, TimeLineID starttli, XLogRecPtr checkpo
LSN_FORMAT_ARGS(checkpointloc),
strfbuf);
if (len >= sizeof(buf))
- pg_fatal("backup label buffer too small"); /* shouldn't happen */
+ pg_fatal("recovery control buffer too small"); /* shouldn't happen */
/* TODO: move old file out of the way, if any. */
- open_target_file("backup_label", true); /* BACKUP_LABEL_FILE */
+ open_target_file("recovery_control", true); /* RECOVERY_CONTROL_FILE */
write_target_range(buf, 0, len);
close_target_file();
}
diff --git a/src/include/access/xlog.h b/src/include/access/xlog.h
index 4ad572cb874..9556892a4a6 100644
--- a/src/include/access/xlog.h
+++ b/src/include/access/xlog.h
@@ -293,8 +293,8 @@ extern SessionBackupState get_backup_status(void);
/* File path names (all relative to $PGDATA) */
#define RECOVERY_SIGNAL_FILE "recovery.signal"
#define STANDBY_SIGNAL_FILE "standby.signal"
-#define BACKUP_LABEL_FILE "backup_label"
-#define BACKUP_LABEL_OLD "backup_label.old"
+#define RECOVERY_CONTROL_FILE "recovery_control"
+#define RECOVERY_CONTROL_OLD "recovery_control.old"
#define TABLESPACE_MAP "tablespace_map"
#define TABLESPACE_MAP_OLD "tablespace_map.old"
diff --git a/src/include/catalog/pg_proc.dat b/src/include/catalog/pg_proc.dat
index 72ea4aa8b8c..0a40c3c1ed6 100644
--- a/src/include/catalog/pg_proc.dat
+++ b/src/include/catalog/pg_proc.dat
@@ -6424,7 +6424,7 @@
proname => 'pg_backup_stop', provolatile => 'v', proparallel => 'r',
prorettype => 'record', proargtypes => 'bool',
proallargtypes => '{bool,pg_lsn,text,text}', proargmodes => '{i,o,o,o}',
- proargnames => '{wait_for_archive,lsn,labelfile,spcmapfile}',
+ proargnames => '{wait_for_archive,lsn,recoveryctlfile,spcmapfile}',
prosrc => 'pg_backup_stop' },
{ oid => '3436', descr => 'promote standby server',
proname => 'pg_promote', provolatile => 'v', prorettype => 'bool',
At Sat, 14 Oct 2023 14:19:42 -0400, David Steele <david@pgmasters.net> wrote in
I was recently discussing the complexities of dealing with pg_control
and backup_label with some hackers at PGConf NYC, when David
Christensen commented that backup_label was not a very good name since
it gives the impression of being informational and therefore something
the user can delete. In fact, we see this happen quite a lot, and
there have been some other discussions about it recently, see [1] and
[2]. I bounced the idea of a rename off various hackers at the
conference and in general people seemed to think it was a good idea.Attached is a patch to rename backup_label to recovery_control. The
Just an idea in a slightly different direction, but I'm wondering if
we can simply merge the content of backup_label into control file.
The file is 8192 bytes long, yet only 256 bytes are used. As a result,
we anticipate no overhead. Sucha configuration would forcibly prevent
uses from from removing the backup information.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Mon, 16 Oct 2023 13:16:42 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
Just an idea in a slightly different direction, but I'm wondering if
we can simply merge the content of backup_label into control file.
The file is 8192 bytes long, yet only 256 bytes are used. As a result,
we anticipate no overhead. Sucha configuration would forcibly prevent
uses from from removing the backup information.
In second thought, that would break the case of file-system level
backups, which require backup information separately from control
data.
Sorry for the noise.
--
Kyotaro Horiguchi
NTT Open Source Software Center
On Mon, Oct 16, 2023 at 01:16:42PM +0900, Kyotaro Horiguchi wrote:
Just an idea in a slightly different direction, but I'm wondering if
we can simply merge the content of backup_label into control file.
The file is 8192 bytes long, yet only 256 bytes are used. As a result,
we anticipate no overhead. Sucha configuration would forcibly prevent
uses from from removing the backup information.
With the critical assumptions behind PG_CONTROL_MAX_SAFE_SIZE, that
does not sound like a good idea to me. And that's without the fact
that base backup labels could make the control file theoretically even
larger than PG_CONTROL_FILE_SIZE, even if that's unlikely going to
happen in practice.
--
Michael
On 10/16/23 00:26, Kyotaro Horiguchi wrote:
At Mon, 16 Oct 2023 13:16:42 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
Just an idea in a slightly different direction, but I'm wondering if
we can simply merge the content of backup_label into control file.
The file is 8192 bytes long, yet only 256 bytes are used. As a result,
we anticipate no overhead. Sucha configuration would forcibly prevent
uses from from removing the backup information.In second thought, that would break the case of file-system level
backups, which require backup information separately from control
data.
Exactly -- but we do have a proposal to do the opposite and embed
pg_control into backup_label [1]/messages/by-id/1330cb48-4e47-03ca-f2fb-b144b49514d8@pgmasters.net (or hopefully recovery_control).
Regards,
-David
[1]: /messages/by-id/1330cb48-4e47-03ca-f2fb-b144b49514d8@pgmasters.net
/messages/by-id/1330cb48-4e47-03ca-f2fb-b144b49514d8@pgmasters.net
On Sat, Oct 14, 2023 at 2:22 PM David Steele <david@pgmasters.net> wrote:
I was recently discussing the complexities of dealing with pg_control
and backup_label with some hackers at PGConf NYC, when David Christensen
commented that backup_label was not a very good name since it gives the
impression of being informational and therefore something the user can
delete. In fact, we see this happen quite a lot, and there have been
some other discussions about it recently, see [1] and [2]. I bounced the
idea of a rename off various hackers at the conference and in general
people seemed to think it was a good idea.
Personally, I feel like this is an area where we keep moving the parts
around but I'm not sure we're really getting to anything better. We
got rid of recovery.conf. We got rid of exclusive backup mode. We
replaced pg_start_backup with pg_backup_start. It feels like every
other release or so we whack something around here, but I'm not
convinced that any of it is really making much of an impact. If
there's been any decrease in people screwing up their backups, I
haven't noticed it.
To be fair, I will grant that renaming pg_clog to pg_xact_status and
pg_xlog to pg_wal does seem to have reduced the incidence of people
nuking those directories, at least IME. So maybe this change would
help too, for similar reasons. But I'm still concerned that we're
doing too much superficial tinkering in this area. Breaking
compatibility is not without cost.
I also do wonder with recovery_control is really a better name. Maybe
I just have backup_label too firmly stuck in my head, but is what that
file does really best described as recovery control? I'm not so sure
about that.
--
Robert Haas
EDB: http://www.enterprisedb.com
On 10/16/23 10:19, Robert Haas wrote:
On Sat, Oct 14, 2023 at 2:22 PM David Steele <david@pgmasters.net> wrote:
I was recently discussing the complexities of dealing with pg_control
and backup_label with some hackers at PGConf NYC, when David Christensen
commented that backup_label was not a very good name since it gives the
impression of being informational and therefore something the user can
delete. In fact, we see this happen quite a lot, and there have been
some other discussions about it recently, see [1] and [2]. I bounced the
idea of a rename off various hackers at the conference and in general
people seemed to think it was a good idea.Personally, I feel like this is an area where we keep moving the parts
around but I'm not sure we're really getting to anything better. We
got rid of recovery.conf.
I agree that this was not an improvement. I was fine with bringing the
recovery options into the GUC fold but never really liked forcing them
into postgresql.auto.conf. But I lost that argument.
We got rid of exclusive backup mode. We
replaced pg_start_backup with pg_backup_start.
I do think this was an improvement. For example it allows us to do [1]/messages/by-id/1330cb48-4e47-03ca-f2fb-b144b49514d8@pgmasters.net,
which I believe is a better overall solution to the problem of torn
reads of pg_control. With exclusive backup we would not have this option.
It feels like every
other release or so we whack something around here, but I'm not
convinced that any of it is really making much of an impact. If
there's been any decrease in people screwing up their backups, I
haven't noticed it.
It's pretty subjective, but I feel much the same way. However, I think
the *areas* that people are messing up are changing as we remove
obstacles and I feel like we should address them. backup_label has
always been a bit of a problem -- basically deciding should it be deleted?
With the removal of exclusive backup we removed the only valid use case
(I think) for removing backup_label manually. Now, it should probably
never be removed manually, so we need to make adjustments to make that
clearer to the user, also see [1]/messages/by-id/1330cb48-4e47-03ca-f2fb-b144b49514d8@pgmasters.net.
Better messaging may also help, and I am also thinking about that.
To be fair, I will grant that renaming pg_clog to pg_xact_status and
pg_xlog to pg_wal does seem to have reduced the incidence of people
nuking those directories, at least IME. So maybe this change would
help too, for similar reasons. But I'm still concerned that we're
doing too much superficial tinkering in this area. Breaking
compatibility is not without cost.
True enough, but ISTM that we have gotten few (or any) actual complaints
outside of hackers speculating that there will be complaints. For the
various maintainers of backup software this is just business as usual.
The changes to pg_basebackup are also pretty trivial.
I also do wonder with recovery_control is really a better name. Maybe
I just have backup_label too firmly stuck in my head, but is what that
file does really best described as recovery control? I'm not so sure
about that.
The thing it does that describes it as "recovery control" in my view is
that it contains the LSN where Postgres must start recovery (plus TLI,
backup method, etc.). There is some other informational stuff in there,
but the important fields are all about ensuring consistent recovery.
At the end of the day the entire point of backup *is* recovery and users
will interact with this file primarily in recovery scenarios.
Regards,
-David
---
[1]: /messages/by-id/1330cb48-4e47-03ca-f2fb-b144b49514d8@pgmasters.net
/messages/by-id/1330cb48-4e47-03ca-f2fb-b144b49514d8@pgmasters.net
On Mon, Oct 16, 2023 at 11:15:53AM -0400, David Steele wrote:
On 10/16/23 10:19, Robert Haas wrote:
We got rid of exclusive backup mode. We replaced pg_start_backup
with pg_backup_start.I do think this was an improvement. For example it allows us to do
[1], which I believe is a better overall solution to the problem of
torn reads of pg_control. With exclusive backup we would not have this
option.
Well maybe, but it also seems to mean that any other 3rd party (i.e. not
Postgres-specific) backup tool seems to only support Postgres up till
version 14, as they cannot deal with non-exclusive mode - they are used
to a simple pre/post-script approach.
Not sure what to do about this, but as people/companies start moving to
15, I am afraid we will get people complaining about this. I think
having exclusive mode still be the default for pg_start_backup() (albeit
deprecated) in one release and then dropping it in the next was too
fast.
Or is somebody helping those "enterprise" backup solutions along in
implementing non-exclusive Postgres backups?
Michael
On Mon, Oct 16, 2023 at 12:06 PM Michael Banck <mbanck@gmx.net> wrote:
Not sure what to do about this, but as people/companies start moving to
15, I am afraid we will get people complaining about this. I think
having exclusive mode still be the default for pg_start_backup() (albeit
deprecated) in one release and then dropping it in the next was too
fast.
I completely agree, and I said so at the time, but got shouted down. I
think the argument that exclusive backups were breaking anything at
all was very weak. Nobody was being forced to use them, and they broke
nothing for people who didn't.
--
Robert Haas
EDB: http://www.enterprisedb.com
On 10/16/23 12:06, Michael Banck wrote:
On Mon, Oct 16, 2023 at 11:15:53AM -0400, David Steele wrote:
On 10/16/23 10:19, Robert Haas wrote:
We got rid of exclusive backup mode. We replaced pg_start_backup
with pg_backup_start.I do think this was an improvement. For example it allows us to do
[1], which I believe is a better overall solution to the problem of
torn reads of pg_control. With exclusive backup we would not have this
option.Well maybe, but it also seems to mean that any other 3rd party (i.e. not
Postgres-specific) backup tool seems to only support Postgres up till
version 14, as they cannot deal with non-exclusive mode - they are used
to a simple pre/post-script approach.
I'd be curious to know what enterprise solutions currently depend on
this method. At the very least they'd need to manage a WAL archive since
copying pg_wal is not a safe thing to do (without a snapshot), so it's
not just a matter of using start/stop scripts. And you'd probably want
PITR, etc.
Not sure what to do about this, but as people/companies start moving to
15, I am afraid we will get people complaining about this. I think
having exclusive mode still be the default for pg_start_backup() (albeit
deprecated) in one release and then dropping it in the next was too
fast.
But lots of companies are on PG15 and lots of hosting providers support
it, apparently with no issues. Perhaps the companies you are referring
to are lagging in adoption (a pretty common scenario) but I still see no
evidence that there is a big problem looming.
Exclusive backup was deprecated for six releases, which should have been
ample time to switch over. All the backup solutions I am familiar with
have supported non-exclusive backup for years.
Or is somebody helping those "enterprise" backup solutions along in
implementing non-exclusive Postgres backups?
I couldn't say, but there are many examples in open source projects of
how to do this. Somebody (Laurenz, I believe) also wrote a shell script
to simulate exclusive backup behavior for those that want to continue
using it. Not what I would recommend, but he showed that it was possible.
Regards,
-David
On 10/16/23 12:12, Robert Haas wrote:
On Mon, Oct 16, 2023 at 12:06 PM Michael Banck <mbanck@gmx.net> wrote:
Not sure what to do about this, but as people/companies start moving to
15, I am afraid we will get people complaining about this. I think
having exclusive mode still be the default for pg_start_backup() (albeit
deprecated) in one release and then dropping it in the next was too
fast.I completely agree, and I said so at the time, but got shouted down. I
think the argument that exclusive backups were breaking anything at
all was very weak. Nobody was being forced to use them, and they broke
nothing for people who didn't.
My argument then (and now) is that exclusive backup prevented us from
making material improvements in backup and recovery. It was complicated,
duplicative (in code and docs), and entirely untested.
So you are correct that it was only dangerous to the people who were
using it (even if they did not know they were), but it was also a
barrier to progress.
Regards,
-David
On Mon, 2023-10-16 at 12:12 -0400, Robert Haas wrote:
On Mon, Oct 16, 2023 at 12:06 PM Michael Banck <mbanck@gmx.net> wrote:
Not sure what to do about this, but as people/companies start moving to
15, I am afraid we will get people complaining about this. I think
having exclusive mode still be the default for pg_start_backup() (albeit
deprecated) in one release and then dropping it in the next was too
fast.I completely agree, and I said so at the time, but got shouted down. I
think the argument that exclusive backups were breaking anything at
all was very weak. Nobody was being forced to use them, and they broke
nothing for people who didn't.
+1
Yours,
Laurenz Albe
On 16.10.23 17:15, David Steele wrote:
I also do wonder with recovery_control is really a better name. Maybe
I just have backup_label too firmly stuck in my head, but is what that
file does really best described as recovery control? I'm not so sure
about that.The thing it does that describes it as "recovery control" in my view is
that it contains the LSN where Postgres must start recovery (plus TLI,
backup method, etc.). There is some other informational stuff in there,
but the important fields are all about ensuring consistent recovery.At the end of the day the entire point of backup *is* recovery and users
will interact with this file primarily in recovery scenarios.
Maybe "restore" is better than "recovery", since recovery also happens
separate from backups, but restoring is something you do with a backup
(and there is also restore_command etc.).
On 10/18/23 03:07, Peter Eisentraut wrote:
On 16.10.23 17:15, David Steele wrote:
I also do wonder with recovery_control is really a better name. Maybe
I just have backup_label too firmly stuck in my head, but is what that
file does really best described as recovery control? I'm not so sure
about that.The thing it does that describes it as "recovery control" in my view
is that it contains the LSN where Postgres must start recovery (plus
TLI, backup method, etc.). There is some other informational stuff in
there, but the important fields are all about ensuring consistent
recovery.At the end of the day the entire point of backup *is* recovery and
users will interact with this file primarily in recovery scenarios.Maybe "restore" is better than "recovery", since recovery also happens
separate from backups, but restoring is something you do with a backup
(and there is also restore_command etc.).
I would not object to restore (there is restore_command) but I do think
of what PostgreSQL does as "recovery" as opposed to "restore", which
comes before the recovery. Recovery is used a lot in the docs and there
is also recovery.signal.
But based on the discussion in [1]/messages/by-id/0f948866-7caf-0759-d53c-93c3e266ec3f@pgmasters.net I think we might be able to do away
with backup_label entirely, which would make this change moot.
Regards,
-David
[1]: /messages/by-id/0f948866-7caf-0759-d53c-93c3e266ec3f@pgmasters.net
/messages/by-id/0f948866-7caf-0759-d53c-93c3e266ec3f@pgmasters.net