Hi,
On Wed, Mar 11, 2026 at 12:45:55PM -0400, Tom Lane wrote:
> Bertrand Drouvot <bertranddrouvot.pg@gmail.com> writes:
> > On Wed, Mar 11, 2026 at 11:19:45AM -0400, Tom Lane wrote:
> >> The defenses in those modules are probably obsolete too: aren't they about
> >> ensuring exact results with floating-point timestamps? My gut reaction to
> >> this was maybe we could remove *all* of that, so now I'm curious what
> >> problem Bertrand ran into.
>
> > I got some regression tests failing: [1].
>
> Yeah. I quickly tried it here (ie remove the defenses and build with
> -ffast-math), and observed failures in a couple dozen core regression
> tests. A bit of study suggests that
>
> (1) both isnan() and isinf() tests are broken and always return false,
> at least in some call sites;
>
> (2) the code now seems exceedingly cavalier about near-overflow cases,
> such as
>
> regression=# select 1.175494e-38::float4;
> ERROR: "0.00000000000000000000000000000000000001175494" is out of range for type real
>
> which is a case that works fine normally.
>
> So no, I don't wanna support this.
Yeah, that would be a nightmare to support.
> But maybe we should move the
> code-level tests out of the datetime files and into utils/float.h
> or some such place.
But still, I'm not sure the code-level guard is enough for meson. I think we
need to put a guard in meson.build for the "oddity" described in [1]:
it compiles fine with CFLAGS="-ffast-math" CC="gcc" meson setup meson_build but
produces issues during the regression tests.
I just had a closer look and it looks like that the reason is that it's being
added at link time:
$ cat meson_build/build.ninja | grep LINK_ARGS | grep -c "ffast-math"
254
So that the code-level is ok, but the tests fail.
[1]: https://postgr.es/m/abGO%2BBl1FQlpvFAt%40ip-10-97-1-34.eu-west-3.compute.internal
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
