doc: note downstream node (dis)connection monitoring in more places

See also https://www.df7cb.de/blog/2020/apt-archive.postgresql.org.html

HISTORY

@@ -1,4 +1,8 @@
-5.0     2019-10-??
+5.0.1   20??-??-??
+        repmgr: ensure an existing replication slot is not deleted if the
+          follow target is the node's current upstream (Ian)
+
+5.0     2019-10-15
         general: add PostgreSQL 12 support (Ian)
         general: parse configuration file using flex (Ian)
         repmgr: rename "repmgr daemon ..." commands to "repmgr service ..." (Ian)

README.md

@@ -7,32 +7,30 @@ replication capabilities with utilities to set up standby servers, monitor
 replication, and perform administrative tasks such as failover or switchover
 operations.
 
-`repmgr 4` is a complete rewrite of the existing `repmgr` codebase, allowing
-the use of all of the latest features in PostgreSQL replication.
-
-PostgreSQL 11, 10, 9.6 and 9.5 are fully supported.
+PostgreSQL 12, 11, 10, 9.6 and 9.5 are fully supported.
 PostgreSQL 9.4 and 9.3 are supported, with some restrictions.
 
 `repmgr` is distributed under the GNU GPL 3 and maintained by 2ndQuadrant.
 
-### BDR support
-
-`repmgr 4` supports monitoring of a two-node BDR 2.0 cluster on PostgreSQL 9.6
-only. Note that BDR 2.0 is not publicly available; please contact 2ndQuadrant
-for details.
-
-
 Documentation
 -------------
 
-The main `repmgr` documentation is available here:
+The full `repmgr` documentation is available here:
 
 > [repmgr documentation](https://repmgr.org/docs/current/index.html)
 
-The `README` file for `repmgr` 3.x is available here:
+The old `README` file for `repmgr` 3.x is available here:
 
 > https://github.com/2ndQuadrant/repmgr/blob/REL3_3_STABLE/README.md
 
+Note that the `repmgr` 3.x series is no longer supported and contains known bugs;
+please upgrade to the current `repmgr` version as soon as possible.
+
+Versions
+--------
+
+For an overview of `repmgr` versions and PostgreSQL compatibility, see the
+[repmgr compatibility matrix](https://repmgr.org/docs/current/install-requirements.html#INSTALL-COMPATIBILITY-MATRIX).
 
 Files
 ------
@@ -72,6 +70,8 @@ Please report bugs and other issues to:
 
 * https://github.com/2ndQuadrant/repmgr
 
+See 
+
 Further information is available at https://repmgr.org/
 
 We'd love to hear from you about how you use repmgr. Case studies and
@@ -98,6 +98,8 @@ Further reading
 ---------------
 
 * [repmgr documentation](https://repmgr.org/docs/current/index.html)
+* [How to Automate PostgreSQL 12 Replication and Failover with repmgr - Part 1](https://www.2ndquadrant.com/en/blog/how-to-automate-postgresql-12-replication-and-failover-with-repmgr-part-1/)
+* [How to Automate PostgreSQL 12 Replication and Failover with repmgr - Part 2](https://www.2ndquadrant.com/en/blog/how-to-automate-postgresql-12-replication-and-failover-with-repmgr-part-2/)
 * https://blog.2ndquadrant.com/repmgr-3-2-is-here-barman-support-brand-new-high-availability-features/
 * https://blog.2ndquadrant.com/improvements-in-repmgr-3-1-4/
 * https://blog.2ndquadrant.com/managing-useful-clusters-repmgr/

configfile.c

@@ -1180,7 +1180,8 @@ reload_config(t_configuration_options *orig_options, t_server_type server_type)
 	_parse_config(&new_options, &config_errors, &config_warnings);
 
 
-	if (server_type == PRIMARY || server_type == STANDBY)
+	if (new_options.failover == FAILOVER_AUTOMATIC
+		&& (server_type == PRIMARY || server_type == STANDBY))
 	{
 		if (new_options.promote_command[0] == '\0')
 		{
@@ -1882,6 +1883,8 @@ modify_auto_conf(const char *data_dir, KeyValueList *items)
 	PQExpBufferData auto_conf_contents;
 
 	FILE	   *fp;
+	mode_t		um;
+
 	KeyValueList config = {NULL, NULL};
 	KeyValueListCell *cell = NULL;
 
@@ -1937,7 +1940,11 @@ modify_auto_conf(const char *data_dir, KeyValueList *items)
 						  cell->key, cell->value);
 	}
 
+	/* Set umask to 0600 */
+	um = umask((~(S_IRUSR | S_IWUSR)) & (S_IRWXG | S_IRWXO));
 	fp = fopen(auto_conf_tmp.data, "w");
+	umask(um);
+
 	if (fp == NULL)
 	{
 		fprintf(stderr, "unable to open \"%s\": %s\n",

configure

@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for repmgr 5.0.
+# Generated by GNU Autoconf 2.69 for repmgr 5.0.0.
 #
 # Report bugs to <repmgr@googlegroups.com>.
 #
@@ -582,8 +582,8 @@ MAKEFLAGS=
 # Identity of this package.
 PACKAGE_NAME='repmgr'
 PACKAGE_TARNAME='repmgr'
-PACKAGE_VERSION='5.0'
-PACKAGE_STRING='repmgr 5.0'
+PACKAGE_VERSION='5.0.0'
+PACKAGE_STRING='repmgr 5.0.0'
 PACKAGE_BUGREPORT='repmgr@googlegroups.com'
 PACKAGE_URL='https://repmgr.org/'
 
@@ -1181,7 +1181,7 @@ if test "$ac_init_help" = "long"; then
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures repmgr 5.0 to adapt to many kinds of systems.
+\`configure' configures repmgr 5.0.0 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1242,7 +1242,7 @@ fi
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
-     short | recursive ) echo "Configuration of repmgr 5.0:";;
+     short | recursive ) echo "Configuration of repmgr 5.0.0:";;
    esac
   cat <<\_ACEOF
 
@@ -1316,7 +1316,7 @@ fi
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-repmgr configure 5.0
+repmgr configure 5.0.0
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -1335,7 +1335,7 @@ cat >config.log <<_ACEOF
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by repmgr $as_me 5.0, which was
+It was created by repmgr $as_me 5.0.0, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -2487,7 +2487,7 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by repmgr $as_me 5.0, which was
+This file was extended by repmgr $as_me 5.0.0, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES    = $CONFIG_FILES
@@ -2550,7 +2550,7 @@ _ACEOF
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/\\\\&/g'`"
 ac_cs_version="\\
-repmgr config.status 5.0
+repmgr config.status 5.0.0
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 

configure.in

@@ -1,4 +1,4 @@
-AC_INIT([repmgr], [5.0], [repmgr@googlegroups.com], [repmgr], [https://repmgr.org/])
+AC_INIT([repmgr], [5.0.0], [repmgr@googlegroups.com], [repmgr], [https://repmgr.org/])
 
 AC_COPYRIGHT([Copyright (c) 2010-2019, 2ndQuadrant Ltd.])
 

dbutils.c

@@ -67,6 +67,12 @@ static bool _is_bdr_db(PGconn *conn, PQExpBufferData *output, bool quiet);
 static void _populate_bdr_node_record(PGresult *res, t_bdr_node_info *node_info, int row);
 static void _populate_bdr_node_records(PGresult *res, BdrNodeInfoList *node_list);
 
+/*
+ * This provides a standardized way of logging database errors. Note
+ * that the provided PGconn can be a normal or a replication connection;
+ * no attempt is made to write to the database, only to report the output
+ * of PQerrorMessage().
+ */
 void
 log_db_error(PGconn *conn, const char *query_text, const char *fmt,...)
 {

doc/appendix-packages.xml

@@ -253,20 +253,14 @@
     </indexterm>
 
     <para>
-      &repmgr; <literal>.deb</literal> packages are provided via the
+      &repmgr; <literal>.deb</literal> packages are provided by 2ndQuadrant as well as the
       PostgreSQL Community APT repository, and are available for each community-supported
       PostgreSQL version, currently supported Debian releases, and currently supported
       Ubuntu LTS releases.
     </para>
 
     <sect2 id="packages-apt-repository">
-      <title>APT repository</title>
-
-      <para>
-        &repmgr; packages are available from the  PostgreSQL Community APT repository,
-        which is updated immediately after each &repmgr; release.
-      </para>
-
+      <title>APT repositories</title>
 
       <table id="apt-2ndquadrant-repository">
         <title>2ndQuadrant public repository</title>
@@ -291,7 +285,7 @@
           <tbody>
             <row>
               <entry>Repository URL:</entry>
-              <entry><ulink url="http://apt.postgresql.org/">http://apt.postgresql.org/</ulink></entry>
+              <entry><ulink url="https://apt.postgresql.org/">https://apt.postgresql.org/</ulink></entry>
             </row>
             <row>
               <entry>Repository documentation:</entry>
@@ -382,9 +376,9 @@
       </table>
       <note>
         <para>
-          Instead of using the <application>systemd</application> service command directly,
-          it's recommended to execute <command>pg_ctlcluster</command> (as <literal>root</literal>,
-          either directly or via <command>sudo</command>), e.g.:
+          When using Debian packages, instead of using the <application>systemd</application> service
+          command directly,  it's recommended to execute <command>pg_ctlcluster</command>
+          (as <literal>root</literal>, either directly or via <command>sudo</command>), e.g.:
           <programlisting>
             <command>pg_ctlcluster 11 main [start|stop|restart|reload]</command></programlisting>
         </para>
@@ -477,7 +471,7 @@ repmgr96-4.1.1-0.0git320.g5113ab0.1.el7.x86_64.rpm</programlisting>
       <title>Debian/Ubuntu</title>
       <para>
         An archive of old packages (<literal>3.3.2</literal> and later) for Debian/Ubuntu-based systems is available here:
-        <ulink url="http://atalia.postgresql.org/morgue/r/repmgr/">http://atalia.postgresql.org/morgue/r/repmgr/</ulink>
+        <ulink url="https://apt-archive.postgresql.org/">https://apt-archive.postgresql.org/</ulink>
       </para>
     </sect2>
 

doc/appendix-release-notes.xml

@@ -16,10 +16,35 @@
   </para>
 
 <!-- remember to update the release date in ../repmgr_version.h.in -->
+  <sect1 id="release-5.0.1">
+    <title>Release 5.0.1</title>
+    <para><emphasis>???</emphasis></para>
+    <para>
+      &repmgr; 5.0.1 is a minor release.
+    </para>
+
+    <sect2>
+      <title>Bug fixes</title>
+      <para>
+        <itemizedlist>
+         <listitem>
+            <para>
+              <command><link linkend="repmgr-standby-follow">repmgr standby follow</link></command>:
+	          ensure an existing replication slot is not deleted if the
+              follow target is the node's current upstream.
+            </para>
+	      </listitem>
+
+        </itemizedlist>
+      </para>
+    </sect2>
+
+  </sect1>
+
 
   <sect1 id="release-5.0">
     <title id="release-current">Release 5.0</title>
-    <para><emphasis>?? September ??, 2019</emphasis></para>
+    <para><emphasis>Tue 15 October, 2019</emphasis></para>
 
     <para>
       &repmgr; 5.0 is a major release.
@@ -167,6 +192,10 @@ conninfo='host=node1 user=repmgr dbname=repmgr connect_timeout=2'</programlistin
               function, which enables a standby to be promoted to primary using an SQL
               command.
             </para>
+            <para>
+              For an overview of general changes to replication configuration, see this blog entry:
+              <ulink url="https://www.2ndquadrant.com/en/blog/replication-configuration-changes-in-postgresql-12/">Replication configuration changes in PostgreSQL 12</ulink>
+            </para>
           </listitem>
 
 
@@ -261,7 +290,7 @@ conninfo='host=node1 user=repmgr dbname=repmgr connect_timeout=2'</programlistin
 
   <sect1 id="release-4.4">
     <title>Release 4.4</title>
-    <para><emphasis>27 June, 2019</emphasis></para>
+    <para><emphasis>Thu 27 June, 2019</emphasis></para>
 
     <para>
       &repmgr; 4.4 is a major release.

doc/appendix-support.xml

@@ -43,6 +43,12 @@
 
     <itemizedlist spacing="compact" mark="bullet">
 
+     <listitem>
+      <simpara>
+        PostgreSQL version
+      </simpara>
+     </listitem>
+
      <listitem>
       <simpara>
         &repmgr; version
@@ -68,9 +74,18 @@
       </simpara>
      </listitem>
 
+
      <listitem>
       <simpara>
-        PostgreSQL version
+        PostgreSQL 11 and earlier: contents of the <filename>recovery.conf</filename> file
+        (suitably anonymized if necessary).
+      </simpara>
+     </listitem>
+     <listitem>
+      <simpara>
+        PostgreSQL 12 and later: contents of the <filename>postgresql.auto.conf</filename> file
+        (suitably anonymized if necessary), and whether or not the PostgreSQL data directory
+        contains the files <filename>standby.signal</filename> and/or <filename>recovery.signal</filename>.
       </simpara>
      </listitem>
 
@@ -90,8 +105,8 @@
     </para>
     <para>
       In all cases it is <emphasis>extremely</emphasis> useful to receive
-      information on how to reliably reproduce an issue with as much detail as
-      possible.
+      as much detail as possible on how to reliably reproduce
+      an issue.
     </para>
 
   </sect1>

doc/cloning-standbys.xml

@@ -103,15 +103,28 @@
      <filename>repmgr.conf</filename> should contain the following entries:
     <programlisting>
     barman_host='barman@barmansrv'
-    barman_server='somedb'</programlisting>
+    barman_server='pg'</programlisting>
+   </para>
+   <para>
+     Here <literal>pg</literal> corresponds to a section in Barman's configuration file for a specific
+     server backup configuration, which would look something like:
+     <programlisting>
+[pg]
+description = "Main cluster"
+...
+     </programlisting>
+   </para>
+   <para>
+     More details on Barman configuration can be found in the
+     <ulink url="https://docs.pgbarman.org/">Barman documentation</ulink>'s
+     <ulink url="https://docs.pgbarman.org/#configuration">configuration section</ulink>.
    </para>
-
    <note>
     <para>
      To use a non-default Barman configuration file on the Barman server,
      specify this in <filename>repmgr.conf</filename> with <filename>barman_config</filename>:
      <programlisting>
-      barman_config=/path/to/barman.conf</programlisting>
+      barman_config='/path/to/barman.conf'</programlisting>
     </para>
    </note>
 
@@ -189,8 +202,8 @@
     <filename>repmgr.conf</filename> should include the following lines:
     <programlisting>
     barman_host='barman@barmansrv'
-    barman_server='somedb'
-    restore_command='/usr/bin/barman-wal-restore barmansrv somedb %f %p'</programlisting>
+    barman_server='pg'
+    restore_command='/usr/bin/barman-wal-restore barmansrv pg %f %p'</programlisting>
    </para>
    <note>
     <simpara>
@@ -444,10 +457,8 @@
 
     <para>
      The recommended way to do this is to store the password in the <literal>postgres</literal> system
-     user's <filename>~/.pgpass</filename> file. It's also possible to store the password in the
-     environment variable <varname>PGPASSWORD</varname>, however this is not recommended for
-     security reasons. For more details see the
-     <ulink url="https://www.postgresql.org/docs/current/libpq-pgpass.html">PostgreSQL password file documentation</ulink>.
+     user's <filename>~/.pgpass</filename> file.  For more information on using the password file, see
+     the documentation section <xref linkend="configuration-password-file"/>.
     </para>
 
     <note>
@@ -469,19 +480,6 @@
      will need to be set during any action which causes <filename>recovery.conf</filename> to be
      rewritten, e.g. <xref linkend="repmgr-standby-follow"/>.
     </para>
-    <para>
-     It is of course also possible to include the password value in the <varname>conninfo</varname>
-     string for each node, but this is obviously a security risk and should be avoided.
-    </para>
-    <para>
-      From PostgreSQL 9.6, <application>libpq</application> supports the <varname>passfile</varname>
-      parameter in connection strings, which can be used to specify a password file other than
-      the default <filename>~/.pgpass</filename>.
-    </para>
-    <para>
-      To have &repmgr; write a custom password file in <varname>primary_conninfo</varname>,
-      specify its location in <varname>passfile</varname> in <filename>repmgr.conf</filename>.
-    </para>
    </sect2>
 
    <sect2 id="cloning-advanced-replication-user" xreflabel="Separate replication user">
@@ -497,6 +495,34 @@
      cloning a node or executing <xref linkend="repmgr-standby-follow"/>.
     </para>
    </sect2>
+
+
+   <sect2 id="cloning-advanced-tablespace-mapping" xreflabel="Tablespace mapping">
+    <title>Tablespace mapping</title>
+    <indexterm>
+      <primary>tablespace mapping</primary>
+    </indexterm>
+    <para>
+      &repmgr; provides a <option>tablespace_mapping</option> configuration
+      file option, which will makes it possible to map the tablespace on the source node to
+      a different location on the local node.
+    </para>
+    <para>
+      To use this, add <option>tablespace_mapping</option> to <filename>repmgr.conf</filename>
+      like this:
+<programlisting>
+  tablespace_mapping='/var/lib/pgsql/tblspc1=/data/pgsql/tblspc1'
+</programlisting>
+    </para>
+    <para>
+      where the left-hand value represents the tablespace on the source node,
+      and the right-hand value represents  the tablespace on the standby to be cloned.
+    </para>
+    <para>
+      This parameter can be provided multiple times.
+    </para>
+   </sect2>
+
  </sect1>
 
 

doc/configuration-file-optional-settings.xml

@@ -119,6 +119,27 @@
       </listitem>
     </varlistentry>
 
+    <varlistentry id="repmgr-conf-ssh-options" xreflabel="ssh_options">
+      <term><varname>ssh_options</varname> (<type>string</type>)
+        <indexterm>
+          <primary><varname>ssh_options</varname> configuration file parameter</primary>
+        </indexterm>
+      </term>
+      <listitem>
+        <para>
+          Options to append to the <command>ssh</command> command when executed
+          by &repmgr;.
+        </para>
+        <para>
+          We recommend adding <literal>-q</literal> to suppress any superfluous
+          SSH chatter such as login banners, and also an explicit
+          <option>ConnectTimeout</option> value,
+          e.g.:
+<programlisting>
+ssh_options='-q -o ConnectTimeout=10'</programlisting>
+        </para>
+      </listitem>
+    </varlistentry>
 
   </variablelist>
 </sect1>

doc/configuration-password-management.xml

@@ -0,0 +1,147 @@
+<sect1 id="configuration-password-management" xreflabel="password management">
+
+  <title>Password Management</title>
+  <indexterm>
+    <primary>passwords</primary>
+  </indexterm>
+
+  <sect2 id="configuration-password-management-options" xreflabel="password management options">
+  <title>Password Management Options</title>
+  <indexterm>
+    <primary>passwords</primary>
+    <secondary>options for managing</secondary>
+  </indexterm>
+
+  <para>
+    For security purposes it's desirable to protect database access using a password.
+  </para>
+  <para>
+    PostgreSQL has three ways of providing a password:
+    <itemizedlist spacing="compact" mark="bullet">
+
+       <listitem>
+         <simpara>
+           including the password in the <option>conninfo</option> string
+           (e.g. &quot;<literal>host=node1 dbname=repmgr user=repmgr password=foo</literal>&quot;)
+         </simpara>
+       </listitem>
+
+       <listitem>
+         <simpara>
+           exporting the password as an environment variable (<envar>PGPASSWORD</envar>)
+         </simpara>
+       </listitem>
+
+       <listitem>
+         <simpara>
+           storing the password in a dedicated password file
+         </simpara>
+       </listitem>
+    </itemizedlist>
+  </para>
+  <para>
+    We strongly advise against including the password in the <option>conninfo</option> string, as
+    this will result in the database password being exposed in various places, including in the
+    <filename>repmgr.conf</filename> file, the <literal>repmgr.nodes</literal> table, any output
+    generated by &repmgr; which lists the node <option>conninfo</option> strings (e.g.
+    <link linkend="repmgr-cluster-show">repmgr cluster show</link>) and in the &repmgr; log file,
+    particularly at <option>log_level=DEBUG</option>.
+  </para>
+  <note>
+    <para>
+      Currently &repmgr; does not fully support use of the <option>password</option> option in the
+      <option>conninfo</option> string.
+    </para>
+  </note>
+  <para>
+    Exporting the password as an environment variable (<envar>PGPASSWORD</envar>) is considered
+    less insecure, but the PostgreSQL documentation explicitly recommends against doing this:
+   <blockquote>
+     <attribution><ulink url="https://www.postgresql.org/docs/current/libpq-envars.html">Environment Variables</ulink></attribution>
+     <para>
+       <envar>PGPASSWORD</envar> behaves the same as the <option>password</option>
+       connection parameter. Use of this environment variable
+       is not recommended for security reasons, as some operating systems
+       allow non-root users to see process environment variables via
+       <application>ps</application>; instead consider using a password file.
+     </para>
+    </blockquote>
+
+  </para>
+  <para>
+    The most secure option for managing passwords is to use a dedicated password file; see the following
+    section for more details.
+  </para>
+
+  </sect2>
+
+  <sect2 id="configuration-password-file" xreflabel="password file">
+    <title>Using a password file</title>
+    <indexterm>
+      <primary>pgpass</primary>
+    </indexterm>
+
+    <indexterm>
+      <primary>.pgpass</primary>
+    </indexterm>
+
+    <indexterm>
+      <primary>passwords</primary>
+      <secondary>using a password file</secondary>
+    </indexterm>
+
+    <para>
+      The most secure way of storing passwords is in a password file,
+      which by default is <filename>~/.pgpass</filename>. This file
+      can only be read by the system user who owns the file, and
+      PostgreSQL will refuse to use the file unless read/write
+      permissions are restricted to the file owner. The password(s)
+      contained in the file will not be directly accessed by
+      &repmgr; (or any other libpq-based client software such as <application>psql</application>).
+    </para>
+    <para>
+       For full details see the
+       <ulink url="https://www.postgresql.org/docs/current/libpq-pgpass.html">PostgreSQL password file documentation</ulink>.
+    </para>
+    <para>
+      For use with &repmgr;, the <filename>~/.pgpass</filename> must two entries for each
+      node in the replication cluster: one for the &repmgr; user who accesses the &repmgr; metadatabase,
+      and one for replication connections (regardless of whether a dedicated replication user is used).
+      The file must be present on each node in the replication cluster.
+    </para>
+    <para>
+      A <filename>~/.pgpass</filename> file for a 3-node cluster where the <literal>repmgr</literal> database user
+      is used for both for accessing the  &repmgr; metadatabase and for replication connections would look like this:
+      <programlisting>
+node1:5432:repmgr:repmgr:foo
+node1:5432:replication:repmgr:foo
+node2:5432:repmgr:repmgr:foo
+node2:5432:replication:repmgr:foo
+node3:5432:repmgr:repmgr:foo
+node3:5432:replication:repmgr:foo</programlisting>
+      If a dedicated replication user (here: <literal>repluser</literal>) is in use, the file would look like this:
+      <programlisting>
+node1:5432:repmgr:repmgr:foo
+node1:5432:replication:repluser:foo
+node2:5432:repmgr:repmgr:foo
+node2:5432:replication:repluser:foo
+node3:5432:repmgr:repmgr:foo
+node3:5432:replication:repluser:foo</programlisting>
+
+    </para>
+    <note>
+      <para>
+        It's possible to specify an alternative location for the <filename>~/.pgpass</filename> file, either via
+        the environment variable <envar>PGPASSFILE</envar>, or (from PostgreSQL 9.6) using the
+        <varname>passfile</varname> parameter in connection strings.
+      </para>
+      <para>
+        If using the <varname>passfile</varname> parameter, it's essential to ensure the file is in the same
+        location on all nodes, as when connecting to a remote node, the file referenced is the one on the
+        local node.
+      </para>
+    </note>
+
+  </sect2>
+
+</sect1>

doc/configuration-permissions.xml

@@ -0,0 +1,25 @@
+<sect1 id="configuration-permissions" xreflabel="Database user permissions">
+  <title>repmgr database user permissions</title>
+
+  <indexterm>
+    <primary>configuration</primary>
+    <secondary>database user permissions</secondary>
+  </indexterm>
+
+  <para>
+    &repmgr; requires that the database defined in the <varname>conninfo</varname>
+    setting contains the <literal>repmgr</literal> extension. The database user defined in the
+    <varname>conninfo</varname> setting must be able to access this database and
+    the database objects contained within the extension.
+  </para>
+  <para>
+    The <literal>repmgr</literal> extension can only be installed by a superuser.
+    If the &repmgr; user is a superuser, &repmgr; will create the extension automatically.
+  </para>
+
+  <para>
+    Alternatively, the extension can be created manually by a superuser
+    (with &quot;<command>CREATE EXTENSION repmgr</command>&quot;) before executing
+    <link linkend="repmgr-primary-register">repmgr primary register</link>.
+  </para>
+</sect1>

doc/configuration.xml

@@ -318,23 +318,7 @@
   &configuration-file-optional-settings;
   &configuration-file-log-settings;
   &configuration-file-service-commands;
+  &configuration-permissions;
+  &configuration-password-management;
 
-  <sect1 id="configuration-permissions" xreflabel="Database user permissions">
-    <title>repmgr database user permissions</title>
-
-    <indexterm>
-      <primary>configuration</primary>
-      <secondary>database user permissions</secondary>
-    </indexterm>
-
-    <para>
-      &repmgr; will create an extension database containing objects
-      for administering &repmgr; metadata. The user defined in the <varname>conninfo</varname>
-      setting must be able to access all objects. Additionally, superuser permissions
-      are required to install the &repmgr; extension. The easiest way to do this
-      is create the &repmgr; user as a superuser, however if this is not
-      desirable, the &repmgr; user can be created as a normal user and a
-      superuser specified with <literal>--superuser</literal> when registering a &repmgr; node.
-    </para>
-  </sect1>
 </chapter>

doc/event-notifications.xml

@@ -148,7 +148,7 @@
   the notification types can be filtered to explicitly named ones using the
   <varname>event_notifications</varname> parameter, e.g.:
     <programlisting>
-    event_notifications=primary_register,standby_register,witness_register</programlisting>
+    event_notifications='primary_register,standby_register,witness_register'</programlisting>
 
  </para>
 

doc/filelist.xml

@@ -21,6 +21,8 @@
 <!ENTITY configuration-file-optional-settings      SYSTEM "configuration-file-optional-settings.xml">
 <!ENTITY configuration-file-log-settings      SYSTEM "configuration-file-log-settings.xml">
 <!ENTITY configuration-file-service-commands   SYSTEM "configuration-file-service-commands.xml">
+<!ENTITY configuration-permissions   SYSTEM "configuration-permissions.xml">
+<!ENTITY configuration-password-management   SYSTEM "configuration-password-management.xml">
 <!ENTITY cloning-standbys  SYSTEM "cloning-standbys.xml">
 <!ENTITY promoting-standby  SYSTEM "promoting-standby.xml">
 <!ENTITY follow-new-primary  SYSTEM "follow-new-primary.xml">

doc/install-packages.xml

@@ -26,10 +26,18 @@
 	<ulink url="https://dl.2ndquadrant.com/">public repository</ulink>; see following
 	section for details.
   </para>
+  <note>
+    <para>
+      Currently the <ulink url="https://2ndquadrant.com">2ndQuadrant</ulink>
+	  <ulink url="https://dl.2ndquadrant.com/">public repository</ulink> provides
+      support for RedHat/CentOS versions 5, 6 and 7. Support for version 8 is
+      available via the PGDG repository; see below for details.
+    </para>
+  </note>
   <para>
    RPM packages for &repmgr; are also available via Yum through
-   the PostgreSQL Global Development Group RPM repository
-   (<ulink url="https://yum.postgresql.org/">http://yum.postgresql.org/</ulink>).
+   the PostgreSQL Global Development Group (PGDG) RPM repository
+   (<ulink url="https://yum.postgresql.org/">https://yum.postgresql.org/</ulink>).
    Follow the instructions for your distribution (RedHat, CentOS,
    Fedora, etc.) and architecture as detailed there. Note that it can take some days
    for new &repmgr; packages to become available via the this repository.
@@ -198,7 +206,7 @@ repmgr11.x86_64                        4.4-1.el7                             2nd
   </indexterm>
 
   <para>.deb packages for &repmgr; are available from the
-  PostgreSQL Community APT repository (<ulink url="http://apt.postgresql.org/">http://apt.postgresql.org/</ulink>).
+  PostgreSQL Community APT repository (<ulink url="https://apt.postgresql.org/">https://apt.postgresql.org/</ulink>).
   Instructions can be found in the APT section of the PostgreSQL Wiki
   (<ulink url="https://wiki.postgresql.org/wiki/Apt">https://wiki.postgresql.org/wiki/Apt</ulink>).
   </para>

doc/install-requirements.xml

@@ -99,6 +99,9 @@
             <entry>
               &repmgr; version
             </entry>
+            <entry>
+              Supported?
+            </entry>
             <entry>
               Latest release
             </entry>
@@ -114,6 +117,9 @@
             <entry>
               &repmgr; 5.x
             </entry>
+            <entry>
+              YES
+            </entry>
             <entry>
               <link linkend="release-current">&repmgrversion;</link> (&releasedate;)
             </entry>
@@ -127,7 +133,10 @@
               &repmgr; 4.x
             </entry>
             <entry>
-              <link linkend="release-4.4">4.4</link> (27 June, 2019)
+              NO
+            </entry>
+            <entry>
+              <link linkend="release-4.4">4.4</link> (2019-06-27)
             </entry>
             <entry>
               9.3, 9.4, 9.5, 9.6, 10, 11
@@ -138,6 +147,9 @@
             <entry>
               &repmgr; 3.x
             </entry>
+            <entry>
+              NO
+            </entry>
             <entry>
               <ulink url="https://repmgr.org/release-notes-3.3.2.html">3.3.2</ulink> (2017-05-30)
             </entry>
@@ -150,6 +162,9 @@
             <entry>
               &repmgr; 2.x
             </entry>
+            <entry>
+              NO
+            </entry>
             <entry>
               <ulink url="https://repmgr.org/release-notes-2.0.3.html">2.0.3</ulink> (2015-04-16)
             </entry>
@@ -167,8 +182,23 @@
         The &repmgr; 2.x and 3.x series are no longer maintained or supported.
         We strongly recommend  upgrading to the latest &repmgr; version.
       </para>
+      <para>
+        Following the release of &repmgr; 5.0, there will be no further releases of
+        the &repmgr; 4.x series. Note that &repmgr; 5.x is an incremental development
+        of the 4.x series and &repmgr; 4.x users should upgrade to this as soon as possible.
+      </para>
     </important>
 
+  </sect2>
+
+  <sect2 id="install-postgresql-93-94">
+
+    <title>PostgreSQL 9.3 and 9.4 support</title>
+
+    <indexterm>
+      <primary>PostgreSQL 9.3</primary>
+      <secondary>repmgr support</secondary>
+    </indexterm>
 
     <para>
       Note that some &repmgr; functionality is not available in PostgreSQL 9.3 and PostgreSQL 9.4:
@@ -190,5 +220,26 @@
       </listitem>
     </itemizedlist>
 
+    <important>
+      <para>
+        PostgreSQL 9.3 has reached the end of its community support period (final release was
+        <ulink url="https://www.postgresql.org/docs/9.3/release-9-3-25.html">9.3.25</ulink>
+        in November 2018) and will no longer be updated with security or bugfixes.
+      </para>
+      <para>
+        PostgreSQL 9.4 has reached the end of its community support period (final release was
+        <ulink url="https://www.postgresql.org/docs/9.4/release-9-4-26.html">9.4.26</ulink>
+        in February 2020) and will no longer be updated with security or bugfixes.
+      </para>
+      <para>
+        We recommend that users of these versions migrate to a recent PostgreSQL version
+        as soon as possible.
+      </para>
+      <para>
+        For further details, see the  <ulink url="https://www.postgresql.org/support/versioning/">PostgreSQL Versioning Policy</ulink>.
+      </para>
+    </important>
+
   </sect2>
+
  </sect1>

doc/install-source.xml

@@ -24,8 +24,7 @@
     <listitem>
      <para>
       <literal>Debian</literal> and <literal>Ubuntu</literal>: First
-      add the <ulink
-      url="http://apt.postgresql.org/">apt.postgresql.org</ulink>
+      add the <ulink url="https://apt.postgresql.org/">apt.postgresql.org</ulink>
       repository to your <filename>sources.list</filename> if you
       have not already done so, and ensure the source repository is enabled.
      </para>
@@ -36,8 +35,8 @@
          line in the repository file, which is usually
          <filename>/etc/apt/sources.list.d/pgdg.list</filename>, e.g.:
          <programlisting>
-deb http://apt.postgresql.org/pub/repos/apt/ stretch-pgdg main
-deb-src http://apt.postgresql.org/pub/repos/apt/ stretch-pgdg main</programlisting>
+deb https://apt.postgresql.org/pub/repos/apt/ stretch-pgdg main
+deb-src https://apt.postgresql.org/pub/repos/apt/ stretch-pgdg main</programlisting>
        </para>
      </tip>
      <para>

doc/repmgr-primary-register.xml

@@ -24,10 +24,15 @@
 
     <note>
       <para>
-        It's possibly to install the &repmgr; extension manually before executing
+        &repmgr; will attempt to install the &repmgr; extension as part of this command,
+        however this will fail if the <literal>repmgr</literal> user is not a superuser.
+      </para>
+      <para>
+        It's possible to install the &repmgr; extension manually before executing
         <command>repmgr primary register</command>; in this case &repmgr; will
         detect the presence of the extension and skip that step.
       </para>
+ 
     </note>
 
   </refsect1>
@@ -59,6 +64,21 @@
 
   </refsect1>
 
+  <refsect1>
+    <title>User permission requirements</title>
+    <para>
+      The <literal>repmgr</literal> user must be a superuser in order for &repmgr;
+      to be able to install the <literal>repmgr</literal> extension.
+    </para>
+    <para>
+      If this is not the case, the <literal>repmgr</literal> extension can be installed
+      manually before executing <command>repmgr primary register</command>.
+    </para>
+    <para>
+      A future &repmgr; release will enable the provision of a <option>--superuser</option>
+      name for the installation of the extension.
+    </para>
+  </refsect1>
   <refsect1>
 
     <title>Options</title>

doc/repmgr-standby-promote.xml

@@ -86,6 +86,7 @@
   </refsect1>
 
 
+
   <refsect1>
     <title>Example</title>
     <para>
@@ -101,6 +102,31 @@
   </refsect1>
 
 
+  <refsect1>
+    <title>User permission requirements</title>
+    <para><emphasis>pg_promote() (PostgreSQL 12)</emphasis></para>
+    <para>
+      From PostgreSQL 12, &repmgr; uses the <command>pg_promote()</command> function to promote a standby
+      to primary.
+    </para>
+    <para>
+      By default, execution of <command>pg_promote()</command> is restricted to superusers.
+      If the <literal>repmgr</literal> use is not a superuser, execution permission for this
+      function must be granted with e.g.:
+      <programlisting>
+    GRANT EXECUTE ON FUNCTION pg_catalog.pg_promote TO repmgr</programlisting>
+      </para>
+      <para>
+        Note that permissions are only effective for the database they are granted in, so
+        this <emphasis>must</emphasis> be executed in the &repmgr; database to be effective.
+      </para>
+
+    <para>
+      A future &repmgr; release will relax this restriction by falling back to
+      <command>pg_ctl promote</command>, as used for pre-PostgreSQL 12 versions.
+    </para>
+  </refsect1>
+
   <refsect1>
     <title>Options</title>
     <variablelist>

doc/repmgr-standby-switchover.xml

@@ -63,6 +63,37 @@
   </refsect1>
 
   <refsect1>
+    <title>User permission requirements</title>
+    <para><emphasis>CHECKPOINT</emphasis></para>
+    <para>
+      &repmgr; executes <command>CHECKPOINT</command> on the demotion candidate as part of the shutdown
+      process.
+    </para>
+    <para>
+      Note that <command>CHECKPOINT</command> requires database superuser permissions to execute.
+      If the <literal>repmgr</literal> user is not a superuser, the checkpoint operation will
+      fail, though this is not a fatal error &repmgr; will continue the switchover process.
+    </para>
+    <para><emphasis>pg_promote() (PostgreSQL 12)</emphasis></para>
+    <para>
+      From PostgreSQL 12, &repmgr; uses the <command>pg_promote()</command> function to promote a standby
+      to primary.
+    </para>
+    <para>
+      By default, execution of <command>pg_promote()</command> is restricted to superusers.
+      If the <literal>repmgr</literal> use is not a superuser, execution permission for this
+      function must be granted with e.g.:
+      <programlisting>
+    GRANT EXECUTE ON FUNCTION pg_catalog.pg_promote TO repmgr</programlisting>
+    </para>
+    <para>
+      A future &repmgr; release will relax this restriction by falling back to
+      <command>pg_ctl promote</command>, as used for pre-PostgreSQL 12 versions.
+    </para>
+  </refsect1>
+
+  <refsect1>
+
     <title>Options</title>
     <variablelist>
 

doc/repmgrd-automatic-failover.xml

@@ -192,8 +192,8 @@
     connected. Beginning with <link linkend="release-4.4">&repmgr; 4.4</link>
     it is now possible for the affected standbys to build a consensus about whether
     the primary is still available to some standbys (&quot;primary visibility consensus&quot;).
-    This is done by polling each standby for the time it last saw the primary;
-    if any have seen the primary very recently, it's reasonable
+    This is done by polling each standby (and the witness, if present) for the time it last saw the
+    primary; if any have seen the primary very recently, it's reasonable
     to infer that the primary is still available and a failover should not be started.
   </para>
 
@@ -205,9 +205,10 @@
     <programlisting>$ repmgr -f /etc/repmgr.conf service status
  ID | Name  | Role    | Status    | Upstream | repmgrd | PID   | Paused? | Upstream last seen
 ----+-------+---------+-----------+----------+---------+-------+---------+--------------------
- 1  | node1 | primary | * running |          | running | 96563 | no      | n/a
- 2  | node2 | standby |   running | node1    | running | 96572 | no      | 1 second(s) ago
- 3  | node3 | standby |   running | node1    | running | 96584 | no      | 0 second(s) ago</programlisting>
+ 1  | node1 | primary | * running |          | running | 27259 | no      | n/a
+ 2  | node2 | standby |   running | node1    | running | 27272 | no      | 1 second(s) ago
+ 3  | node3 | standby |   running | node1    | running | 27282 | no      | 0 second(s) ago
+ 4  | node4 | witness | * running | node1    | running | 27298 | no      | 1 second(s) ago</programlisting>
 
   </para>
 

doc/repmgrd-bdr.xml

@@ -94,7 +94,7 @@
         replication_type='bdr'
 
         # Event notification configuration
-        event_notifications=bdr_failover
+        event_notifications='bdr_failover'
         event_notification_command='/path/to/bdr-pgbouncer.sh %n %e %s "%c" "%a" >> /tmp/bdr-failover.log 2>&1'
 
         # repmgrd options

doc/repmgrd-configuration.xml

@@ -15,9 +15,13 @@
   </para>
   <para>
     &repmgrd; can be configured to provide failover
-    capability in case the primary upstream node becomes unreachable, and/or
+    capability in case the primary or upstream node becomes unreachable, and/or
     provide monitoring data to the &repmgr; metadatabase.
   </para>
+  <para>
+    From &repmgr; 4.4, when running on the primary node, &repmgrd; can also monitor
+    standby disconnections/reconnections (see <xref linkend="repmgrd-primary-child-disconnection"/>).
+  </para>
 
   <sect1 id="repmgrd-basic-configuration">
     <title>repmgrd configuration</title>
@@ -394,8 +398,8 @@
             </indexterm>
 
             <para>
-              If <literal>true</literal>, only continue with failover if no standbys have seen
-			  the primary node recently.
+              If <literal>true</literal>, only continue with failover if no standbys
+              (or the witness server, if present) have seen the primary node recently.
             </para>
             <note>
               <para>
@@ -486,6 +490,23 @@
 
     </sect2>
 
+
+    <sect2 id="repmgrd-automatic-failover-configuration-pgbouncer-fencing">
+      <title>Configuring &repmgrd; and pgbouncer to fence a failed primary node</title>
+      <indexterm>
+        <primary>fencing</primary>
+        <secondary>using repmgrd and pgbouncer to fence a failed primary node</secondary>
+      </indexterm>
+      <indexterm>
+        <primary>PgBouncer</primary>
+        <secondary>using repmgrd and pgbouncer to fence a failed primary node</secondary>
+      </indexterm>
+      <para>
+        For further details and a reference implementation, see the separate document
+        <ulink url="https://github.com/2ndQuadrant/repmgr/blob/master/doc/repmgrd-node-fencing.md">Fencing a failed master node with repmgrd and PgBouncer</ulink>.
+      </para>
+    </sect2>
+
     <sect2 id="postgresql-service-configuration">
       <title>PostgreSQL service configuration</title>
 
@@ -566,7 +587,8 @@ repmgrd_service_stop_command='sudo systemctl repmgr12 stop'
         the option <option>monitor_interval_secs</option> (see above).
       </para>
       <para>
-        For more details on monitoring, see <xref linkend="repmgrd-monitoring"/>.
+        For more details on monitoring, see <xref linkend="repmgrd-monitoring"/>. For information on
+        monitoring standby disconnections, see <xref linkend="repmgrd-primary-child-disconnection"/>.
       </para>
     </sect2>
 

doc/repmgrd-node-fencing.md

@@ -146,7 +146,7 @@ Script and template file should be installed on each node where `repmgrd` is run
 Finally, set `promote_command` in `repmgr.conf` on each node to
 point to the custom promote script:
 
-    promote_command=/var/lib/postgres/repmgr/promote.sh
+    promote_command='/var/lib/postgres/repmgr/promote.sh'
 
 and reload/restart any running `repmgrd` instances for the changes to take
 effect.

doc/switchover.xml

@@ -186,6 +186,7 @@
       NOTICE: local node "node2" (ID: 2) will be promoted to primary; current primary "node1" (ID: 1) will be demoted to standby
       INFO: following shutdown command would be run on node "node1":
         "pg_ctl -l /var/log/postgresql/startup.log -D '/var/lib/postgresql/data' -m fast -W stop"
+      INFO: parameter "shutdown_check_timeout" is set to 60 seconds
     </programlisting>
    </para>
 

repmgr-action-cluster.c

@@ -247,13 +247,13 @@ do_cluster_show(void)
 		if (cell->node_info->replication_info->timeline_id == UNKNOWN_TIMELINE_ID)
 		{
 			/* display "?" */
-			headers_show[SHOW_PRIORITY].cur_length = 1;
+			headers_show[SHOW_TIMELINE_ID].cur_length = 1;
 		}
 		else
 		{
 			initPQExpBuffer(&buf);
 			appendPQExpBuffer(&buf, "%i", cell->node_info->replication_info->timeline_id);
-			headers_show[SHOW_PRIORITY].cur_length = strlen(buf.data);
+			headers_show[SHOW_TIMELINE_ID].cur_length = strlen(buf.data);
 			termPQExpBuffer(&buf);
 		}
 

repmgr-action-primary.c

@@ -106,7 +106,7 @@ do_primary_register(void)
 	current_primary_id = get_primary_node_id(conn);
 	if (current_primary_id != NODE_NOT_FOUND && current_primary_id != config_file_options.node_id)
 	{
-		log_debug("XXX %i", current_primary_id);
+		log_debug("current active primary node ID is %i", current_primary_id);
 		primary_conn = establish_primary_db_connection(conn, false);
 
 		if (PQstatus(primary_conn) == CONNECTION_OK)

repmgr-action-standby.c

@@ -958,6 +958,13 @@ _do_create_recovery_conf(void)
 		exit(ERR_BAD_CONFIG);
 	}
 
+
+	/* check connection */
+	source_conn = establish_db_connection_by_params(&source_conninfo, true);
+
+	/* Verify that source is a supported server version */
+	(void) check_server_version(source_conn, "source node", true, NULL);
+
 	/*
 	 * Do some sanity checks on the data directory to make sure
 	 * it contains a valid but dormant instance
@@ -967,14 +974,17 @@ _do_create_recovery_conf(void)
 		case DIR_ERROR:
 			log_error(_("unable to access specified data directory \"%s\""), local_data_directory);
 			log_detail("%s", strerror(errno));
+			PQfinish(source_conn);
 			exit(ERR_BAD_CONFIG);
 			break;
 		case DIR_NOENT:
 			log_error(_("specified data directory \"%s\" does not exist"), local_data_directory);
+			PQfinish(source_conn);
 			exit(ERR_BAD_CONFIG);
 			break;
 		case DIR_EMPTY:
 			log_error(_("specified data directory \"%s\" is empty"), local_data_directory);
+			PQfinish(source_conn);
 			exit(ERR_BAD_CONFIG);
 			break;
 		case DIR_NOT_EMPTY:
@@ -982,6 +992,7 @@ _do_create_recovery_conf(void)
 			if (!is_pg_dir(local_data_directory))
 			{
 				log_error(_("specified data directory \"%s\" does not contain a PostgreSQL instance"), local_data_directory);
+				PQfinish(source_conn);
 				exit(ERR_BAD_CONFIG);
 			}
 
@@ -991,7 +1002,16 @@ _do_create_recovery_conf(void)
 				{
 					log_error(_("specified data directory \"%s\" appears to contain a running PostgreSQL instance"),
 							  local_data_directory);
-					log_hint(_("use -F/--force to create \"recovery.conf\" anyway"));
+
+					if (PQserverVersion(source_conn) >= 120000)
+					{
+						log_hint(_("use -F/--force to create replication configuration anyway"));
+					}
+					else
+					{
+						log_hint(_("use -F/--force to create \"recovery.conf\" anyway"));
+					}
+
 					exit(ERR_BAD_CONFIG);
 				}
 
@@ -999,11 +1019,25 @@ _do_create_recovery_conf(void)
 
 				if (runtime_options.dry_run == true)
 				{
-					log_warning(_("\"recovery.conf\" would be created in an active data directory"));
+					if (PQserverVersion(source_conn) >= 120000)
+					{
+						log_warning(_("replication configuration would be created in an active data directory"));
+					}
+					else
+					{
+						log_warning(_("\"recovery.conf\" would be created in an active data directory"));
+					}
 				}
 				else
 				{
-					log_warning(_("creating \"recovery.conf\" in an active data directory"));
+					if (PQserverVersion(source_conn) >= 120000)
+					{
+						log_warning(_("creating replication configuration in an active data directory"));
+					}
+					else
+					{
+						log_warning(_("creating \"recovery.conf\" in an active data directory"));
+					}
 				}
 			}
 			break;
@@ -1011,8 +1045,6 @@ _do_create_recovery_conf(void)
 			break;
 	}
 
-	/* check connection */
-	source_conn = establish_db_connection_by_params(&source_conninfo, true);
 
 	/* determine node for primary_conninfo */
 
@@ -3067,8 +3099,8 @@ do_standby_follow_internal(PGconn *primary_conn, PGconn *follow_target_conn, t_n
 	}
 
 	/*
-	 * store the original upstream node id so we can delete the
-	 * replication slot, if exists
+	 * Store the original upstream node id so we can delete the
+	 * replication slot, if it exists.
 	 */
 	if (local_node_record.upstream_node_id != UNKNOWN_NODE_ID)
 	{
@@ -3079,9 +3111,17 @@ do_standby_follow_internal(PGconn *primary_conn, PGconn *follow_target_conn, t_n
 		original_upstream_node_id = follow_target_node_record->node_id;
 	}
 
-	if (config_file_options.use_replication_slots && runtime_options.host_param_provided == false && original_upstream_node_id != UNKNOWN_NODE_ID)
+	if (config_file_options.use_replication_slots && runtime_options.host_param_provided == false)
 	{
-		remove_old_replication_slot = true;
+		/*
+		 * Only attempt to delete the old replication slot if the old upstream
+		 * node is known and is different to the follow target node.
+		 */
+		if (original_upstream_node_id != UNKNOWN_NODE_ID
+		 && original_upstream_node_id != follow_target_node_record->node_id)
+		{
+			remove_old_replication_slot = true;
+		}
 	}
 
 	/* Fetch original upstream's record */
@@ -3237,8 +3277,6 @@ do_standby_follow_internal(PGconn *primary_conn, PGconn *follow_target_conn, t_n
 	 * Note that if this function is called by do_standby_switchover(), the
 	 * "repmgr node rejoin" command executed on the demotion candidate may already
 	 * have removed the slot, so there may be nothing to do.
-	 *
-	 * XXX check if former upstream is current primary?
 	 */
 
 	if (remove_old_replication_slot == true)
@@ -3741,7 +3779,9 @@ do_standby_switchover(void)
 
 	if (runtime_options.dry_run == true)
 	{
-		log_info(_("able to execute \"%s\" on remote host \"localhost\""), progname());
+		log_info(_("able to execute \"%s\" on remote host \"%s\""),
+				 progname(),
+				 remote_host);
 	}
 
 	/*
@@ -3902,7 +3942,7 @@ do_standby_switchover(void)
 							exit(ERR_SWITCHOVER_FAIL);
 						}
 
-						log_warning(_("number of pending archive files on demotion candidate \"%s\" is critical"),
+						log_warning(_("number of pending archive files on demotion candidate \"%s\" exceeds the critical threshold"),
 									remote_node_record.node_name);
 						log_detail(_("%i pending archive files (critical threshold: %i)"),
 								   files, threshold);
@@ -3912,7 +3952,7 @@ do_standby_switchover(void)
 
 				case CHECK_STATUS_WARNING:
 					{
-						log_warning(_("number of pending archive files on demotion candidate \"%s\" is warning"),
+						log_warning(_("number of pending archive files on demotion candidate \"%s\" exceeds the warning threshold"),
 									remote_node_record.node_name);
 						log_detail(_("%i pending archive files (warning threshold: %i)"),
 								   files, threshold);
@@ -4321,6 +4361,9 @@ do_standby_switchover(void)
 				 remote_node_record.node_name,
 				 shutdown_command);
 
+		log_info(_("parameter \"shutdown_check_timeout\" is set to %i seconds"),
+				 config_file_options.shutdown_check_timeout);
+
 		clear_node_info_list(&sibling_nodes);
 
 		key_value_list_free(&remote_config_files);
@@ -5489,7 +5532,7 @@ check_upstream_config(PGconn *conn, int server_version_num, t_node_info *upstrea
 	{
 		if (i == 0)
 		{
-			log_error(_("parameter 'hot_standby' must be set to 'on'"));
+			log_error(_("parameter \"hot_standby\" must be set to \"on\""));
 		}
 
 		if (exit_on_error == true)
@@ -5507,7 +5550,7 @@ check_upstream_config(PGconn *conn, int server_version_num, t_node_info *upstrea
 	{
 		if (pg_setting_ok == true)
 		{
-			log_error(_("parameter \"max_wal_senders\" must be set to be at least 1 %i"), i);
+			log_error(_("parameter \"max_wal_senders\" must be set to be at least %i"), i);
 			log_hint(_("\"max_wal_senders\" should be set to at least the number of expected standbys"));
 		}
 
@@ -6072,7 +6115,7 @@ run_basebackup(t_node_info *node_record)
 				if (record_status == RECORD_FOUND)
 				{
 					log_verbose(LOG_INFO,
-								_("replication slot \"%s\" aleady exists on upstream node %i"),
+								_("replication slot \"%s\" already exists on upstream node %i"),
 								node_record->slot_name,
 								upstream_node_id);
 					slot_exists_on_upstream = true;
@@ -7952,7 +7995,7 @@ do_standby_help(void)
 			 "                                        when the intended upstream server does not yet exist\n"));
 	printf(_("  --upstream-node-id                  ID of the upstream node to replicate from (optional, defaults to primary node)\n"));
 	printf(_("  --without-barman                    do not use Barman even if configured\n"));
-	printf(_("  --recovery-conf-only                create \"recovery.conf\" file for a previously cloned instance\n"));
+	printf(_("  --recovery-conf-only                generate replication configuration for a previously cloned instance\n"));
 
 	puts("");
 

repmgr-client.c

@@ -2456,6 +2456,8 @@ action_name(const int action)
 			return "STANDBY PROMOTE";
 		case STANDBY_FOLLOW:
 			return "STANDBY FOLLOW";
+		case STANDBY_SWITCHOVER:
+			return "STANDBY SWITCHOVER";
 
 		case WITNESS_REGISTER:
 			return "WITNESS REGISTER";
@@ -2475,9 +2477,13 @@ action_name(const int action)
 			return "NODE REJOIN";
 		case NODE_SERVICE:
 			return "NODE SERVICE";
+		case NODE_CONTROL:
+			return "NODE CONTROL";
 
 		case CLUSTER_SHOW:
 			return "CLUSTER SHOW";
+		case CLUSTER_CLEANUP:
+			return "CLUSTER CLEANUP";
 		case CLUSTER_EVENT:
 			return "CLUSTER EVENT";
 		case CLUSTER_MATRIX:
@@ -2844,15 +2850,25 @@ create_repmgr_extension(PGconn *conn)
 int
 check_server_version(PGconn *conn, char *server_type, bool exit_on_error, char *server_version_string)
 {
-	int			conn_server_version_num = get_server_version(conn, server_version_string);
+	char		version_string[MAXVERSIONSTR] = "";
+	int			conn_server_version_num = get_server_version(conn, version_string);
+
+	/* Copy the version string, if the caller wants it */
+	if (server_version_string != NULL)
+		strncpy(server_version_string, version_string, MAXVERSIONSTR);
 
 	if (conn_server_version_num < MIN_SUPPORTED_VERSION_NUM)
 	{
 		if (conn_server_version_num > 0)
+		{
 			log_error(_("%s requires %s to be PostgreSQL %s or later"),
 					  progname(),
 					  server_type,
 					  MIN_SUPPORTED_VERSION);
+			log_detail(_("%s server version is %s"),
+					   server_type,
+					   version_string);
+		}
 
 		if (exit_on_error == true)
 		{
@@ -2863,6 +2879,38 @@ check_server_version(PGconn *conn, char *server_type, bool exit_on_error, char *
 		return UNKNOWN_SERVER_VERSION_NUM;
 	}
 
+	/*
+	 * If it's clear a particular repmgr feature branch won't be able to support
+	 * PostgreSQL from a particular PostgreSQL release onwards (e.g. 4.4 with PostgreSQL
+	 * 12 and later due to recovery.conf removal), set MAX_UNSUPPORTED_VERSION and
+	 * MAX_UNSUPPORTED_VERSION_NUM in "repmgr.h" to define the first PostgreSQL
+	 * version which can't be suppored.
+	 */
+#ifdef MAX_UNSUPPORTED_VERSION_NUM
+	if (conn_server_version_num >= MAX_UNSUPPORTED_VERSION_NUM)
+	{
+		if (conn_server_version_num > 0)
+		{
+			log_error(_("%s %s does not support PostgreSQL %s or later"),
+					  progname(),
+					  REPMGR_VERSION,
+					  MAX_UNSUPPORTED_VERSION);
+			log_detail(_("%s server version is %s"),
+					   server_type,
+					   version_string);
+			log_hint(_("For details of supported versions see: https://repmgr.org/docs/current/install-requirements.html#INSTALL-COMPATIBILITY-MATRIX"));
+		}
+
+		if (exit_on_error == true)
+		{
+			PQfinish(conn);
+			exit(ERR_BAD_CONFIG);
+		}
+
+		return UNKNOWN_SERVER_VERSION_NUM;
+	}
+#endif
+
 	return conn_server_version_num;
 }
 

repmgr.conf.sample

@@ -21,7 +21,7 @@
 # repmgr and repmgrd require the following items to be explicitly configured.
 
 
-#node_id=    	     	     	 # A unique integer greater than zero
+#node_id=			 # A unique integer greater than zero
 #node_name=''			 # An arbitrary (but unique) string; we recommend
 				 # using the server's hostname or another identifier
 				 # unambiguously associated with the server to avoid
@@ -29,8 +29,8 @@
 				 # node's current role, e.g. 'primary' or 'standby1',
 				 # as roles can change and it will be confusing if
 				 # the current primary is called 'standby1'.
-                                 # The string's maximum length is 63 characters and it should
-                                 # contain only printable ASCII characters.
+				 # The string's maximum length is 63 characters and it should
+				 # contain only printable ASCII characters.
 
 #conninfo=''			 # Database connection information as a conninfo string.
 				 # All servers in the cluster must be able to connect to
@@ -77,7 +77,7 @@
 #location='default'		 # An arbitrary string defining the location of the node; this
 				 # is used during failover to check visibility of the
 				 # current primary node. For further details see:
-                                 #   https://repmgr.org/docs/current/repmgrd-network-split.html
+				 #   https://repmgr.org/docs/current/repmgrd-network-split.html
 
 #use_replication_slots=no	 # whether to use physical replication slots
 				 # NOTE: when using replication slots,
@@ -160,12 +160,13 @@
 
 #repmgr_bindir=''			# Path to repmgr binary directory (location of the repmgr
 					# binary. Only needed if the repmgr executable is not in
-                                        # the system $PATH or the path defined in "pg_bindir".
+					# the system $PATH or the path defined in "pg_bindir".
 
-#use_primary_conninfo_password=false	# explicitly set "password" in recovery.conf's
-					# "primary_conninfo" parameter using the value contained
-					# in the environment variable PGPASSWORD
+#use_primary_conninfo_password=false	# explicitly set "password" in "primary_conninfo"
+					# using the value contained in the environment variable
+					# PGPASSWORD
 #passfile=''				# path to .pgpass file to include in "primary_conninfo"
+
 #------------------------------------------------------------------------------
 # external command options
 #------------------------------------------------------------------------------
@@ -179,7 +180,7 @@
 #   rsync_options=--archive --checksum --compress --progress --rsh="ssh -o \"StrictHostKeyChecking no\""
 #   ssh_options=-o "StrictHostKeyChecking no"
 
-#pg_ctl_options='' 			# Options to append to "pg_ctl"
+#pg_ctl_options=''			# Options to append to "pg_ctl"
 #pg_basebackup_options=''		# Options to append to "pg_basebackup"
 #rsync_options=''			# Options to append to "rsync"
 ssh_options='-q -o ConnectTimeout=10'	# Options to append to "ssh"
@@ -197,19 +198,19 @@ ssh_options='-q -o ConnectTimeout=10'	# Options to append to "ssh"
 #   tablespace_mapping=/path/to/original/tablespace=/path/to/new/tablespace
 #   restore_command = 'cp /path/to/archived/wals/%f %p'
 
-#tablespace_mapping=''	  		# Tablespaces can be remapped from one
+#tablespace_mapping=''			# Tablespaces can be remapped from one
 					# file system location to another. This
 					# parameter can be provided multiple times.
 
-#restore_command=''			# This will be placed in the recovery.conf file generated
-					# by repmgr.
+#restore_command=''			# This will be included in the recovery configuration
+					# generated by repmgr.
 
-#archive_cleanup_command=''		# This will be placed in the recovery.conf file generated
-					# by repmgr. Note we recommend using Barman for managing
-					# WAL archives (see: https://www.pgbarman.org )
+#archive_cleanup_command=''		# This will be included in the recovery configuration
+					# generated by repmgr. Note we recommend using Barman for
+					# managing WAL archives (see: https://www.pgbarman.org )
 
-#recovery_min_apply_delay=		# If provided, "recovery_min_apply_delay" in recovery.conf
-					# will be set to this value (PostgreSQL 9.4 and later).
+#recovery_min_apply_delay=		# If provided, "recovery_min_apply_delay" will be set to
+					# this value (PostgreSQL 9.4 and later).
 
 
 #------------------------------------------------------------------------------
@@ -296,17 +297,17 @@ ssh_options='-q -o ConnectTimeout=10'	# Options to append to "ssh"
 					# (default: 100)
 
 #connection_check_type=ping		# How to check availability of the upstream node; valid options:
-                                        #  'ping': use PQping() to check if the node is accepting connections
-                                        #  'connection': execute a throwaway query on the current connection
+					#  'ping': use PQping() to check if the node is accepting connections
+					#  'connection': execute a throwaway query on the current connection
 #reconnect_attempts=6			# Number of attempts which will be made to reconnect to an unreachable
 					# primary (or other upstream node)
 #reconnect_interval=10			# Interval between attempts to reconnect to an unreachable
 					# primary (or other upstream node)
-#promote_command=			# command repmgrd executes when promoting a new primary; use something like:
+#promote_command=''			# command repmgrd executes when promoting a new primary; use something like:
 					#
 					#     repmgr standby promote -f /etc/repmgr.conf
 					#
-#follow_command=			# command repmgrd executes when instructing a standby to follow a new primary;
+#follow_command=''			# command repmgrd executes when instructing a standby to follow a new primary;
 					# use something like:
 					#
 					#     repmgr standby follow -f /etc/repmgr.conf -W --upstream-node-id=%n
@@ -318,8 +319,8 @@ ssh_options='-q -o ConnectTimeout=10'	# Options to append to "ssh"
 					# for the the local node to restart and become ready to accept connections after
 					# executing "follow_command" (defaults to the value set in "standby_reconnect_timeout")
 
-#monitoring_history=no                  # Whether to write monitoring data to the "montoring_history" table
-#monitor_interval_secs=2                # Interval (in seconds) at which to write monitoring data
+#monitoring_history=no			# Whether to write monitoring data to the "montoring_history" table
+#monitor_interval_secs=2		# Interval (in seconds) at which to write monitoring data
 #degraded_monitoring_timeout=-1		# Interval (in seconds) after which repmgrd will terminate if the
 					# server(s) being monitored are no longer available. -1 (default)
 					# disables the timeout completely.
@@ -348,7 +349,7 @@ ssh_options='-q -o ConnectTimeout=10'	# Options to append to "ssh"
 					# an error, pause the specified amount of seconds before rerunning the election.
 					#
 					# The following items are relevant for repmgrd running on the primary,
-                                        # and will be ignored on non-primary nodes
+					# and will be ignored on non-primary nodes
 #child_nodes_check_interval=5		# Interval (in seconds) to check for attached child nodes (standbys)
 #child_nodes_connected_min_count=-1	# Minimum number of child nodes which must remain connected, otherwise
 					# disconnection command will be triggered
@@ -373,7 +374,7 @@ ssh_options='-q -o ConnectTimeout=10'	# Options to append to "ssh"
 # NOTE: These commands must be runnable on remote nodes as well for switchover
 # to function correctly.
 #
-# If you use sudo, the user repmgr runs as (usually 'postgres')  must have
+# If you use sudo, the user repmgr runs as (usually 'postgres')	 must have
 # passwordless sudo access to execute the command.
 #
 # For example, to use systemd, you can set
@@ -386,8 +387,8 @@ ssh_options='-q -o ConnectTimeout=10'	# Options to append to "ssh"
 #    # this is required when running sudo over ssh without -t:
 #    Defaults:postgres !requiretty
 #    postgres ALL = NOPASSWD: /usr/bin/systemctl stop postgresql-9.6, \
-#       /usr/bin/systemctl start postgresql-9.6, \
-#       /usr/bin/systemctl restart postgresql-9.6
+#	/usr/bin/systemctl start postgresql-9.6, \
+#	/usr/bin/systemctl restart postgresql-9.6
 #
 # Debian/Ubuntu users: use "sudo pg_ctlcluster" to execute service control commands.
 #
@@ -414,7 +415,7 @@ ssh_options='-q -o ConnectTimeout=10'	# Options to append to "ssh"
 
 # Various warning/critical thresholds used by "repmgr node check".
 
-#archive_ready_warning=16  	      	# repmgr node check --archive-ready
+#archive_ready_warning=16		# repmgr node check --archive-ready
 #archive_ready_critical=128		#
 					# Numbers of files pending archiving via PostgreSQL's
 					# "archive_command" configuration parameter. If
@@ -439,8 +440,8 @@ ssh_options='-q -o ConnectTimeout=10'	# Options to append to "ssh"
 # BDR monitoring options
 #------------------------------------------------------------------------------
 
-#bdr_local_monitoring_only=false         # Only monitor the local node; no checks will be
+#bdr_local_monitoring_only=false	 # Only monitor the local node; no checks will be
 					 # performed on the other node
-#bdr_recovery_timeout                    # If a BDR node was offline and has become available
+#bdr_recovery_timeout			 # If a BDR node was offline and has become available
 					 # maximum length of time in seconds to wait for the
 					 # node to reconnect to the cluster

repmgr_version.h.in

@@ -1,5 +1,5 @@
 #define REPMGR_VERSION_DATE ""
-#define REPMGR_VERSION "5.0"
+#define REPMGR_VERSION "5.0.0"
 #define REPMGR_VERSION_NUM 50000
-#define REPMGR_RELEASE_DATE "2019-XX-XX"
+#define REPMGR_RELEASE_DATE "2019-10-15"
 #define PG_ACTUAL_VERSION_NUM 

repmgrd-physical.c

@@ -3655,7 +3655,7 @@ follow_new_primary(int new_primary_id)
 		else
 		{
 			new_primary_ok = false;
-			log_warning(_("new primary is not in recovery"));
+			log_warning(_("new primary is in recovery"));
 			close_connection(&upstream_conn);
 		}
 	}
@@ -3848,7 +3848,7 @@ witness_follow_new_primary(int new_primary_id)
 				break;
 			case RECTYPE_STANDBY:
 				new_primary_ok = false;
-				log_warning(_("new primary is not in recovery"));
+				log_warning(_("new primary is in recovery"));
 				break;
 			case RECTYPE_UNKNOWN:
 				new_primary_ok = false;
@@ -4029,7 +4029,9 @@ do_election(NodeInfoList *sibling_nodes, int *new_primary_id)
 	}
 	else
 	{
-		log_info(_("primary and this node have the same location (\"%s\")"),
+		log_info(_("primary node  \"%s\" (ID: %i) and this node have the same location (\"%s\")"),
+				 upstream_node_info.node_name,
+				 upstream_node_info.node_id,
 				 local_node_info.location);
 	}
 
@@ -4269,7 +4271,9 @@ do_election(NodeInfoList *sibling_nodes, int *new_primary_id)
 			else
 			{
 				nodes_with_primary_still_visible++;
-				log_notice(_("node %i last saw primary node %i second(s) ago, considering primary still visible"),
+				log_notice(_("%s node \"%s\" (ID: %i) last saw primary node %i second(s) ago, considering primary still visible"),
+						   get_node_type_string(cell->node_info->type),
+						   cell->node_info->node_name,
 						   cell->node_info->node_id,
 						   sibling_replication_info.upstream_last_seen);
 				appendPQExpBuffer(&nodes_with_primary_visible,
@@ -4281,7 +4285,9 @@ do_election(NodeInfoList *sibling_nodes, int *new_primary_id)
 		}
 		else
 		{
-			log_info(_("node %i last saw primary node %i second(s) ago"),
+			log_info(_("%s node \"%s\" (ID: %i) last saw primary node %i second(s) ago"),
+					 get_node_type_string(cell->node_info->type),
+					 cell->node_info->node_name,
 					 cell->node_info->node_id,
 					 sibling_replication_info.upstream_last_seen);
 		}