On Tue, Aug 6, 2024 at 5:17 AM Alexander Korotkov <aekorot...@gmail.com> wrote: > 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.
Here is a revised version of the patchset. I've fixed some typos, identation, etc. I'm going to push this once it passes cfbot. ------ Regards, Alexander Korotkov Supabase
v2-0002-Improve-header-comment-for-WaitLSNSetLatches.patch
Description: Binary data
v2-0001-Adjust-pg_wal_replay_wait-procedure-behavior-on-p.patch
Description: Binary data
v2-0003-Add-tests-for-pg_wal_replay_wait-errors.patch
Description: Binary data
