Update Authors and version on README

Signed-off-by: Martín Marqués <martin.marques@enterprisedb.com>

HISTORY

@@ -1,3 +1,9 @@
+5.4.1   2023-??-??
+        repmgrd: ensure witness node metadata is updated (Ian)
+
+5.4.0   2023-03-16
+        Support cloning replicas using pg-backup-api
+
 5.3.3   2022-10-17
         Support for PostgreSQL added
         repmgrd: ensure event notification script is called for event

README.md

@@ -7,8 +7,8 @@ replication capabilities with utilities to set up standby servers, monitor
 replication, and perform administrative tasks such as failover or switchover
 operations.
 
-The most recent `repmgr` version (5.3.2) supports all PostgreSQL versions from
-9.5 to 14. PostgreSQL 9.4 is also supported, with some restrictions.
+The most recent `repmgr` version (5.4.1) supports all PostgreSQL versions from
+10 to 16.
 
 `repmgr` is distributed under the GNU GPL 3 and maintained by EnterpriseDB.
 
@@ -56,8 +56,6 @@ There is a mailing list/forum to discuss contributions or issues:
 
 * https://groups.google.com/group/repmgr
 
-The IRC channel #repmgr is registered with freenode.
-
 Please report bugs and other issues to:
 
 * https://github.com/EnterpriseDB/repmgr
@@ -69,6 +67,14 @@ news are always welcome.
 
 Thanks from the repmgr core team.
 
+* Ian Barwick
+* Israel Barth
+* Mario González
+* Martín Marqués
+* Gianni Ciolli
+
+Past contributors:
+
 * Jaime Casanova
 * Abhijit Menon-Sen
 * Simon Riggs

dbutils.c

@@ -1913,15 +1913,47 @@ can_disable_walsender(PGconn *conn)
 	if (is_superuser_connection(conn, NULL) == true)
 		return true;
 
-	/*
-	 * As of PostgreSQL 14, it is not possible for a non-superuser
-	 * to execute ALTER SYSTEM, so further checks are superfluous.
-	 * This will need modifying for PostgreSQL 15.
-	 */
-	log_warning(_("\"standby_disconnect_on_failover\" specified, but repmgr user is not a superuser"));
-	log_detail(_("superuser permission required to disable standbys on failover"));
+	PQExpBufferData query;
+	PGresult   *res;
+	bool		has_alter_system_priv = false;
 
-	return false;
+	/* GRANT ALTER SYSTEM available from PostgreSQL 15 */
+	if (PQserverVersion(conn) >= 150000)
+	{
+		initPQExpBuffer(&query);
+		appendPQExpBufferStr(&query,
+						" SELECT pg_catalog.has_parameter_privilege('wal_retrieve_retry_interval', 'ALTER SYSTEM') ");
+
+		res = PQexec(conn, query.data);
+
+		if (PQresultStatus(res) != PGRES_TUPLES_OK)
+		{
+			log_db_error(conn, query.data,
+					_("can_disable_walsender(): unable to query user parameter privileges"));
+		}
+		else
+		{
+			has_alter_system_priv = atobool(PQgetvalue(res, 0, 0));
+		}
+		termPQExpBuffer(&query);
+		PQclear(res);
+	}
+
+	if (has_alter_system_priv == false)
+	{
+		log_warning(_("\"standby_disconnect_on_failover\" specified, but repmgr user is not authorized to perform ALTER SYSTEM wal_retrieve_retry_interval"));
+
+		if (PQserverVersion(conn) >= 150000)
+		{
+			log_detail(_("superuser or ALTER SYSTEM wal_retrieve_retry_interval permission required to disable standbys on failover"));
+		}
+		else
+		{
+			log_detail(_("superuser permission required to disable standbys on failover"));
+		}
+	}
+
+	return has_alter_system_priv;
 }
 
 /*

doc/appendix-release-notes.xml

@@ -16,8 +16,44 @@
   </para>
 
   <!-- remember to update the release date in ../repmgr_version.h.in -->
+  <sect1 id="release-5.4.1">
+    <title id="release-current">Release 5.4.1</title>
+    <para><emphasis>??? ?? ??????, 202?</emphasis></para>
+    <para>
+      &repmgr; 5.4.1 is a minor release providing ...
+    </para>
+    <sect2>
+      <title>Bug fixes</title>
+      <para>
+        <itemizedlist>
+          <listitem>
+            <para>
+              &repmgrd;: ensure witness node metadata is updated if the primary
+              node changed while the witness &repmgrd; was not running.
+            </para>
+          </listitem>
+        </itemizedlist>
+      </para>
+    </sect2>
+  </sect1>
+
+  <sect1 id="release-5.4.0">
+    <title>Release 5.4.0</title>
+    <para><emphasis>Thu 15 March, 2023</emphasis></para>
+    <para>
+      &repmgr; 5.4.0 is a major release.
+    </para>
+    <para>
+      This release provides support for cloning standbys using backups taken with <ulink url="http://www.pgbarman.org">barman</ulink>
+      with the use of <ulink url="https://github.com/EnterpriseDB/pg-backup-api">pg-backup-api</ulink>.
+    </para>
+    <para>
+      Minor fixes to the documentation.
+    </para>
+  </sect1>
+
   <sect1 id="release-5.3.3">
-    <title id="release-current">Release 5.3.3</title>
+    <title>Release 5.3.3</title>
     <para><emphasis>Mon 17 October, 2022</emphasis></para>
     <para>
       &repmgr; 5.3.3 is a minor release providing support for

doc/cloning-standbys.xml

@@ -225,6 +225,109 @@ description = "Main cluster"
    </note>
 
   </sect2>
+
+  <sect2 id="cloning-from-barman-pg_backupapi-mode" xreflabel="Using Barman through its API (pg-backup-api)">
+    <title>Using Barman through its API (pg-backup-api)</title>
+    <indexterm>
+      <primary>cloning</primary>
+      <secondary>pg-backup-api</secondary>
+    </indexterm>
+
+    <para>
+      You can find information on how to install and setup pg-backup-api in
+      <ulink url="https://www.enterprisedb.com/docs/supported-open-source/barman/pg-backup-api/">the pg-backup-api
+      documentation</ulink>.
+    </para>
+
+    <para>
+      This mode (`pg-backupapi`) was introduced in v5.4.0 as a way to further integrate with Barman letting Barman
+      handle the restore. This also reduces the ssh keys that need to share between the backup and postgres nodes.
+      As long as you have access to the API service by HTTP calls, you could perform recoveries right away.
+      You just need to instruct Barman through the API which backup you need and on which node the backup needs to
+      to be restored on.
+    </para>
+
+    <para>
+      In order to enable <literal>pg_backupapi mode</literal> support for <command>repmgr standby clone</command>,
+      you need the following lines in repmgr.conf:
+      <itemizedlist spacing="compact" mark="bullet">
+        <listitem><para>pg_backupapi_host: Where pg-backup-api is hosted</para></listitem>
+        <listitem><para>pg_backupapi_node_name: Name of the server as understood by Barman</para></listitem>
+        <listitem><para>pg_backupapi_remote_ssh_command: How Barman will be connecting as to the node</para></listitem>
+        <listitem><para>pg_backupapi_backup_id: ID of the existing backup you need to restore</para></listitem>
+      </itemizedlist>
+
+      This is an example of how repmgr.conf would look like:
+
+      <programlisting>
+        pg_backupapi_host = '192.168.122.154'
+        pg_backupapi_node_name = 'burrito'
+        pg_backupapi_remote_ssh_command = 'ssh john_doe@192.168.122.1'
+        pg_backupapi_backup_id = '20230223T093201'
+      </programlisting>
+    </para>
+
+    <para>
+      <literal>pg_backupapi_host</literal> is the variable name that enables this mode, and when you set it,
+      all the rest of the above variables are required. Also, remember that this service is just an interface
+      between Barman and repmgr, hence if something fails during a recovery, you should check Barman's logs upon
+      why the process couldn't finish properly.
+    </para>
+
+    <note>
+      <simpara>
+        Despite in Barman you can define shortcuts like "lastest" or "oldest", they are not supported for the
+        time being in pg-backup-api. These shortcuts will be supported in a future release.
+      </simpara>
+     </note>
+
+    <para>
+      This is a real example of repmgr's output cloning with the API. Note that during this operation, we stopped
+      the service for a little while and repmgr had to retry but that doesn't affect the final outcome. The primary
+      is listening on localhost's port 6001:
+
+      <programlisting>
+$ repmgr -f ~/nodes/node_3/repmgr.conf standby clone -U repmgr -p 6001 -h localhost
+NOTICE: destination directory "/home/mario/nodes/node_3/data" provided
+INFO: Attempting to use `pg_backupapi` new restore mode
+INFO: connecting to source node
+DETAIL: connection string is: user=repmgr port=6001 host=localhost
+DETAIL: current installation size is 8541 MB
+DEBUG: 1 node records returned by source node
+DEBUG: connecting to: "user=repmgr dbname=repmgr host=localhost port=6001 connect_timeout=2 fallback_application_name=repmgr options=-csearch_path="
+DEBUG: upstream_node_id determined as 1
+INFO: Attempting to use `pg_backupapi` new restore mode
+INFO: replication slot usage not requested;  no replication slot will be set up for this standby
+NOTICE: starting backup (using pg_backupapi)...
+INFO: Success creating the task: operation id '20230309T150647'
+INFO: status IN_PROGRESS
+INFO: status IN_PROGRESS
+Incorrect reply received for that operation ID.
+INFO: Retrying...
+INFO: status IN_PROGRESS
+INFO: status IN_PROGRESS
+INFO: status IN_PROGRESS
+INFO: status IN_PROGRESS
+INFO: status IN_PROGRESS
+INFO: status IN_PROGRESS
+INFO: status IN_PROGRESS
+INFO: status IN_PROGRESS
+INFO: status IN_PROGRESS
+INFO: status IN_PROGRESS
+INFO: status IN_PROGRESS
+INFO: status IN_PROGRESS
+INFO: status IN_PROGRESS
+INFO: status IN_PROGRESS
+INFO: status IN_PROGRESS
+INFO: status DONE
+NOTICE: standby clone (from pg_backupapi) complete
+NOTICE: you can now start your PostgreSQL server
+HINT: for example: pg_ctl -D /home/mario/nodes/node_3/data start
+HINT: after starting the server, you need to register this standby with "repmgr standby register"
+      </programlisting>
+
+    </para>
+  </sect2> <!--END cloning-from-barman-pg_backupapi-mode !-->
  </sect1>
 
  <sect1 id="cloning-replication-slots" xreflabel="Cloning and replication slots">

doc/configuration-file-optional-settings.xml

@@ -10,8 +10,8 @@
   <note>
     <simpara>
       This section documents a subset of optional configuration settings; for a full
-      for a full and annotated view of all configuration options see the
-      see the <ulink url="https://raw.githubusercontent.com/EnterpriseDB/repmgr/master/repmgr.conf.sample">sample repmgr.conf file</ulink>
+      and annotated view of all configuration options see the
+      <ulink url="https://raw.githubusercontent.com/EnterpriseDB/repmgr/master/repmgr.conf.sample">sample repmgr.conf file</ulink>
     </simpara>
   </note>
 

doc/configuration-permissions.xml

@@ -159,8 +159,10 @@
             <simpara>
               The <command>ALTER SYSTEM</command> is executed by &repmgrd; if
               <varname>standby_disconnect_on_failover</varname> is set to <literal>true</literal> in
-              <filename>repmgr.conf</filename>. <command>ALTER SYSTEM</command> can only be executed by
+              <filename>repmgr.conf</filename>. Until PostgreSQL 14 <command>ALTER SYSTEM</command> can only be executed by
               a superuser; if the &repmgr; user is not a superuser, this functionality will not be available.
+              From PostgreSQL 15 a specific ALTER SYSTEM privilege can be granted with e.g.
+              <command>GRANT ALTER SYSTEM ON PARAMETER wal_retrieve_retry_interval TO repmgr</command>.
             </simpara>
           </listitem>
         </itemizedlist>

doc/repmgrd-automatic-failover.xml

@@ -279,7 +279,9 @@
   <note>
     <para>
       <option>standby_disconnect_on_failover</option> is available with PostgreSQL 9.5 and later.
-      Additionally this requires that the <literal>repmgr</literal> database user is a superuser.
+      Until PostgreSQL 14 this requires that the <literal>repmgr</literal> database user is a superuser.
+      From PostgreSQL 15 a specific ALTER SYSTEM privilege can be granted to the <literal>repmgr</literal> database
+      user with e.g. <command>GRANT ALTER SYSTEM ON PARAMETER wal_retrieve_retry_interval TO repmgr</command>.
     </para>
   </note>
   <para>

repmgr.conf.sample

@@ -340,7 +340,9 @@ ssh_options='-q -o ConnectTimeout=10'	# Options to append to "ssh"
 #repmgrd_exit_on_inactive_node=false	# If "true", and the node record is marked as "inactive", abort repmgrd startup
 #standby_disconnect_on_failover=false	# If "true", in a failover situation wait for all standbys to
 					# disconnect their WAL receivers before electing a new primary
-					# (PostgreSQL 9.5 and later only; repmgr user must be a superuser for this)
+					# Can be true in PostgreSQL 9.5 and later only. Until PostgreSQL 14 repmgr user must be a superuser to use this.
+					# From PostgreSQL 15 repmgr must be a superuser or have 'ALTER SYSTEM wal_retrieve_retry_interval' privilege.
+					# (see: https://repmgr.org/docs/current/repmgrd-standby-disconnection-on-failover.html )
 #sibling_nodes_disconnect_timeout=30	# If "standby_disconnect_on_failover" is true, the maximum length of time
 					#  (in seconds) to wait for other standbys to confirm they have disconnected their
 					# WAL receivers

repmgrd-physical.c

@@ -2394,6 +2394,17 @@ monitor_streaming_witness(void)
 			terminate(ERR_BAD_CONFIG);
 		}
 
+		/*
+		 * It's possible that the primary changed while the witness repmgrd was not
+		 * running. This does not affect the functionality of the witness repmgrd, but
+		 * does mean outdated node metadata will be displayed, so update that.
+		 */
+		if (local_node_info.upstream_node_id != primary_node_id)
+		{
+			update_node_record_set_upstream(primary_conn, local_node_info.node_id, primary_node_id);
+			local_node_info.upstream_node_id = primary_node_id;
+		}
+
 		initPQExpBuffer(&event_details);
 
 		appendPQExpBuffer(&event_details,