Horton

Re: Implement waiting for wal lsn replay: reloaded

Xuneng Zhou <xunengzhou@gmail.com>

View thread
From: Xuneng Zhou <xunengzhou@gmail.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Álvaro Herrera <alvherre@kurilemu.de>, pgsql-hackers <pgsql-hackers@lists.postgresql.org>, Michael Paquier <michael@paquier.xyz>, jian he <jian.universality@gmail.com>, Tomas Vondra <tomas@vondra.me>, Yura Sokolov <y.sokolov@postgrespro.ru>
Date: 2025-11-16T14:01:04Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Clean up 019_replslot_limit.pl comments

  2. Stabilize 019_replslot_limit.pl: wait on slot restart_lsn

  3. Use WAIT FOR LSN in PostgreSQL::Test::Cluster::wait_for_catchup()

  4. Add tab completion for the WAIT FOR LSN MODE option

  5. Add the MODE option to the WAIT FOR LSN command

  6. Extend xlogwait infrastructure with write and flush wait types

  7. Unify error messages

  8. Optimize shared memory usage for WaitLSNProcInfo

  9. Fix WaitLSNWakeup() fast-path check for InvalidXLogRecPtr

  10. Fix incorrect function name in comments

  11. Add infrastructure for efficient LSN waiting

  12. Add pairingheap_initialize() for shared memory usage

  13. Implement WAIT FOR command

Hi!

On Sun, Nov 16, 2025 at 8:37 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
>
> On Wed, Nov 12, 2025 at 9:20 AM Xuneng Zhou <xunengzhou@gmail.com> wrote:
> > On Wed, Nov 5, 2025 at 5:51 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> > > On Mon, Nov 3, 2025 at 5:13 PM Andres Freund <andres@anarazel.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.
> >
> > 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.
>
> I would say that adding mode parameter seems to be a pretty natural
> extension of what we have at the moment.  I can imagine some
> clustering solution can use it to wait for certain transaction to be
> flushed at the replica (without delaying the commit at the primary).
>
> ------
> Regards,
> Alexander Korotkov
> Supabase

Makes sense. I'll play with it and try to prepare a follow-up patch.

--
Best,
Xuneng