Re: BUG #17876: Function width_bucket() for float8 input returns value out of range
Mats Kindahl <mats@timescale.com>
From: Mats Kindahl <mats@timescale.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-bugs@lists.postgresql.org
Date: 2023-03-30T07:54:51Z
Lists: pgsql-bugs
Attachments
- 0001-Avoid-floating-point-overflow-in-width_bucket.patch (text/x-patch) patch 0001
On Wed, Mar 29, 2023 at 2:33 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Mats Kindahl <mats@timescale.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 >
Commits
-
Further tweaking of width_bucket() edge cases.
- a2a0c7c29e47 16.0 landed
-
Avoid overflow in width_bucket_float8().
- b0e9e4d76ca2 16.0 landed