1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00

Adjust pg_wal_replay_wait() procedure behavior on promoted standby

pg_wal_replay_wait() is intended to be called on standby.  However, standby
can be promoted to primary at any moment, even concurrently with the
pg_wal_replay_wait() call.  If recovery is not currently in progress
that doesn't mean the wait was unsuccessful.  Thus, we always need to recheck
if the target LSN is replayed.

Reported-by: Kevin Hale Boyes
Discussion: https://postgr.es/m/CAPpHfdu5QN%2BZGACS%2B7foxmr8_nekgA2PA%2B-G3BuOUrdBLBFb6Q%40mail.gmail.com
Author: Alexander Korotkov
This commit is contained in:
Alexander Korotkov
2024-08-10 21:43:02 +03:00
parent bbf668d66f
commit 867d396ccd
3 changed files with 55 additions and 11 deletions

View File

@ -28969,6 +28969,15 @@ postgres=# SELECT '0/0'::pg_lsn + pd.segment_number * ps.setting::int + :offset
connection pooler side.
</para>
<para>
<function>pg_wal_replay_wait</function> should be called on standby.
If a user calls <function>pg_wal_replay_wait</function> on primary, it
will error out. However, if <function>pg_wal_replay_wait</function> is
called on primary promoted from standby and <literal>target_lsn</literal>
was already replayed, then <function>pg_wal_replay_wait</function> just
exits immediately.
</para>
<para>
You can use <function>pg_wal_replay_wait</function> to wait for
the <type>pg_lsn</type> value. For example, an application could update