Re: timeout value overflow in wait for lsn

From: Xuneng Zhou <xunengzhou(at)gmail(dot)com>
To: cca5507 <cca5507(at)qq(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(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-30 03:04:50
Message-ID: CABPTF7U3Yo3Tp6MVArwQwsWkWTBUf9j9azgf=oFDuY2btBrCAQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Changao, Sawada-san,

On Sat, Aug 29, 2026 at 6:02 PM cca5507 <cca5507(at)qq(dot)com> wrote:
>
> > 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.
>
> Fixed.
>
> > ---
> > /*
> > * 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.
>
> Fixed.
>
> > ---
> > 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?
>
> I think it's ok to use parse_real() here because parse_int() also accepts
> real values.

I think there's still subtlety regarding the use of parse_real() or
parse_int() and how to handle fractional values. I'll reply later for
this.

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

Mentioning the max value in doc seems useful to me, despite no
precedents of timeout have done so even if they share the same
capping.

+ The valid range is from 0 to 2,147,483,647 milliseconds, inclusive.
+ A value of zero means waiting indefinitely.

2,147,483,647 milliseconds seems ok for agents to read but not very
interpretable to humans. I doubt that few people would actually type
it manually. The main use here seems to let users have a vague concept
of the max value, so it might be helpful to convert that value to
something that humans can read like xx days.

> > ---
> > 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.
>
> Fixed.
>
> > ---
> > The patch needs to run pgindent.
>
> Fixed.
>
> Please see the v5 patch.
>
> --
> Regards,
> ChangAo Chen

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Srinath Reddy Sadipiralla 2026-08-30 04:24:00 pg_rewind: Remove recovery at the start of rewind
Previous Message Henson Choi 2026-08-30 02:04:06 Re: Row pattern recognition