Re: [HACKERS] make async slave to wait for lsn to be replayed

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Kevin Hale Boyes <kcboyes(at)gmail(dot)com>
Cc: Kartyshov Ivan <i(dot)kartyshov(at)postgrespro(dot)ru>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, hlinnaka(at)iki(dot)fi, alvherre(at)alvh(dot)no-ip(dot)org, pashkin(dot)elfe(at)gmail(dot)com, bharath(dot)rupireddyforpostgres(at)gmail(dot)com, euler(at)eulerto(dot)com, thomas(dot)munro(at)gmail(dot)com, peter(at)eisentraut(dot)org, amit(dot)kapila16(at)gmail(dot)com, dilipbalaut(at)gmail(dot)com, smithpb2250(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed
Date: 2024-08-10 17:18:53
Message-ID: CAPpHfdsgKwR5ifuBTdB4sOA1=h28=0tUHjaWRWi0C_VZR5PMdg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Aug 10, 2024 at 7:33 PM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> On Tue, Aug 6, 2024 at 5:17 AM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> > On Sat, Aug 3, 2024 at 6:07 AM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> > > On Sat, Aug 3, 2024 at 3:45 AM Kevin Hale Boyes <kcboyes(at)gmail(dot)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.

The next revison of the patchset fixes uninitialized variable usage
spotted by cfbot.

------
Regards,
Alexander Korotkov
Supabase

Attachment Content-Type Size
v3-0002-Improve-header-comment-for-WaitLSNSetLatches.patch application/octet-stream 1.0 KB
v3-0001-Adjust-pg_wal_replay_wait-procedure-behavior-on-p.patch application/octet-stream 5.5 KB
v3-0003-Add-tests-for-pg_wal_replay_wait-errors.patch application/octet-stream 2.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2024-08-10 17:25:29 Re: SPI_connect, SPI_connect_ext return type
Previous Message Tom Lane 2024-08-10 16:57:36 Re: is_superuser versus set_config_option's parallelism check