Re: timeout value overflow in wait for lsn

> So I've reviewed the v6 patch, and here are some comments:
>
> wait.c no longer calls rint() or isnan(), so we don't need to include math.h.
>
> ---
> + The valid range is <literal>0 .. INT_MAX</literal> milliseconds.
> + A value of zero means waiting indefinitely.
>
> INT_MAX is a C identifier and it's better to avoid using it in that section.
>
> Also, the current description "The timeout might be given as integer
> number of milliseconds." seems not correct to me since pares_int()
> falls back to strtod() when the value has a decimal point. ANd the
> paragraph also doesn't mention the rounding. How about rewriting it to
> something like:
>
> <para>
> When specified and <parameter>timeout</parameter> is
> greater than zero,
> the command waits until <parameter>lsn</parameter> is reached or
> - the specified <parameter>timeout</parameter> has elapsed.
> + the specified <parameter>timeout</parameter> has elapsed. A value
> + of zero (the default) means the command waits indefinitely.
> </para>
> <para>
> - The <parameter>timeout</parameter> 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 <xref linkend="config-setting-names-values"/>).
> + The <parameter>timeout</parameter> is an amount of time in
> + milliseconds. It may also be specified as a string containing the
> + numerical value followed by a time unit
> + (see <xref linkend="config-setting-names-values"/>). The maximum
> + value is <literal>2147483647 ms</literal>.
> + </para>
> + <para>
> + Fractional values are rounded to the nearest millisecond. Note
> + that a <parameter>timeout</parameter> of half a millisecond or
> + less therefore rounds down to zero, which means waiting
> + indefinitely.
> </para>
>
> I've attached the updated patch that incorporated the above points.
> Please review it.

Thanks for updating/reviewing the patch!

LGTM.

> > I still think that it needs to be fixed in HEAD.
>
> Agreed, and I'd rather we did that on its own thread.

OK. I'll start a new thread for it when the somewhat overwhelmed v19
clean-up phase is over. I'd also be happy to help if fellow hackers
passing by decide to tackle it.

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