--- /dev/null
+<!-- doc/src/sgml/obsolete-pgxlogdump.sgml -->
+<!--
+ See doc/src/sgml/obsolete.sgml for why this file exists. Do not change the id attribute.
+-->
+
+<sect1 id="app-pgreceivexlog" xreflabel="pg_receivexlog">
+ <title><command>pg_receivexlog</command> renamed to <command>pg_receivewal</command></title>
+
+ <indexterm>
+ <primary>pg_receivexlog</primary>
+ <see>pg_receivewal</see>
+ </indexterm>
+
+ <para>
+ PostgreSQL 9.6 and below provided a command named
+ <command>pg_receivexlog</command>
+ <indexterm><primary>pg_receivexlog</primary></indexterm>
+ to fetch write-ahead-log (WAL) files. This command was renamed to <command>pg_receivewal</command>, see
+ <xref linkend="app-pgreceivewal"/> for documentation of <command>pg_receivewal</command> and see
+ <link linkend="release-prior">the release notes for PostgreSQL 10</link> for details
+ on this change.
+ </para>
+
+</sect1>
--- /dev/null
+<!-- doc/src/sgml/obsolete-pgresetxlog.sgml -->
+<!--
+ See doc/src/sgml/obsolete.sgml for why this file exists. Do not change the id attribute.
+-->
+
+<sect1 id="app-pgresetxlog" xreflabel="pg_resetxlog">
+ <title><command>pg_resetxlog</command> renamed to <command>pg_resetwal</command></title>
+
+ <indexterm>
+ <primary>pg_resetxlog</primary>
+ <see>pg_resetwal</see>
+ </indexterm>
+
+ <para>
+ PostgreSQL 9.6 and below provided a command named
+ <command>pg_resetxlog</command>
+ <indexterm><primary>pg_resetxlog</primary></indexterm>
+ to reset the write-ahead-log (WAL) files. This command was renamed to <command>pg_resetwal</command>, see
+ <xref linkend="app-pgresetwal"/> for documentation of <command>pg_resetwal</command> and see
+ <link linkend="release-prior">the release notes for PostgreSQL 10</link> for details
+ on this change.
+ </para>
+
+</sect1>
--- /dev/null
+<!-- doc/src/sgml/obsolete-pgxlogdump.sgml -->
+<!--
+ See doc/src/sgml/obsolete.sgml for why this file exists. Do not change the id attribute.
+-->
+
+<sect1 id="pgxlogdump" xreflabel="pg_xlogdump">
+ <title><command>pg_xlogdump</command> renamed to <command>pg_waldump</command></title>
+
+ <indexterm>
+ <primary>pg_xlogdump</primary>
+ <see>pg_waldump</see>
+ </indexterm>
+
+ <para>
+ PostgreSQL 9.6 and below provided a command named
+ <command>pg_xlogdump</command>
+ <indexterm><primary>pg_xlogdump</primary></indexterm>
+ to read write-ahead-log (WAL) files. This command was renamed to <command>pg_waldump</command>, see
+ <xref linkend="pgwaldump"/> for documentation of <command>pg_waldump</command> and see
+ <link linkend="release-prior">the release notes for PostgreSQL 10</link> for details
+ on this change.
+ </para>
+
+</sect1>
--- /dev/null
+<!-- doc/src/sgml/obsolete-recovery-config.sgml -->
+<!--
+ See doc/src/sgml/obsolete.sgml for why this file exists. Do not change the id attribute.
+-->
+
+<sect1 id="recovery-config" xreflabel="recovery.conf">
+ <title><filename>recovery.conf</filename> file merged into <filename>postgresql.conf</filename></title>
+
+ <indexterm>
+ <primary><filename>recovery.conf</filename></primary>
+ </indexterm>
+
+ <para>
+ PostgreSQL 11 and below used a configuration file named
+ <filename>recovery.conf</filename>
+ <indexterm><primary>recovery.conf</primary></indexterm>
+ to manage replicas and standbys. Support for this file was removed in PostgreSQL 12. See
+ <link linkend="release-prior">the release notes for PostgreSQL 12</link> for details
+ on this change.
+ </para>
+
+ <para>
+ On PostgreSQL 12 and above,
+ <link linkend="continuous-archiving">archive recovery, streaming replication, and PITR</link>
+ are configured using
+ <link linkend="runtime-config-replication-standby">normal server configuration parameters</link>.
+ These are set in <filename>postgresql.conf</filename> or via
+ <link linkend="sql-altersystem">ALTER SYSTEM</link>
+ like any other parameter.
+ </para>
+
+ <para>
+ The server will not start if a <filename>recovery.conf</filename> exists.
+ </para>
+
+ <para>
+ The
+ <literal>trigger_file</literal>
+ <indexterm>
+ <primary>trigger_file</primary>
+ <see>promote_trigger_file</see>
+ </indexterm>
+ setting has been renamed to
+ <xref linkend="guc-promote-trigger-file"/>.
+ </para>
+
+ <para>
+ The
+ <literal>standby_mode</literal>
+ <indexterm>
+ <primary>standby_mode</primary>
+ <see>standby.signal</see>
+ </indexterm>
+ setting has been removed. A <filename>standby.signal</filename> file in the data directory
+ is used instead. See <xref linkend="standby-server-operation"/> for details.
+ </para>
+
+</sect1>
--- /dev/null
+<!-- doc/src/sgml/obsolete.sgml -->
+
+<appendix id="appendix-obsolete">
+ <title>Obsolete or Renamed Features</title>
+
+ <para>
+ Functionality is sometimes removed from PostgreSQL, feature, setting
+ and file names sometimes change, or documentation moves to different
+ places. This section directs users coming from old versions of the
+ documentation or from external links to the appropriate new location
+ for the information they need.
+ </para>
+
+ <!--
+ This section exists so that people following /current/ links to documentation
+ don't get a 404 when we move or rename things. And users who find old versions
+ of the docs in searches or old command names when checking the index can
+ follow links to the new commands.
+
+ Each subsection here should retain the same <chapter>, <appendix> and/or
+ <sect1> "id" attribute that was used for the relevant documentation before
+ it was renamed or moved. Do not prepend "obsolete-" or anything, keep it
+ exactly the same. These ids are used to determine the filenames for generated
+ HTML docs so changing them will break links.
+
+ Each entry should also insert index terms redirecting from the old to new
+ names. The recommended spelling is
+
+ <indexterm><primary>oldname</primary><see>newname</see></indexterm>
+
+ We don't bother with attempting to maintain down-version linking, e.g from
+ pg_waldump to pg_xlogdump. Users of old versions should use old docs. There
+ is no need to add index terms pointing from the new to old names.
+ -->
+
+ &obsolete-recovery-config;
+ &obsolete-pgxlogdump;
+ &obsolete-pgresetxlog;
+ &obsolete-pgreceivexlog;
+
+</appendix>
<title>Standby Servers</title>
<para>
- These settings control the behavior of a standby server that is
+ These settings control the behavior of a
+ <link linkend="standby-server-operation">standby server</link>
+ that is
to receive replication data. Their values on the primary server
are irrelevant.
</para>
<!-- back matter -->
<!ENTITY biblio SYSTEM "biblio.sgml">
+
+<!-- Stubs for removed entries to preserve public links -->
+<!ENTITY obsolete SYSTEM "appendix-obsolete.sgml">
+<!ENTITY obsolete-recovery-config SYSTEM "appendix-obsolete-recovery-config.sgml">
+<!ENTITY obsolete-pgxlogdump SYSTEM "appendix-obsolete-pgxlogdump.sgml">
+<!ENTITY obsolete-pgresetxlog SYSTEM "appendix-obsolete-pgresetxlog.sgml">
+<!ENTITY obsolete-pgreceivexlog SYSTEM "appendix-obsolete-pgreceivexlog.sgml">
</sect2>
- <sect2 id="standby-server-operation">
+ <sect2 id="standby-server-operation" xreflabel="Standby Server Operation">
<title>Standby Server Operation</title>
+ <para>
+ A server enters standby mode if a
+ <anchor id="file-standby-signal" xreflabel="standby.signal"/>
+ <filename>standby.signal</filename>
+ <indexterm><primary><filename>standby.signal</filename></primary></indexterm>
+ file exists in the data directory when the server is started.
+ </para>
+
<para>
In standby mode, the server continuously applies WAL received from the
primary server. The standby server can read WAL from a WAL archive
<para>
To set up the standby server, restore the base backup taken from primary
server (see <xref linkend="backup-pitr-recovery"/>). Create a file
- <filename>standby.signal</filename> in the standby's cluster data
+ <link linkend="file-standby-signal"><filename>standby.signal</filename></link><indexterm><primary>standby.signal</primary></indexterm>
+ in the standby's cluster data
directory. Set <xref linkend="guc-restore-command"/> to a simple command to copy files from
the WAL archive. If you plan to have multiple standby servers for high
availability purposes, make sure that <varname>recovery_target_timeline</varname> is set to
<para>
If <varname>hot_standby</varname> is <literal>on</literal> in <filename>postgresql.conf</filename>
- (the default value) and there is a <filename>standby.signal</filename>
+ (the default value) and there is a
+ <link linkend="file-standby-signal"><filename>standby.signal</filename></link><indexterm><primary>standby.signal</primary><secondary>for hot standby</secondary></indexterm>
file present, the server will run in Hot Standby mode.
However, it may take some time for Hot Standby connections to be allowed,
because the server will not accept connections until it has completed
&acronyms;
&glossary;
&color;
+ &obsolete;
</part>
<listitem>
<para>
- Creates a <filename>standby.signal</filename> file and appends
+ Creates a
+ <link linkend="file-standby-signal"><filename>standby.signal</filename></link>
+ <indexterm><primary><filename>standby.signal</filename></primary><secondary>pg_basebackup --write-recovery-conf</secondary></indexterm>
+ file and appends
connection settings to the <filename>postgresql.auto.conf</filename>
file in the target directory (or within the base archive file when
using tar format). This eases setting up a standby server using the