On 19.02.2022 15:35, Tomas Pospisek wrote:
That would be visible via `lsof`. `libc. The file `...libc...so` that
`postgres` is keeping open would have the text `DEL` (as in deleted) in
the `FD` column of `lsof`'s output.
As opposed to a newly started program which would have `REG` (regular
file) there.
*t
Actually, PostgreSLQ uses the same libc than any recently started
program. lsof reports REG and my /lib/x86_64-linux-gnu/libc-2.19.so has
file date Mar 27, 2019, so it's much older than the point in time when
PostgreSQL was started the last time (aprx. 480 days ago).
After all, I guess the idea of a wrong rounding setting (set to round
down, raised by Peter J. Holzer) seems most plausible to me. In
particular, since the "right" and "wrong" values caused by wrong
rounding shown by Tom Lane are exactly the values I am seeing.
Also, there is a quite aggressive import script running for some days,
which even tried to replace some of the core functions, like
array_length (it added a pure PL/pgSQL version in public schema). Seems
like they wanted to "Polyfill" some required functions. Maybe that
script is responsible for changing the process' rounding mode? The
customer started that script without thinking too much about it... :(
@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?
Because several people recommended using a debugger in order to see
whats going on here: actually I have no expertise with debugging on
Linux without an IDE. So I did not yet think of using a debugger so far.
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?)
I'm very unhappy with the customer starting that import script. In order
to find the `smoking gun`, I will now have a closer look at the
"product" that import is based on and what they have done to the database...
Regards, Carsten
