Re: timeout value overflow in wait for lsn

On Thu, Aug 20, 2026 at 2:17 PM cca5507 <cca5507(at)qq(dot)com> wrote:
>
> > We have a loop in the wait infra, which means that the waiter could
> > fall asleep several times. Each time takes a INT_MAX maximumly, added
> > up toward a value larger than INT_MAX. That is why I was wondering
> > whether the bug itself warrants a truncation from 64 to 32. If there
> > are user needs like absurdly long timeouts, then we better satisfy
> > them and there're ways to do so. But in my poor imagination, waiting
> > greater than 25 days seems unlikely in reality. So I voted for the
> > limitation of the range.
> >
> > > And I think it's ok to use int64
> > > as the argument in WaitForLSN() because convert int32 to int64 is always
> > > safe.
> >
> > Yeah, it is safe only if we handle the checking/rejection properly.
> > The wait for infra is also used by repack, which uses timeout as zero
> > for an indefinite wait and 100 milliseconds for a finite wait. So it
> > is not vulnerable to edge cases like this. But the infra could have
> > more potential callers in the future, we better not let them bother
> > the extra safety if we can deal with it easily. Sorry if this seems
> > nitpicking to you.
>
> Make sense to me. The v2 patch forgets to update the type of the timeout
> variable in repack worker, fixed in v3.

Thanks. WFM.

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