Skip to content

Commit 2dedf4d

Browse files
committed
Integrate recovery.conf into postgresql.conf
recovery.conf settings are now set in postgresql.conf (or other GUC sources). Currently, all the affected settings are PGC_POSTMASTER; this could be refined in the future case by case. Recovery is now initiated by a file recovery.signal. Standby mode is initiated by a file standby.signal. The standby_mode setting is gone. If a recovery.conf file is found, an error is issued. The trigger_file setting has been renamed to promote_trigger_file as part of the move. The documentation chapter "Recovery Configuration" has been integrated into "Server Configuration". pg_basebackup -R now appends settings to postgresql.auto.conf and creates a standby.signal file. Author: Fujii Masao <masao.fujii@gmail.com> Author: Simon Riggs <simon@2ndquadrant.com> Author: Abhijit Menon-Sen <ams@2ndquadrant.com> Author: Sergei Kornilov <sk@zsrv.org> Discussion: https://www.postgresql.org/message-id/flat/607741529606767@web3g.yandex.ru/
1 parent ab69ea9 commit 2dedf4d

40 files changed

+1403
-1173
lines changed

contrib/pg_standby/pg_standby.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -611,7 +611,7 @@ usage(void)
611611
printf(" -w MAXWAITTIME max seconds to wait for a file (0=no limit) (default=0)\n");
612612
printf(" -?, --help show this help, then exit\n");
613613
printf("\n"
614-
"Main intended use as restore_command in recovery.conf:\n"
614+
"Main intended use as restore_command in postgresql.conf:\n"
615615
" restore_command = 'pg_standby [OPTION]... ARCHIVELOCATION %%f %%p %%r'\n"
616616
"e.g.\n"
617617
" restore_command = 'pg_standby /mnt/server/archiverdir %%f %%p %%r'\n");

doc/src/sgml/backup.sgml

Lines changed: 11 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -1220,8 +1220,11 @@ SELECT pg_stop_backup();
12201220
</listitem>
12211221
<listitem>
12221222
<para>
1223-
Create a recovery command file <filename>recovery.conf</filename> in the cluster
1224-
data directory (see <xref linkend="recovery-config"/>). You might
1223+
Set recovery configuration settings in
1224+
<filename>postgresql.conf</filename> (see <xref
1225+
linkend="runtime-config-wal-archive-recovery"/>) and create a file
1226+
<filename>recovery.signal</filename> in the cluster
1227+
data directory. You might
12251228
also want to temporarily modify <filename>pg_hba.conf</filename> to prevent
12261229
ordinary users from connecting until you are sure the recovery was successful.
12271230
</para>
@@ -1232,8 +1235,8 @@ SELECT pg_stop_backup();
12321235
proceed to read through the archived WAL files it needs. Should the
12331236
recovery be terminated because of an external error, the server can
12341237
simply be restarted and it will continue recovery. Upon completion
1235-
of the recovery process, the server will rename
1236-
<filename>recovery.conf</filename> to <filename>recovery.done</filename> (to prevent
1238+
of the recovery process, the server will remove
1239+
<filename>recovery.signal</filename> (to prevent
12371240
accidentally re-entering recovery mode later) and then
12381241
commence normal database operations.
12391242
</para>
@@ -1249,12 +1252,9 @@ SELECT pg_stop_backup();
12491252
</para>
12501253

12511254
<para>
1252-
The key part of all this is to set up a recovery configuration file that
1255+
The key part of all this is to set up a recovery configuration that
12531256
describes how you want to recover and how far the recovery should
1254-
run. You can use <filename>recovery.conf.sample</filename> (normally
1255-
located in the installation's <filename>share/</filename> directory) as a
1256-
prototype. The one thing that you absolutely must specify in
1257-
<filename>recovery.conf</filename> is the <varname>restore_command</varname>,
1257+
run. The one thing that you absolutely must specify is the <varname>restore_command</varname>,
12581258
which tells <productname>PostgreSQL</productname> how to retrieve archived
12591259
WAL file segments. Like the <varname>archive_command</varname>, this is
12601260
a shell command string. It can contain <literal>%f</literal>, which is
@@ -1316,7 +1316,7 @@ restore_command = 'cp /mnt/server/archivedir/%f %p'
13161316
<para>
13171317
If you want to recover to some previous point in time (say, right before
13181318
the junior DBA dropped your main transaction table), just specify the
1319-
required <link linkend="recovery-target-settings">stopping point</link> in <filename>recovery.conf</filename>. You can specify
1319+
required <link linkend="runtime-config-wal-recovery-target">stopping point</link>. You can specify
13201320
the stop point, known as the <quote>recovery target</quote>, either by
13211321
date/time, named restore point or by completion of a specific transaction
13221322
ID. As of this writing only the date/time and named restore point options
@@ -1414,7 +1414,7 @@ restore_command = 'cp /mnt/server/archivedir/%f %p'
14141414
that was current when the base backup was taken. If you wish to recover
14151415
into some child timeline (that is, you want to return to some state that
14161416
was itself generated after a recovery attempt), you need to specify the
1417-
target timeline ID in <filename>recovery.conf</filename>. You cannot recover into
1417+
target timeline ID in <xref linkend="guc-recovery-target-timeline"/>. You cannot recover into
14181418
timelines that branched off earlier than the base backup.
14191419
</para>
14201420
</sect2>

0 commit comments

Comments
 (0)