Re: [PATCH v1 0/2] Preserve input sign across numeric parameter parsing

From: Xuneng Zhou <xunengzhou(at)gmail(dot)com>
To: Haibo Yan <tristan(dot)yim(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Subject: Re: [PATCH v1 0/2] Preserve input sign across numeric parameter parsing
Date: 2026-11-13 03:16:46
Message-ID: CABPTF7UhXChj593vyJgUQCHjnJwvxypUysfZfsACh71Juf+jeQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Haibo,

Thanks for picking this up and sorry for the late reply.

On Sat, Sep 12, 2026 at 5:16 AM Haibo Yan <tristan(dot)yim(at)gmail(dot)com> wrote:
>
> Hi hackers,
>
> While looking at the WAIT FOR timeout parsing issue, I noticed that the
> underlying problem is not specific to WAIT FOR. parse_int() and parse_real()
> can lose information about the original value during unit conversion and
> rounding, before the caller gets a chance to validate it.
> For example, these are currently accepted:
>
> SET statement_timeout = '-0.5ms';
> CREATE TABLE t (i int) WITH (parallel_workers = -0.4);
> VACUUM (BUFFER_USAGE_LIMIT '-512B') t;
>
> The first is stored as 0, the reloption is accepted after -0.4 rounds to 0, and
> the VACUUM option is interpreted as the special value 0 (“no ring
> buffer limit”).
> WAIT FOR has the same issue: a timeout of ‘-0.4ms’ passes the negative check
> after rounding and becomes an indefinite wait.

I agree the problem is not specific to WAIT. But I kinda think the
lost sign is one symptom of the rounding issue during the parsing
stage. What we need to do is to read the time value exactly as it is.
I'll reply later after thinking more.

CCed Sawada-san since he suggested dealing with this separately.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhijie Hou 2026-11-13 03:58:10 Document prepared transaction lock waits with two_phase subscriptions
Previous Message JoongHyuk Shin 2026-11-13 02:50:32 Re: Deadlock detector fails to activate on a hot standby replica