Re: timeout value overflow in wait for lsn

From: cca5507 <cca5507(at)qq(dot)com>
To: Xuneng Zhou <xunengzhou(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Subject: Re: timeout value overflow in wait for lsn
Date: 2026-08-20 03:12:47
Message-ID: tencent_59EDE0C0CE2334BB30B0D63B0542A6022F05@qq.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Changing the check to FLOAT8_FITS_IN_INT32 would reject larger values.
> If we choose that limit, the timeout variable and the WaitForLSN()
> argument should also use int so that the interface matches the
> accepted range.
>
> Alternatively, we can preserve the int64 interface and check the
> deadline calculation in WaitForLSN():
>
>     if (pg_mul_s64_overflow(timeout, USECS_PER_MSEC, &timeout_us) ||
>         pg_add_s64_overflow(now, timeout_us, &endtime) ||
>         !IS_VALID_TIMESTAMP(endtime))
>
> -----------------
>
> Another option is to reject values greater than or equal with
> INT64_MAX/1000, which seems a bit hacky to me.

The max timeout value supported by WaitLatch() is INT_MAX, so I think
it's reasonable to limit the range to int32. And I think it's ok to use int64
as the argument in WaitForLSN() because convert int32 to int64 is always
safe.

--
Regards,
ChangAo Chen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2026-08-20 03:41:13 Re: Logical Replication - revisit `is_table_publication` function implementation
Previous Message Aditya Gollamudi 2026-08-20 03:01:04 Re: Report bytes and transactions actually sent downtream