Re: Implement waiting for wal lsn replay: reloaded

On Sat, Aug 15, 2026 at 6:11 PM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
>
> On Sat, Aug 15, 2026 at 11:01 AM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
> >
> > On Sat, Aug 15, 2026 at 8:01 AM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> >
> > > The patchset looks good to me. I made some minor corrections.
> > >
> > > 0003 Removed extra check in WaitLSNCleanup() as deleteLSNWaiter()
> > > already does it.
> > > 0005 Improved comment about the situation on when LSN can go backwards.
> >
> > Thanks for the corrections! LGTM.
>
> + * This cannot spin. Once we are back in the heap, targetLSN is above
> + * the position we just read, so a waker can only remove us again
> + * after the position genuinely reaches the target, and then the check
> + * above ends the loop. The timeout and interrupt checks below are
> + * thus deferred by at most one iteration.
>
> After thinking more about this, it seems that repeated stale wakeups
> could turn this into spinning theoretically. I am not sure about the
> possibility of this in practice. But for cautiousness, does it make
> sense to reorder the re-registration and the timeout/interrupt
> checking?

Yes, this makes sense. I also think it's better to calculate delay_ms
just before WaitLatch().

> > For patch 0005, I was initially
> > hesitant to add a new test module because it may seem somewhat heavy
> > just to test this issue. I ended up adding it after realizing that it
> > could also be reused to test another, as-yet-unreported issue.
> >
> > I'm still wondering when it is appropriate to introduce a new test
> > module like this. I'm also not quite sure when a TAP test is warranted
> > instead of just providing a reproducer, since I spent a lot of time
> > designing this test. I'd like to hear your thoughts on them.

I think it's OK to introduce modules when test scenario can't be
reliably reached just with SQL queries. So, it must be eligible for
this case.

> > BTW, there are a few potential issues I've been investigating for a
> > while, but the fixes and constraints are still not entirely clear to
> > me, so I plan to send an off-list email about them later.

Sure, share what you have in mind off-list or on-list at your preferrence.

------
Regards,
Alexander Korotkov
Supabase