A.3. Release 5.1.0

A.3.1. Compatibility changes
A.3.2. General improvements
A.3.3. Bug fixes

Mon 13 April, 2020

repmgr 5.1.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.3.1. Compatibility changes

The repmgr standby clone --recovery-conf-only option has been renamed to --replication-conf-only. --recovery-conf-only will still be accepted as an alias.

A.3.2. General improvements

  • The requirement that the repmgr user is a database superuser has been removed as far as possible.

    In theory, repmgr can be operated with a normal database user for managing the repmgr database, and a separate replication user for managing replication connections (and replication slots, if these are in use).

    Some operations will still require superuser permissions, e.g. for issuing a CHECKPOINT as par of a switchover operation; in this case a valid superuser should be provided with the -S/--superuser option.

  • repmgr standby clone: Warn if neither of data page checksums or wal_log_hints are active, as this will preclude later usage of pg_rewind.

  • repmgr standby promote: when executed with --dry-run, the method which would be used to promote the node will be displayed.

  • repmgr standby follow: Improve logging and checking of potential failure situations.

  • repmgr standby switchover: Replication configuration files (PostgreSQL 11 and earlier: recovery.conf; PostgreSQL 12 and later: postgresql.auto.conf) will be checked to ensure they are owned by the same user who owns the PostgreSQL data directory.

  • repmgr standby switchover: Provide additional information in --dry-run mode output.

  • repmgr standby switchover: Checks that the demotion candidate's registered repmgr.conf file can be found, to prevent confusing references to an incorrectly configured data directory. GitHub 615.

  • repmgr node check: accept option -S/--superuser. GitHub #621.

  • repmgr node check: add --upstream option to check whether the node is attached to the expected upstream node.

A.3.3. Bug fixes

  • Ensure repmgr node rejoin checks for available replication slots on the rejoin target.

  • repmgr standby follow and repmgr node rejoin will now return an error code if the operation fails if a replication slot is not available or cannot be created on the follow/rejoin target.

  • repmgr standby promote: in --dry-run mode, display promote command which will be executed.

  • repmgr standby promote will check if the repmgr user has permission to execute pg_promote() and fall back to pg_ctl promote if necessary.

  • repmgr standby switchover: check for demotion candidate reattachment as late as possible to avoid spurious failure reports.

  • repmgrd: check for presence of promote_command and follow_command on receipt of SIGHUP. GitHub 614.

  • Fix situation where replication connections were not created correctly, which could lead to spurious replication connection failures in some situations, e.g. where password files are used.

  • Ensure postgresql.auto.conf is created with correct permissions (PostgreSQL 12 and later).