Issue #829 was opened indicating, with a reproducible, that repmgr
was not able to run `node rejoin` with minimal privileged user. The
main obstacle is that pg_rewind is not able to execute the rewind
operation if the user has REPLICATION privileges, but the user
repmgr uses requires REPLICATION. This is a typical catch22.
The solution provided here adds a --superuser, similar to what
other commands have, to `node rejoin`
AI-assisted development notes:
The approach was designed and directed by Martín Marqués, who
also reviewed and refined the output. Code was written by Claude
(AI), with some additions from Martín in the documentation.
Fixes#829
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
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.
As it's possible to specify the connection information for any available
node, but currently not possible to rejoin to a node other than the
primary, explicitly mention what the rejoin target will be.
From PostgreSQL 13, pg_rewind will automatically handle an unclean
shutdown itself, so as long as --force-rewind was provided, so there
is no need to fail with an error.
Note that pg_rewind handles the unclean shutdown by starting PostgreSQL
in single user mode, which it does before performing any checks as
to whether a rewind is actually necessary.
However pg_rewind doesn't take into account the possible presence
of a standby.signal file, so we remove that and recreate it after
pg_rewind was executed.
