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:
@ -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
|
||||
|
Reference in New Issue
Block a user