On Sat, Aug 3, 2024 at 6:07 AM Alexander Korotkov <aekorot...@gmail.com> wrote: > On Sat, Aug 3, 2024 at 3:45 AM Kevin Hale Boyes <kcbo...@gmail.com> wrote: > > In the for loop in WaitForLSNReplay, shouldn't the check for in-recovery be > > moved up above the call to GetXLogReplayRecPtr? > > If we get promoted while waiting for the timeout we could call > > GetXLogReplayRecPtr while not in recovery. > > This is intentional. After standby gets promoted, > GetXLogReplayRecPtr() returns the last WAL position being replayed > while being standby. So, if standby reached target lsn before being > promoted, we don't have to throw an error. > > But this gave me an idea that before the loop we probably need to put > RecoveryInProgress() check after GetXLogReplayRecPtr() too. I'll > recheck that.
The attached patchset comprises assorted improvements for pg_wal_replay_wait(). The 0001 patch is intended to improve this situation. Actually, it's not right to just put RecoveryInProgress() after GetXLogReplayRecPtr(), because more wal could be replayed between these calls. Instead we need to recheck GetXLogReplayRecPtr() after getting negative result of RecoveryInProgress() because WAL replay position couldn't get updated after. 0002 patch comprises fix for the header comment of WaitLSNSetLatches() function 0003 patch comprises tests for pg_wal_replay_wait() errors. ------ Regards, Alexander Korotkov Supabase
v1-0002-Improve-header-comment-for-WaitLSNSetLatches.patch
Description: Binary data
v1-0001-Adjust-pg_wal_replay_wait-procedure-behavior-on-p.patch
Description: Binary data
v1-0003-Add-tests-for-pg_wal_replay_wait-errors.patch
Description: Binary data
