Hi Fujii-san, On Tue, Oct 21, 2025 at 7:45 AM Fujii Masao <[email protected]> wrote: > > On Mon, Oct 20, 2025 at 1:45 PM Shinya Kato <[email protected]> wrote: > > > > On Mon, Oct 20, 2025 at 10:17 AM Fujii Masao <[email protected]> wrote: > > > > > > On Sun, Oct 19, 2025 at 2:04 AM Shinya Kato <[email protected]> > > > wrote: > > > > Thank you for the patch. I have one comment. > > > > > > > > + if (lag_tracker->overflowed[head].lsn > lsn) > > > > + return now - lag_tracker->overflowed[head].time; > > > > > > > > Could this return a negative value if the clock somehow went > > > > backwards? The original code returns -1 in this case, so I'm curious > > > > about this. > > > > > > Thanks for the review! > > > > > > Yes, you're right. So I've updated the patch so that -1 is returned > > > when the current time is earlier than the time in the overflow entry, > > > treating it as "no new sample found". > > > > Thank you for updating the patch. It looks nice to me. > > Thanks for the review! > Unless there are any objections, I'll commit the patch and > backpatch it to all supported branches. >
Thanks for working on this. The patch LGTM. I am wondering whether it is helpful to add some comments for this overflowed array WalTimeSample overflowed[NUM_SYNC_REP_WAIT_MODE]; and replacing literal zeros with the constant InvalidXLogRecPtr for better readability. /* InvalidXLogRecPtr means no overflow yet */ if (lag_tracker->overflowed[i].lsn == InvalidXLogRecPtr) Best, Xuneng
