If the control file couldn't be parsed for whatever reason, return
the default value for the requested parameter.
It'd be better to have the caller pass in a pointer to the parameter
and have the function return bool so the caller doesn't assume the
control file was read successfully. This is important for handling
DBState, where no "value unknown" default is available.
"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.
This commit adds infrastruture for repmgr to be able to check
whether one standby can attach to another node, regardless whether
it is a standby or a primary.
This is intended to prevent a node from attempting to follow a
node whose timeline has diverged. The --dry-run option makes
it possible to test a follow operation before it is carried out.
As a useful side-effect this makes it possible for a standby to
follow another standby.
This is an initial implementation; documentation and possibly
further changes to follow.
With the recovery configuration changes in PostgreSQL 12, there will
be situations where we'll need to determine the version number from
a dormant data directory in order to determine whether to write
recovery.conf or not.
The "data_checksum_version" field towards the end of the ControlFileData struct,
meaning its position varies between versions. Previously this wasn't a problem
as it was only required for operations involving 9.5 and later, and its position
within the control file has not changed between the current release and current
HEAD.
However, in order to support pg_rewind in 9.3 and 9.4, which both have changes in
the control file format, we'll need version-specific parsing. This will also make
it easier to deal with any future changes to the control file format.
pg_rewind will only be executed on a demoted primary if explictly
requested, to prevent transactions on the primary, which
were never replicated, from being automatically overwritten.
If --force-rewind is provided, we'll need to check pg_rewind
is actually useable before we need to use it.
The repmgr3 implementation required the promotion candidate (standby)
to directly work with the demotion candidate's data directory,
directly execute server control commands etc.
Here we delegated a lot more of that work to the repmgr on the
demotion candidate, which reduces the amount of back-and-forth
over SSH and generally makes things cleaner and smoother.
In particular the repmgr on the demotion candidate will carry
out a thorough check that the node is shut down and report
the last checkpoint LSN to the promotion candidate; this
can then be used to determine whether pg_rewind needs to be
executed on the demoted primary before reintegrating it back
into the cluster (todo).
Also implement "--dry-run" for this action, which will sanity-check the
nodes as far as possible without executing the switchover.
Additionally some of the new repmgr node commands (or command options)
introduced for this can be also executed by the user to obtain
additional information about the status of each node.
This involves adding some infrastructure to parse pg_control in a
reasonably version-independent fashion. This will probably be useful
in other contexts where we need to verify the status of a
data directory where the instance isn't running.
