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

View File

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