the <filename>pg_wal</filename> directory, or run
   <application>pg_rewind</application> with the <literal>-c</literal> option to
   automatically retrieve them from the WAL archive. The use of
   <application>pg_rewind</application> is not limited to failover, e.g.,  a standby
   server can be promoted, run some write transactions, and then rewound
   to become a standby again.
  </para>

  <para>
   After running <application>pg_rewind</application>, WAL replay needs to
   complete for the data directory to be in a consistent state. When the
   target server is started again it will enter archive recovery and replay
   all WAL generated in the source server from the last checkpoint before
   the point of divergence. If some of the WAL was no longer available in the
   source server when <application>pg_rewind</application> was run, and
   therefore could not be copied by the <application>pg_rewind</application>
   session, it must be made available when the target server is started.
   This can be done by creating a <filename>recovery.signal</filename> file
   in the target data directory and by configuring a suitable
   <xref linkend="guc-restore-command"/> in
   <filename>postgresql.conf</filename>.
  </para>

  <para>
   <application>pg_rewind</application> requires that the target server either has
   the <xref linkend="guc-wal-log-hints"/> option enabled
   in <filename>postgresql.conf</filename> or data checksums enabled when
   the cluster was initialized with <application>initdb</application>.  Neither of these
   are currently on by default.  <xref linkend="guc-full-page-writes"/>
   must also be set to <literal>on</literal>, but is enabled by default.
  </para>

  <warning>
   <title>Warning: Failures While Rewinding</title>
   <para>
    If <application>pg_rewind</application> fails while processing, then
    the data folder of the target is likely not in a state that can be
    recovered.  In such a case, taking a new fresh backup is recommended.
   </para>

   <para>
    As <application>pg_rewind</application> copies configuration files
    entirely from the source, it may be required to correct the configuration
    used for recovery before restarting the target server, especially if
    the target is reintroduced as a standby of the source. If you restart
    the server after the rewind operation has finished but without configuring
    recovery, the target may again diverge from the primary.
   </para>

   <para>
    <application>pg_rewind</application> will fail immediately if it finds
    files it cannot write directly to.  This can happen for example when
    the source and the target server use the same file mapping for read-only
    SSL keys and certificates.  If such files are present on the target server
    it is recommended to remove them before running
    <application>pg_rewind</application>.  After doing the rewind, some of
    those files may have been copied from the source, in which case it may
    be necessary to remove the data copied and restore back the set of links
    used before the rewind.
   </para>
  </warning>
 </refsect1>

 <refsect1>
  <title>Options</title>

   <para>
    <application>pg_rewind</application> accepts the following command-line
    arguments:

    <variablelist>
     <varlistentry>
      <term><option>-D <replaceable class="parameter">directory</replaceable></option></term>
      <term><option>--target-pgdata=<replaceable class="parameter">directory</replaceable></option></term>
      <listitem>
       <para>
        This option specifies the target data directory that is synchronized
        with the source. The target server must be shut down cleanly before
        running <application>pg_rewind</application>
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--source-pgdata=<replaceable class="parameter">directory</replaceable></option></term>
      <listitem>
       <para>
        Specifies the file system path to the