On Fri, Sep 25, 2026 at 12:57 AM Daniel Gustafsson <daniel@yesql.se> wrote:
>
> > On 25 Sep 2026, at 07:53, Kirill Reshke <reshkekirill@gmail.com> wrote:
> >
> > repro:
> >
> > reshke=# wait for lsn '1/01C96E58' with (timeout '-1ms');
> > ERROR: timeout cannot be negative
> > reshke=# wait for lsn '1/01C96E58' with (timeout '-0.4ms');
> > ^CCancel request sent
> > ERROR: canceling statement due to user request
> >
> > I think we need to reject '-0.4ms' in the same way as '-1ms'.
>
> This can also be seen as working as documented based on the following paragraph
> (which might then need a s/down/ applied):
>
> "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."
>
> The passed value is fractional and is rounded to zero with an indefinite wait.
> I'm not convinced we need to spend code on handling a value which works as
> documented, and doesn't make sense as a timeout in the first place.
Yes. Since it uses parse_int(), some GUC parameters that accept an
integer value with a unit behaves the same way:
=# set statement_timeout to '-1ms';
ERROR: -1 ms is outside the valid range for parameter
"statement_timeout" (0 ms .. 2147483647 ms)
=# set statement_timeout to '-0.4ms';
SET
=# show statement_timeout ;
statement_timeout
-------------------
0
(1 row)
We agree it might be better to reject such negative values too, but we
agreed it's reasonable to keep the same behavior as other integer GUC
parameters, rather than adding code just to handle the WAIT command
case[1].
Regards,
[1] https://www.postgresql.org/message-id/CAD21AoDpeNo7ZLNcqp3u51FBoXbMft8gvaEn-FXcoGpEZz8V%3Dg%40mail.gmail.com
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
