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.

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).