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
