Re: timeout value overflow in wait for lsn

Hi ChangAo,

On Wed, Aug 19, 2026 at 9:41 PM cca5507 <cca5507(at)qq(dot)com> wrote:
>
> Hi,
>
> The valid range of the timeout value in wait for lsn command is int64, which can overflow
> later in WaitForLSN():
>
> ```
> postgres=# wait for lsn '99/99999999' with (mode 'primary_flush', timeout '10000000000000000ms');
> ERROR: timed out while waiting for target LSN 99/99999999 to be flushed; current primary_flush LSN 0/017CA348
> Time: 0.584 ms
> ```
>
> To fix it, change the valid range to int32, just like deadlock_timeout and many other GUCs.
>
> Thoughts?

Good catch. I am not sure about the fix. The likely cause of overflow is:

#define TimestampTzPlusMilliseconds(tz, ms) \
((tz) + ((ms) * (int64) 1000))

values far greater than int32 could be a problem. But does this
warrant a truncation to int32? Yeah, from a pragmatic perspective,
these off-charts values are not expected in practice since the users
don't have and better not have this amount of patience for latency.
But truncating it alone like

+ if (unlikely(isnan(dval) || !FLOAT8_FITS_IN_INT32(dval)))

seems not adequate to me -- the interface supports int 64, it seems
not good to accept it first and then reject it loudly later. If this
change is desired, we might need to change the interface as well.
Another direction is to prevent the overflow while preserving the
current value by checking the timeout with

if (pg_mul_s64_overflow(timeout, USECS_PER_MSEC, &timeout_us) ||
pg_add_s64_overflow(now, timeout_us, &endtime) ||
!IS_VALID_TIMESTAMP(endtime))

but this seems unprecedented for a timeout value. It would be helpful
to hear Alexander's thoughts on this.

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