In particular, if running "repmgr cluster show" against a database
without the repmgr metadata, showing the error (rather than just
"no records found" etc.) will provide some clues about the problem.
There are now too many options to sensibly fit into general --help
output; we'll add separate output for each repmgr command, e.g.
"repmgr node --help".
If the current primary (demotion candidate) still has any files to archive,
it will delay the shutdown until all files are archived. If there is a
substantial number of files, and/or the archive command executes slowly,
this will probably lead to an unwelcome delay in the switchover process.
Rather than simply emit "FAILED" for an unreachable node,
indicate whether its state matches that expected by repmgr.
E.g. following output:
ID | Name | Role | Status | Upstream | Connection string
----+-------+---------+----------------------+----------+----------------------------------------------------
1 | node1 | primary | * running | | host=localhost dbname=repmgr user=repmgr port=5501
2 | node2 | standby | ? unreachable | node1 | host=localhost dbname=repmgr user=repmgr port=5502
3 | node3 | standby | ! running as primary | node1 | host=localhost dbname=repmgr user=repmgr port=5503
is for a cluster where "node2" has been manually stopped, and "node3"
manually promoted.
