"FullTransactionId" is not present in earlier versions, so we'll
have to #ifdef that out for those.
We should probably add more elegant checks to ensure that repmgr
is being executed against the PostgreSQL version it was built against.
In a normal production environment that will be the case as the
matching package will have been installed, so version mismatches
don't usually occur.
Note that while currently most aspects of the repmgr client are
compatible across PostgreSQL versions, the repmgrd code is very
version specific, so version specificity is a given anyway.
"repmgr daemon" can be interpreted to mean the commands affect the local
daemon process only. Rename the commands which affect the entire cluster
to "repmgr service ...".
The "repmgr daemon ..." form of the affected commands is retained for backwards
compatibility.
Previously, if a standby's repmgrd was looping in degraded monitoring
mode looking for a new primary to follow, once a new primary was
detected the follow command would be executed without any prior
logging at non-DEBUG log levels.
Previously repmgr would emit the "repmgr extension not found on source node"
which depending on context is somewhat misleading, as it may exist
but not be installed, or the user may be attempting to clone from the
wrong database.
From PostgreSQL 10, a member of the default roles "pg_monitor" and/or
"pg_read_all_settings" can read pg_settings without requiring superuser
privileges.
Previously, a hint was being emitted about making the repmgr user a
member of one of those groups, but no check for membership was being
made, meaning the check could only be run by a superuser.
The following options have long since been deprecated, and any attempt
to use them results only in a warning that they are no longer valid:
--data-dir
--no-conninfo-password
--recovery-min-apply-delay
Previously, repmgr was using a very simple ad-hoc string-based parser,
which had various limitations and allowed configuration files to be
created in a way which could cause confusion and/or unexpected
behaviour.
For example, it accepted strings enclosed in single quotes, but treated
strings enclosed in double quotes literally. A node_name defined thusly:
node_name="somenode"
would result in the literal value '"somenode"' being used, which could
lead to unobvious errors along the lines of:
no record found for ""somenode""
The configuration file parser has been adapted from the one used by
PostgreSQL itself, so behaves more-or-less identically (though some
functions such as file inclusion are not supported in repmgr).
This makes configuration parsing more robust and consistent;
additionally, error reporting will be more precise.
Note this does mean that some repmgr.conf items previously accepted
as valid by repmgr will now be rejected; in particular this includes
strings containing spaces which are not enclosed in single quotes.
Due to [insert reason here], in the Debian package build process (and
only there), when building frontend code PG_VERSION_NUM appears to be
from the newest libpq-dev version installed, and does not necessarily
match the version of the server the code is being built against.
To work around this distribution-specific package build issue, we'll
define our own substitution variable which is taken from the value
provided in Makefile.global.
