Carsten Klein <c.klein@datagis.com> writes:
> @Tom Lane: you say, PostgreSQL does not / cannot change rounding mode at
> any time? There is no function to do so? So, the script (it's more like
> a module) must provide a Shared Object module with a C function in order
> to change the FPU's rounding mode?
Per grep, there is no call of fesetround() in the Postgres source
tree. I'm not sure offhand whether libc exposes any other APIs
that could change the rounding mode, but I am quite sure that we
wouldn't be intentionally changing it anywhere.
> I will try a restart of the DB ASAP. However, in order to prove the
> rounding mode thesis: someone knows whether fesetround(FE_DOWNWARD) just
> sets a flag in the C runtime environment or does this call actually set
> the rounding mode in the FPU's control word? Is there any chance to get
> that current rounding mode with or even without a debugger? (Maybe some
> file in /proc filesystem?)
The OS would surely allow each process to have its own setting of the
rounding mode, so I doubt you can see it from outside.
Another point to keep in mind is that no matter how invasive that
import script might be, it's still hard to explain how it'd affect
the rounding mode in other backend processes. You have to postulate
either that the rounding mode has been changed in the postmaster
process (and then inherited by session backends via fork()), or that
some code running at the time of child process creation changes the
mode, or that they replaced numeric_float8 with something else.
I think the only way that the postmaster's rounding mode could change
after postmaster start is the cosmic-ray hypothesis; while we do have
features that'd allow loading extra code into the postmaster, I'm
pretty sure they only take effect at postmaster start. So even if
that import script tried to do that, it wouldn't have succeeded yet.
Of the other two hypotheses, "substitute numeric_float8" seems like
the most likely, especially given the other stuff you mentioned the
script doing. Have you checked the relevant pg_cast entry to see
if it's been changed? It'd also be interesting to see if the odd
rounding behavior happens in all databases of the cluster or just
one.
regards, tom lane