EnterpriseDB/repmgr

repmgr cli would benefits from sensible defaults

Opened this issue · 0 comments

Hi.

Setting up repmgr, and have some feedback about the 1st time experience.

The main thing which complicates the process is IMHO that there are quite a few command line options which have to be passed in all commands over and over again. E.g. the very 1st thing which we run is this:

sudo -u postgres repmgr --copy-external-config-files -h my.primary.host -U repmgr -d repmgr standby clone

It's great that it uses /etc/repmgr.conf file by default and doesn't require specifying this path in command line. My idea is that defaults for most of the options can be inferred from there:

  1. When run from root, repmgr cli could've understand (in this and all other cases) that it actually needs to switch to postgres user. Maybe some option in config (with this default).
  2. -U option's default value can be inferred from /etc/repmgr.conf's conninfo. It's highly unlikely that for the current node and for the primary, the user name will be different. (Alternatively, it can just default to repmgr in all cases. That's the power of defaults - that they don't bring any limitations, but show best practices.)
  3. Same with -d.
  4. For --copy-external-config-files - it could've been an option in repmgr.conf.

I.e. this command could've been shortened (with reasonable defaults for 99% of users) to:

# repmgr standby clone

and allow itself to run as root (these days, people use containers or virtual machines, so there is nothing wrong in using root users in the shell while doing administrative work).