C.1. General

C.1.1. What's the difference between the repmgr versions?
C.1.2. What's the advantage of using replication slots?
C.1.3. How many replication slots should I define in max_replication_slots?
C.1.4. Does repmgr support hash indexes?
C.1.5. Can repmgr assist with upgrading a PostgreSQL cluster?
C.1.6. What does this error mean: ERROR: could not access file "$libdir/repmgr"?
C.1.7. How can I obtain old versions of repmgr packages?
C.1.8. Is repmgr required for streaming replication?
C.1.9. Will replication stop working if repmgr is uninstalled?
C.1.10. Does it matter if different repmgr versions are present in the replication cluster?
C.1.11. Should I upgrade repmgr?
C.1.12. Why do I need to specify the data directory location in repmgr.conf?
C.1.13. Are repmgr packages compatible with $third_party_vendor's packages?

C.1.1. What's the difference between the repmgr versions?

repmgr 4 is a complete rewrite of the previous repmgr code base and implements repmgr as a PostgreSQL extension. It supports all PostgreSQL versions from 9.3 (although some repmgr features are not available for PostgreSQL 9.3 and 9.4).

Note

repmgr 5 is fundamentally the same code base as repmgr 4, but provides support for the revised replication configuration mechanism in PostgreSQL 12.

Support for PostgreSQL 9.3 is no longer available from repmgr 5.2.

repmgr 3.x builds on the improved replication facilities added in PostgreSQL 9.3, as well as improved automated failover support via repmgrd, and is not compatible with PostgreSQL 9.2 and earlier. We recommend upgrading to repmgr 4, as the repmgr 3.x series is no longer maintained.

repmgr 2.x supports PostgreSQL 9.0 ~ 9.3. While it is compatible with PostgreSQL 9.3, we recommend using repmgr 4.x. repmgr 2.x is no longer maintained.

See also repmgr compatibility matrix and Should I upgrade repmgr?.

C.1.2. What's the advantage of using replication slots?

Replication slots, introduced in PostgreSQL 9.4, ensure that the primary server will retain WAL files until they have been consumed by all standby servers. This means standby servers should never fail due to not being able to retrieve required WAL files from the primary.

However this does mean that if a standby is no longer connected to the primary, the presence of the replication slot will cause WAL files to be retained indefinitely, and eventually lead to disk space exhaustion.

Tip

2ndQuadrant's recommended configuration is to configure Barman as a fallback source of WAL files, rather than maintain replication slots for each standby. See also: Using Barman as a WAL file source.

C.1.3. How many replication slots should I define in max_replication_slots?

Normally at least same number as the number of standbys which will connect to the node. Note that changes to max_replication_slots require a server restart to take effect, and as there is no particular penalty for unused replication slots, setting a higher figure will make adding new nodes easier.

C.1.4. Does repmgr support hash indexes?

Before PostgreSQL 10, hash indexes were not WAL logged and are therefore not suitable for use in streaming replication in PostgreSQL 9.6 and earlier. See the PostgreSQL documentation for details.

From PostgreSQL 10, this restriction has been lifted and hash indexes can be used in a streaming replication cluster.

C.1.5. Can repmgr assist with upgrading a PostgreSQL cluster?

For minor version upgrades, e.g. from 9.6.7 to 9.6.8, a common approach is to upgrade a standby to the latest version, perform a switchover promoting it to a primary, then upgrade the former primary.

For major version upgrades (e.g. from PostgreSQL 9.6 to PostgreSQL 10), the traditional approach is to "reseed" a cluster by upgrading a single node with pg_upgrade and recloning standbys from this.

To minimize downtime during major upgrades from PostgreSQL 9.4 and later, pglogical can be used to set up a parallel cluster using the newer PostgreSQL version, which can be kept in sync with the existing production cluster until the new cluster is ready to be put into production.

C.1.6. What does this error mean: ERROR: could not access file "$libdir/repmgr"?

It means the repmgr extension code is not installed in the PostgreSQL application directory. This typically happens when using PostgreSQL packages provided by a third-party vendor, which often have different filesystem layouts.

Either use PostgreSQL packages provided by the community or 2ndQuadrant; if this is not possible, contact your vendor for assistance.

C.1.7. How can I obtain old versions of repmgr packages?

See appendix Installing old package versions for details.

C.1.8. Is repmgr required for streaming replication?

No.

repmgr (together with repmgrd) assists with managing replication. It does not actually perform replication, which is part of the core PostgreSQL functionality.

C.1.9. Will replication stop working if repmgr is uninstalled?

No. See preceding question.

C.1.10. Does it matter if different repmgr versions are present in the replication cluster?

Yes. If different "major" repmgr versions (e.g. 3.3.x and 4.1.x) are present, repmgr (in particular repmgrd) may not run, or run properly, or in the worst case (if different repmgrd versions are running and there are differences in the failover implementation) break your replication cluster.

If different "minor" repmgr versions (e.g. 4.1.1 and 4.1.6) are installed, repmgr will function, but we strongly recommend always running the same version to ensure there are no unexpected suprises, e.g. a newer version behaving slightly differently to the older version.

See also Should I upgrade repmgr?.

C.1.11. Should I upgrade repmgr?

Yes.

We don't release new versions for fun, you know. Upgrading may require a little effort, but running an older repmgr version with bugs which have since been fixed may end up costing you more effort. The same applies to PostgreSQL itself.

C.1.12. Why do I need to specify the data directory location in repmgr.conf?

In some circumstances repmgr may need to access a PostgreSQL data directory while the PostgreSQL server is not running, e.g. to confirm it shut down cleanly during a switchover.

Additionally, this provides support when using repmgr on PostgreSQL 9.6 and earlier, where the repmgr user is not a superuser; in that case the repmgr user will not be able to access the data_directory configuration setting, access to which is restricted to superusers.

In PostgreSQL 10 and later, non-superusers can be added to the default role pg_read_all_settings (or the meta-role pg_monitor) which will enable them to read this setting.

C.1.13. Are repmgr packages compatible with $third_party_vendor's packages?

repmgr packages provided by 2ndQuadrant are compatible with the community-provided PostgreSQL packages and any software provided by 2ndQuadrant.

A number of other vendors provide their own versions of PostgreSQL packages, often with different package naming schemes and/or file locations.

We cannot guarantee that repmgr packages will be compatible with these packages. It may be possible to override package dependencies (e.g. rpm --nodeps for CentOS-based systems or dpkg --force-depends for Debian-based systems).