This release added support for pg-backup-api. Here we add the
release notes which expose the new feature.
Signed-off-by: Martín Marqués <martin.marques@enterprisedb.com>
I added a paragraph at the beginning of the section on where to look for
instructions on how to install the pg-backup-api rest API.
Fixed typos and some gramatical changes. Also reworded the first paragraph
(which is now the second one).
Signed-off-by: Martín Marqués <martin.marques@enterprisedb.com>
Fixed a mising closing quote and closing parenthesis in the repmgrd overview
section of the documentation.
Signed-off-by: Martín Marqués <martin.marques@enterprisedb.com>
Anyone still using PostgreSQL 9.4 should re-examine their life choices
at this point, but as it is not yet de-supported by repmgr, consolidate
the references to it whenever pg_rewind is mentioned to a single
section.
Specifically, don't attempt to disable walsenders if "standby_disconnect_on_failover"
is "true", but the repmgr user is not a superuser.
This restriction can be lifted from PostgreSQL 15.
Information about using repmgr with a non-superuser was spread
throughout individual documentation systems; this commit creates
an overview of requirements and potential issues.
Previously, if the witness node's PostgreSQL was unreachable, it would
be marked as "inactive" on the primary, and under some circumstances
would not be corrected to "active" once the witness node's PostgreSQL
came back.
PR #754; some modifications by Ian Barwick.
The cluster size check is purely informative, and is not in any way
essential for the standby clone operation. As it's possible the query
may fail if the repmgr user does not have sufficient privileges to
query all databases in the cluster, we can simply ignore any failure.
Note that the code comment indicated the query also served to sanity-
check that queries can actually be executed. While this was the case
historically, the preceding server version check now serves the same
purpose and will not have the same risk of failure due to missing
permissions.
Explicitly check whether the "repmgr node rejoin" command on the
demotion candidate succeeded. Due to the way SSH execution is
currently implemented, we can return either the command execution
status or the command output; to ensure any errors are available,
log them to a temporary file on the demotion candidate and note
its location in case of an error.
While we're at it, improve error message handling when the demotion
candidate fails to rejoin.
Martín Marqués