Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 69f7a4d

Browse files
committed
Adjust error checks in pg_start_backup and pg_stop_backup to make it possible
to perform a backup without archive_mode being enabled. This gives up some user-error protection in order to improve usefulness for streaming-replication scenarios. Per discussion.
1 parent f0488bd commit 69f7a4d

File tree

2 files changed

+27
-19
lines changed

2 files changed

+27
-19
lines changed

doc/src/sgml/backup.sgml

+2-1
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.153 2010/04/28 16:10:39 heikki Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.154 2010/04/29 21:49:03 tgl Exp $ -->
22

33
<chapter id="backup">
44
<title>Backup and Restore</title>
@@ -779,6 +779,7 @@ SELECT pg_stop_backup();
779779
Once the WAL segment files active during the backup are archived, you are
780780
done. The file identified by <function>pg_stop_backup</>'s result is
781781
the last segment that is required to form a complete set of backup files.
782+
If <varname>archive_mode</> is enabled,
782783
<function>pg_stop_backup</> does not return until the last segment has
783784
been archived.
784785
Archiving of these files happens automatically since you have

src/backend/access/transam/xlog.c

+25-18
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@
77
* Portions Copyright (c) 1996-2010, PostgreSQL Global Development Group
88
* Portions Copyright (c) 1994, Regents of the University of California
99
*
10-
* $PostgreSQL: pgsql/src/backend/access/transam/xlog.c,v 1.406 2010/04/29 21:36:19 tgl Exp $
10+
* $PostgreSQL: pgsql/src/backend/access/transam/xlog.c,v 1.407 2010/04/29 21:49:03 tgl Exp $
1111
*
1212
*-------------------------------------------------------------------------
1313
*/
@@ -8205,18 +8205,11 @@ pg_start_backup(PG_FUNCTION_ARGS)
82058205
errmsg("recovery is in progress"),
82068206
errhint("WAL control functions cannot be executed during recovery.")));
82078207

8208-
if (!XLogArchivingActive())
8209-
ereport(ERROR,
8210-
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
8211-
errmsg("WAL archiving is not active"),
8212-
errhint("archive_mode must be enabled at server start.")));
8213-
8214-
if (!XLogArchiveCommandSet())
8208+
if (!XLogIsNeeded())
82158209
ereport(ERROR,
82168210
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
8217-
errmsg("WAL archiving is not active"),
8218-
errhint("archive_command must be defined before "
8219-
"online backups can be made safely.")));
8211+
errmsg("WAL level not sufficient for making an online backup"),
8212+
errhint("wal_level must be set to \"archive\" or \"hot_standby\" at server start.")));
82208213

82218214
backupidstr = text_to_cstring(backupid);
82228215

@@ -8404,11 +8397,11 @@ pg_stop_backup(PG_FUNCTION_ARGS)
84048397
errmsg("recovery is in progress"),
84058398
errhint("WAL control functions cannot be executed during recovery.")));
84068399

8407-
if (!XLogArchivingActive())
8400+
if (!XLogIsNeeded())
84088401
ereport(ERROR,
84098402
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
8410-
errmsg("WAL archiving is not active"),
8411-
errhint("archive_mode must be enabled at server start.")));
8403+
errmsg("WAL level not sufficient for making an online backup"),
8404+
errhint("wal_level must be set to \"archive\" or \"hot_standby\" at server start.")));
84128405

84138406
/*
84148407
* OK to clear forcePageWrites
@@ -8516,16 +8509,26 @@ pg_stop_backup(PG_FUNCTION_ARGS)
85168509
CleanupBackupHistory();
85178510

85188511
/*
8519-
* Wait until both the last WAL file filled during backup and the history
8520-
* file have been archived. We assume that the alphabetic sorting
8521-
* property of the WAL files ensures any earlier WAL files are safely
8522-
* archived as well.
8512+
* If archiving is enabled, wait for all the required WAL files to be
8513+
* archived before returning. If archiving isn't enabled, the required
8514+
* WAL needs to be transported via streaming replication (hopefully
8515+
* with wal_keep_segments set high enough), or some more exotic
8516+
* mechanism like polling and copying files from pg_xlog with script.
8517+
* We have no knowledge of those mechanisms, so it's up to the user to
8518+
* ensure that he gets all the required WAL.
8519+
*
8520+
* We wait until both the last WAL file filled during backup and the
8521+
* history file have been archived, and assume that the alphabetic
8522+
* sorting property of the WAL files ensures any earlier WAL files are
8523+
* safely archived as well.
85238524
*
85248525
* We wait forever, since archive_command is supposed to work and we
85258526
* assume the admin wanted his backup to work completely. If you don't
85268527
* wish to wait, you can set statement_timeout. Also, some notices are
85278528
* issued to clue in anyone who might be doing this interactively.
85288529
*/
8530+
if (XLogArchivingActive())
8531+
{
85298532
XLByteToPrevSeg(stoppoint, _logId, _logSeg);
85308533
XLogFileName(lastxlogfilename, ThisTimeLineID, _logId, _logSeg);
85318534

@@ -8564,6 +8567,10 @@ pg_stop_backup(PG_FUNCTION_ARGS)
85648567

85658568
ereport(NOTICE,
85668569
(errmsg("pg_stop_backup complete, all required WAL segments have been archived")));
8570+
}
8571+
else
8572+
ereport(NOTICE,
8573+
(errmsg("WAL archiving is not enabled; you must ensure that all required WAL segments are copied through other means to complete the backup")));
85678574

85688575
/*
85698576
* We're done. As a convenience, return the ending WAL location.

0 commit comments

Comments
 (0)