From: | Mats Kindahl <mats(at)timescale(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17876: Function width_bucket() for float8 input returns value out of range |
Date: | 2023-03-30 07:54:51 |
Message-ID: | CA+14424DZUcLpWnoRURmT1m6Uet1_R39sV=8XhtFRiigVtYqDg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, Mar 29, 2023 at 2:33 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Mats Kindahl <mats(at)timescale(dot)com> writes:
> > Attached is a proposed fix for the issue.
>
> Hm. Aren't you replacing a risk of overflow with a risk of underflow?
> I'd be happier about doing this only if isinf(bound2 - bound1), or
> the reverse for the other path. (Seems like we shouldn't need to
> check the operand diff separately.)
>
Yes, I was wondering the same which is why I was adding these tests as a
separate file to see if I could force a bad bucket. It seems to be hard to
construct a case where the underflow would cause a change in the result.
However, better safe than sorry, so I modified the patch to include the
check. And yes, you're right in that there is no need to check for the
operand diff since the previous checks guarantee that the operand is
between the bounds, and since the diff between the bounds is not infinite,
the diff between the operand and any of the bounds cannot be infinite.
Added a comment to that effect to the patch as well.
Best wishes,
Mats Kindahl, Timescale
> regards, tom lane
>
Attachment | Content-Type | Size |
---|---|---|
0001-Avoid-floating-point-overflow-in-width_bucket.patch | text/x-patch | 6.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Devrim Gündüz | 2023-03-30 08:45:57 | Re: Postgres common repo is missing geos310-3.10.3-1.rhel8.x86_64 |
Previous Message | Richard Guo | 2023-03-30 07:01:52 | Re: Clause accidentally pushed down ( Possible bug in Making Vars outer-join aware) |