Re: Implement waiting for wal lsn replay: reloaded

Hi,

On Wed, Nov 5, 2025 at 5:51 PM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
>
> Hi!
>
> On Mon, Nov 3, 2025 at 5:13 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On 2025-11-03 16:06:58 +0100, Álvaro Herrera wrote:
> > > On 2025-Nov-03, Alexander Korotkov wrote:
> > >
> > > > I'd like to give this subject another chance for pg19. I'm going to
> > > > push this if no objections.
> > >
> > > Sure. I don't understand why patches 0002 and 0003 are separate though.
> >
> > FWIW, I appreciate such splits. Even if the functionality isn't usable
> > independently, it's still different type of code that's affected. And the
> > patches are each big enough to make that worthwhile for easier review.
>
> Thank you for the feedback, pushed.
>
> > One thing that'd be nice to do once we have WAIT FOR is to make the common
> > case of wait_for_catchup() use this facility, instead of polling...
>
> The draft patch for that is attached. WAIT FOR doesn't handle all the
> possible use cases of wait_for_catchup(), but I've added usage when
> it's appropriate.
>
> ------
> Regards,
> Alexander Korotkov
> Supabase

I tested the patch using make check-world, and it worked well. I also
made a few adjustments:

- Added an unconditional chomp($isrecovery) after querying
pg_is_in_recovery() to prevent newline mismatches when $target_lsn is
accidently defined.
- Added chomp($output) to normalize the result from WAIT FOR LSN
before comparison.

At the moment, the WAIT FOR LSN command supports only the replay mode.
If we intend to extend its functionality more broadly, one option is
to add a mode option or something similar. Are users expected to wait
for flush(or others) completion in such cases? If not, and the TAP
test is the only intended use, this approach might be a bit of an
overkill.

--
Best,
Xuneng