Re: Implement waiting for wal lsn replay: reloaded

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?

> 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.
>
> 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.

--
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.