| 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
| 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 |