Re: timeout value overflow in wait for lsn

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: cca5507 <cca5507(at)qq(dot)com>
Cc: Xuneng Zhou <xunengzhou(at)gmail(dot)com>, 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-28 19:11:10
Message-ID: CAD21AoB3jJsXFPjaRHWC_A26u26DK0=rF9x2SynT6mr_owtTwA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 28, 2026 at 2:11 AM cca5507 <cca5507(at)qq(dot)com> wrote:
>
> > I found another issue around timeout value handling: if we specify a
> > timeout in [-0.5, 0.5], the WAIT FOR command waits forever. A negative
> > timeout in [-0.5, 0) should be rejected. ISTM a timeout in (0, 0.5] is
> > rounded down to 0, disabling the timeout essentially, which would
> > surprise users. I think we can either round up timeout in (0, 1] to 1,
> > or reject sub-millisecond values. I think we can fix both in the same
> > patch that fixes the overflow issue.
>
> Good catch! Fixed by moving the negative check before rint() and rounding
> timeout in (0, 1) to 1.
>
> Please see the v4 patch.

Thank you for updating the patch! Here are review comments:

+ if (dval < 0.0)
+ ereport(ERROR,
+ errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("timeout cannot be negative"));

Let's add parser_errposition() here.

Probably we can add the same to other ereport(ERROR) handling a
timeout option value.

---
/*
* Get rid of any fractional part in the input. This is so we
* don't fail on just-out-of-range values that would round into
- * range.
+ * range. Round values in (0, 1) up to 1 to avoid treating them as
+ * zero, which means waiting indefinitely.
*/
- dval = rint(dval);
+ if (dval > 0.0 && dval < 1.0)
+ dval = 1.0;
+ else
+ dval = rint(dval);

The first paragraph is for the else branch whereas the second
paragraph is for the if branch. I think we can write these comments
separately in each branch instead.

---
The documentation says "The timeout might be given as integer number
of milliseconds. Also it might be given as string literal with integer
number of milliseconds or a number with unit (see Section 19.1.1).",
which seems incorrect to me as we parse the timeout value using
parse_real(), clearly accepting real values. Or should we have used
parse_int() in the first place?

Also, I think it's better to mention the maximum value accepted as a
timeout value.

---
I think it's better to add regression tests for the timeout option.
049_wait_for_lsn.pl would be a good place to have them.

---
The patch needs to run pgindent.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2026-08-28 19:15:02 Re: pg_stat_get_autovacuum_scores ignores the main table's reloptions for TOAST tables
Previous Message Daniel Gustafsson 2026-08-28 19:07:53 Re: Changing the state of data checksums in a running cluster