Carsten Klein <c.klein@datagis.com> writes:
> Prior to restarting, I've implemented my own Python based versions of both
> int fegetround(void);
> int fesetround(int rounding_mode integer);
Ah, good idea!
> With those, I was able to proof, that actually the "wrong" rounding mode
> FE_DOWNWARD (0x400)
> was in effect for every new process/connection with all the described
> effects on casting from string or numeric to double precision:
Thanks for confirming that that was the source of the problem.
> We'll likely never know, why ever the postmaster got tainted with that
> FE_DOWNWARD (0x400) rounding mode.
Indeed. It's hard to see any other explanation than "random bit flip"
though. The postmaster is designed to run only a very small amount of
code, almost none of which is user-controllable. Even if there were
somewhere some code that intended to change the rounding mode, explaining
how the postmaster got to that without crashing is a tall order.
> Two official math functions to get and set the session's rounding mode
> provided by PostgreSQL could be a good add-on for any of the next
> versions of the database. Thinking about it again... maybe that's just
> too dangerous :-p
No, we'd absolutely not ever provide a supported function to change
rounding modes. That would require downgrading all float-related
functions from IMMUTABLE to STABLE, which would have severe performance
consequences, even for people with no interest in changing modes.
Thanks for closing out the thread with this info!
regards, tom lane