standby promote: in Pg13 and later, promotion overrides paused WAL replay

Aborting in this case no longer makes sense, so we apply the checks
to PostgreSQL 12 and earlier only.
This commit is contained in:
Ian Barwick
2020-09-30 14:00:05 +09:00
parent 73d2088a85
commit e86c035242
2 changed files with 11 additions and 7 deletions

View File

@@ -66,10 +66,10 @@
Both values can be defined in <filename>repmgr.conf</filename>.
</para>
<note>
<warning>
<para>
If WAL replay is paused on the standby, and not all WAL files on the standby have been
replayed, &repmgr; will not attempt to promote it.
In PostgreSQL 12 and earlier, if WAL replay is paused on the standby, and not all
WAL files on the standby have been replayed, &repmgr; will not attempt to promote it.
</para>
<para>
This is because if WAL replay is paused, PostgreSQL itself will not react to a promote command
@@ -81,7 +81,10 @@
Note that if the standby is in archive recovery, &repmgr; will not be able to determine
if more WAL is pending replay, and will abort the promotion attempt if WAL replay is paused.
</para>
</note>
<para>
This restriction does <emphasis>not</emphasis> apply to PostgreSQL 13 and later.
</para>
</warning>
</refsect1>

View File

@@ -2333,14 +2333,15 @@ do_standby_promote(void)
}
/*
* Executing "pg_ctl ... promote" when WAL replay is paused and
* WAL is pending replay will mean the standby will not promote
* until replay is resumed.
* In PostgreSQL 12 and earlier, executing "pg_ctl ... promote" when WAL
* replay is paused and WAL is pending replay will mean the standby will
* not promote until replay is resumed.
*
* As that could happen at any time outside repmgr's control, we
* need to avoid leaving a "ticking timebomb" which might cause
* an unexpected status change in the replication cluster.
*/
if (PQserverVersion(local_conn) < 130000)
{
ReplInfo replication_info;
bool replay_paused = false;