Re: [HACKERS] make async slave to wait for lsn to be replayed - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: [HACKERS] make async slave to wait for lsn to be replayed
Date
Msg-id CAPpHfdu5QN+ZGACS+7foxmr8_nekgA2PA+-G3BuOUrdBLBFb6Q@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] make async slave to wait for lsn to be replayed  (Kevin Hale Boyes <kcboyes@gmail.com>)
Responses Re: [HACKERS] make async slave to wait for lsn to be replayed
List pgsql-hackers
On Sat, Aug 3, 2024 at 3:45 AM Kevin Hale Boyes <kcboyes@gmail.com> wrote:
> I noticed the commit and had a question and a comment.
> There is a small problem in func.sgml in the sentence "After that the changes made of primary".  Should be "on
primary".

Thank you for spotting this. Will fix.

> 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.

------
Regards,
Alexander Korotkov
Supabase



pgsql-hackers by date:

Previous
From: Kevin Hale Boyes
Date:
Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed
Next
From: Pavel Stehule
Date:
Subject: Re: proposal: schema variables