In previous versions of repmgr, some options had ambiguous meanings,
and/or were used for slightly different purposes. This way we end
up with a couple more options (most of which probably won't need
adjusting) but greater clarity and flexibility.
Removed:
master_reponse_timeout:
renamed to "async_query_timeout", as this was its main usage
retry_promote_interval_secs:
replaced by "primary_notification_timeout"
Added:
async_query_timeout:
timeout (in seconds) when executing asynchronous queries
primary_notification_timeout:
number of seconds to wait for notification from the new primary
after a failover
primary_follow_timeout:
number of seconds to wait for the new primary to become available
when executing "repmgr standby follow"
In some cases, the monitored upstream may not be available for a while
(e.g. network split), in which case it makes sense to have repmgrd
keep running and trying to reconnect. Previously it would just keel
over and quit.
This is more consistent with other parameters and conforms to
the pattern used by PostgreSQL itself, which uses the prefix "log_"
for logging parameters.
A warning will be emitted if the old version of the parameter name
is detected.
Normally (outside of log level DEBUG) repmgrd doesn't generate any
kind of log output, so examining the log file may give the impression
it's not working. Output an informational message at regular intervals
to show it's up and running.
This is more consistent with other parameters and conforms to
the pattern used by PostgreSQL itself, which uses the prefix "log_"
for logging parameters.
A warning will be emitted if the old version of the parameter name
is detected.
