Hi, On Wed, Mar 11, 2026 at 12:45:55PM -0400, Tom Lane wrote: > Bertrand Drouvot <[email protected]> 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
