A.1. Release 5.0

A.1.1. Compatibility changes
A.1.2. General enhancements
A.1.3. Bug fixes

Tue 15 October, 2019

repmgr 5.0 is a major release.

For details on how to upgrade an existing repmgr installation, see documentation section Upgrading a major version release.

If repmgrd is in use, a PostgreSQL restart is required; in that case we suggest combining this repmgr upgrade with the next PostgreSQL minor release, which will require a PostgreSQL restart in any case.

A.1.1. Compatibility changes

A.1.1.1. Configuration file parsing has been made stricter

repmgr now parses configuration files in the same way that PostgreSQL itself does, which means some files used with earlier repmgr versions may need slight modification before they can be used with repmgr 5 and later.

The main change is that string parameters should always be enclosed in single quotes.

For example, in repmgr 4.4 and earlier, the following repmgr.conf entry was valid:

conninfo=host=node1 user=repmgr dbname=repmgr connect_timeout=2

This must now be changed to:

conninfo='host=node1 user=repmgr dbname=repmgr connect_timeout=2'

Note that simple string identifiers (e.g. node_name=node1) may remain unquoted, though we recommend always enclosing strings in single quotes.

Additionally, leading/trailing white space between single quotes will no longer be trimmed; the entire string between single quotes will be taken literally.

Strings enclosed in double quotes (e.g. node_name="node1") will now be rejected; previously they were accepted, but the double quotes were interpreted as part of the string, which was a frequent cause of confusion.

This syntax matches that used by PostgreSQL itself.

A.1.1.2. Some "repmgr daemon ..." commands renamed

Some "repmgr daemon ..." commands have been renamed to "repmgr service ..." as they have a cluster-wide effect and to avoid giving the impression they affect only the local repmgr daemon.

The following commands are affected:

The "repmgr daemon ..." form will still be accepted for backwards compatibility.

A.1.1.3. Some deprecated command line options removed

The following command line options, which have been deprecated since repmgr 3.3 (and which no longer had any effect other than to generate a warning about their use) have been removed:

  • --data-dir
  • --no-conninfo-password
  • --recovery-min-apply-delay

A.1.2. General enhancements

  • Support for PostgreSQL 12 added.

    Beginning with PostgreSQL 12, replication configuration has been integrated into the main PostgreSQL configuraton system and the conventional recovery.conf file is no longer valid.

    repmgr has been modified to be compatible with this change.

    repmgr additionally takes advantage of the new pg_promote() function, which enables a standby to be promoted to primary using an SQL command.

    For an overview of general changes to replication configuration, see this blog entry: Replication configuration changes in PostgreSQL 12

  • The repmgr configuration file is now parsed using flex, meaning it will be parsed in the same way as PostgreSQL parses its own configuration files.

    This makes configuration file parsing more robust and consistent.

    See item Configuration file parsing has been made stricter for details.

  • repmgr standby clone: checks for availability of the repmgr extension on the upstream node have been improved and error messages improved.

  • When executing repmgr remotely, if the repmgr log level was explicitly provided (with -L/--log-level), that log level will be passed to the remote repmgr.

    This makes it possible to return log output when executing repmgr remotely at a different level to the one defined in the remote repmgr's repmgr.conf.

    This is particularly useful when DEBUG output is required.

A.1.3. Bug fixes

  • Check role membership when trying to read pg_settings.

    Previously repmgr assumed only superusers could read pg_settings, but from PostgreSQL 10, all members of the roles pg_read_all_settings or pg_monitor are permitted to do this as well.

  • repmgrd: Fix handling of upstream node change check.

    repmgrd has a check to see if the upstream node has unexpectedly changed, e.g. if the repmgrd service is paused and the PostgreSQL instance has been pointed to another node.

    However this check was relying on the node record on the local node being up-to-date, which may not be the case immediately after a failover, when the node is still replaying records updated prior to the node's own record being updated. In this case it will mistakenly assume the node is following the original primary and attempt to restart monitoring, which will fail as the original primary is no longer available.

    To prevent this, the node's record on the upstream node is checked to see if the reported upstream node_id matches the expected node_id. GitHub #587/#588.