On Fri, Sep 25, 2026 at 12:57 AM Daniel Gustafsson <[email protected]> wrote: > > > On 25 Sep 2026, at 07:53, Kirill Reshke <[email protected]> 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
