On Mon, Aug 17, 2026 at 6:23 PM Alexander Korotkov <[email protected]> wrote: > > On Sat, Aug 15, 2026 at 6:11 PM Xuneng Zhou <[email protected]> wrote: > > > > On Sat, Aug 15, 2026 at 11:01 AM Xuneng Zhou <[email protected]> wrote: > > > > > > On Sat, Aug 15, 2026 at 8:01 AM Alexander Korotkov <[email protected]> > > > 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().
Making sense to me. > > > 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. Thanks. > > > 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. OK, I'll share them soon. -- Regards, Xuneng Zhou HighGo Software Co., Ltd.
