To use repmgrd, its associated function library must be included in postgresql.conf with: shared_preload_libraries = 'repmgr' Changing this setting requires a restart of PostgreSQL; for more details see the PostgreSQL documentation. Additionally the following repmgrd options *must* be set in repmgr.conf (adjust configuration file locations as appropriate): failover=automatic promote_command='repmgr standby promote -f /etc/repmgr.conf --log-to-file' follow_command='repmgr standby follow -f /etc/repmgr.conf --log-to-file --upstream-node-id=%n' Note that the --log-to-file option will cause output generated by the &repmgr; command, when executed by repmgrd, to be logged to the same destination configured to receive log output for repmgrd. See repmgr.conf.sample for further repmgrd-specific settings. When failover is set to automatic, upon detecting failure of the current primary, repmgrd will execute one of promote_command or follow_command, depending on whether the current server is to become the new primary, or needs to follow another server which has become the new primary. Note that these commands can be any valid shell script which results in one of these two actions happening, but if &repmgr;'s standby follow or standby promote commands are not executed (either directly as shown here, or from a script which performs other actions), the &repmgr; metadata will not be updated and &repmgr; will no longer function reliably. The follow_command should provide the --upstream-node-id=%n option to repmgr standby follow; the %n will be replaced by repmgrd with the ID of the new primary node. If this is not provided, &repmgr; will attempt to determine the new primary by itself, but if the original primary comes back online after the new primary is promoted, there is a risk that repmgr standby follow will result in the node continuing to follow the original primary.