On Wed, Nov 12, 2025 at 9:20 AM Xuneng Zhou <[email protected]> wrote: > On Wed, Nov 5, 2025 at 5:51 PM Alexander Korotkov <[email protected]> > wrote: > > On Mon, Nov 3, 2025 at 5:13 PM Andres Freund <[email protected]> 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
