From 867d396ccd2a7f0ce55e1fa7ebda00bc8c81147b Mon Sep 17 00:00:00 2001 From: Alexander Korotkov Date: Sat, 10 Aug 2024 21:43:02 +0300 Subject: 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 --- doc/src/sgml/func.sgml | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'doc/src') diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 0f7154b76ab..968a9985527 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -28969,6 +28969,15 @@ postgres=# SELECT '0/0'::pg_lsn + pd.segment_number * ps.setting::int + :offset connection pooler side. + + pg_wal_replay_wait should be called on standby. + If a user calls pg_wal_replay_wait on primary, it + will error out. However, if pg_wal_replay_wait is + called on primary promoted from standby and target_lsn + was already replayed, then pg_wal_replay_wait just + exits immediately. + + You can use pg_wal_replay_wait to wait for the pg_lsn value. For example, an application could update -- cgit v1.2.3