From 5398fd2d221d7ec21343df99db53dfcc10e288e1 Mon Sep 17 00:00:00 2001 From: Ian Barwick Date: Fri, 10 Aug 2018 10:23:50 +0900 Subject: [PATCH] doc: better explain where pg_bindir won't be applied Basically any setting which can contain a user-defined script *must* have the full path set, even if it's repmgr being executed. We could potentially apply some heuristics to detect if the first item in the setting is "repmgr" (or more precisely repmgrd's program name), but this will require some careful thought and testing that it works as intended. --- doc/appendix-faq.sgml | 11 ++++++++ doc/configuration-file-service-commands.sgml | 7 +++++ doc/quickstart.sgml | 19 +++++++++++++- doc/repmgrd-configuration.sgml | 11 +++++++- repmgr.conf.sample | 27 ++++++++++++-------- 5 files changed, 62 insertions(+), 13 deletions(-) diff --git a/doc/appendix-faq.sgml b/doc/appendix-faq.sgml index d5fe882e..5783153e 100644 --- a/doc/appendix-faq.sgml +++ b/doc/appendix-faq.sgml @@ -303,5 +303,16 @@ + + + <application>repmgrd</application> ignores pg_bindir when executing <varname>promote_command</varname> or <varname>follow_command</varname> + + + promote_command or follow_command can be user-defined scripts, + so &repmgr; will not apply even if excuting &repmgr;. Always provide the full + path; see for more details. + + + diff --git a/doc/configuration-file-service-commands.sgml b/doc/configuration-file-service-commands.sgml index 30d30933..a259801a 100644 --- a/doc/configuration-file-service-commands.sgml +++ b/doc/configuration-file-service-commands.sgml @@ -48,6 +48,13 @@ service_reload_command + + + &repmgr; will not apply when executing any of these commands; + these can be user-defined scripts so must always be specified with the full path. + + + It's also possible to specify a service_promote_command. diff --git a/doc/quickstart.sgml b/doc/quickstart.sgml index 070a48df..03899743 100644 --- a/doc/quickstart.sgml +++ b/doc/quickstart.sgml @@ -240,11 +240,28 @@ For Debian-based distributions we recommend explictly setting - pg_bindir to the directory where pg_ctl and other binaries + to the directory where pg_ctl and other binaries not in the standard path are located. For PostgreSQL 9.6 this would be /usr/lib/postgresql/9.6/bin/. + + + &repmgr; only uses when it executes + PostgreSQL binaries directly. + + + For user-defined scripts such as and the + various s, you must + always explicitly provide the full path to the binary or script being + executed, even if it is &repmgr; itself. + + + This is because these options can contain user-defined scripts in arbitrary + locations, so prepending may break them. + + + See the file repmgr.conf.sample diff --git a/doc/repmgrd-configuration.sgml b/doc/repmgrd-configuration.sgml index ce43bd07..02d02e43 100644 --- a/doc/repmgrd-configuration.sgml +++ b/doc/repmgrd-configuration.sgml @@ -64,8 +64,17 @@ follow_command='/usr/bin/repmgr standby follow -f /etc/repmgr.conf --log-to-file --upstream-node-id=%n' - Adjust file paths as appropriate; we recomment specifying the full path to the &repmgr; binary. + Adjust file paths as appropriate; alway specify the full path to the &repmgr; binary. + + + + &repmgr; will not apply when executing + or ; these can be user-defined scripts so must always be + specified with the full path. + + + Note that the --log-to-file option will cause output generated by the &repmgr; command, when executed by repmgrd, diff --git a/repmgr.conf.sample b/repmgr.conf.sample index 135f72d7..9699dbda 100644 --- a/repmgr.conf.sample +++ b/repmgr.conf.sample @@ -143,6 +143,11 @@ # Debian/Ubuntu users: you will probably need to # set this to the directory where `pg_ctl` is located, # e.g. /usr/lib/postgresql/9.6/bin/ + # + # *NOTE* "pg_bindir" is only used when repmgr directly + # executes PostgreSQL binaries; any user-defined scripts + # *must* be specified with the full path + # #use_primary_conninfo_password=false # explicitly set "password" in recovery.conf's # "primary_conninfo" parameter using the value contained # in the environment variable PGPASSWORD @@ -183,11 +188,11 @@ ssh_options='-q -o ConnectTimeout=10' # Options to append to "ssh" # parameter can be provided multiple times. #restore_command='' # This will be placed in the recovery.conf file generated - # by repmgr. + # by repmgr. #archive_cleanup_command='' # This will be placed in the recovery.conf file generated - # by repmgr. Note we recommend using Barman for managing - # WAL archives (see: https://www.pgbarman.org ) + # by repmgr. Note we recommend using Barman for managing + # WAL archives (see: https://www.pgbarman.org ) #recovery_min_apply_delay= # If provided, "recovery_min_apply_delay" in recovery.conf # will be set to this value (PostgreSQL 9.4 and later). @@ -259,10 +264,10 @@ ssh_options='-q -o ConnectTimeout=10' # Options to append to "ssh" # are defaults. #repmgrd_pid_file= # Path of PID file to use for repmgrd; if not set, a PID file will - # be generated in a temporary directory specified by the environment - # variable $TMPDIR, or if not set, in "/tmp". This value can be overridden - # by the command line option "-p/--pid-file"; the command line option - # "--no-pid-file" will force PID file creation to be skipped. + # be generated in a temporary directory specified by the environment + # variable $TMPDIR, or if not set, in "/tmp". This value can be overridden + # by the command line option "-p/--pid-file"; the command line option + # "--no-pid-file" will force PID file creation to be skipped. #failover=manual # one of 'automatic', 'manual'. # determines what action to take in the event of upstream failure # @@ -332,7 +337,7 @@ ssh_options='-q -o ConnectTimeout=10' # Options to append to "ssh" # # Debian/Ubuntu users: use "sudo pg_ctlcluster" to execute service control commands. # -# For more details, see: https://repmgr.org/docs/4.0/configuration-service-commands.html +# For more details, see: https://repmgr.org/docs/4.1/configuration-service-commands.html #service_start_command = '' #service_stop_command = '' @@ -376,7 +381,7 @@ ssh_options='-q -o ConnectTimeout=10' # Options to append to "ssh" #------------------------------------------------------------------------------ #bdr_local_monitoring_only=false # Only monitor the local node; no checks will be - # performed on the other node + # performed on the other node #bdr_recovery_timeout # If a BDR node was offline and has become available - # maximum length of time in seconds to wait for the - # node to reconnect to the cluster + # maximum length of time in seconds to wait for the + # node to reconnect to the cluster