From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Peter J(dot) Holzer" <hjp-pgsql(at)hjp(dot)at> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org, Carsten Klein <c(dot)klein(at)datagis(dot)com> |
Subject: | Re: Strange results when casting string to double |
Date: | 2022-02-18 21:58:06 |
Message-ID: | 4159419.1645221486@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Peter J. Holzer" <hjp-pgsql(at)hjp(dot)at> writes:
> Another idea: It could be the case that something (maybe a bug in
> postgres, maybe an extension, maybe even a random bit flip in memory)
> changed the FP rounding mode within the postgres process, which would
> affect all FP computations until the rounding mode is reset. That would
> have to have happened in the master to affect the worker processes as
> consistently as you are seeing. I don't know if it is even possible for
> a non-standard rounding mode to persist for any length of time, but if
> it is it would certainly account for weird rounding errors.
Hmm, that is a pretty interesting theory. On a RHEL8 box, I find
that fesetround(FE_DOWNWARD) causes strtod("1.56", NULL) to return
1.55999999999999983124
rather than the usual
1.56000000000000005329
which seems to square with Carsten's symptom.
Postgres itself contains no fesetround calls, but if you want
to believe a random bit flip changed that mode, maybe that'd
account for it. It'd certainly be interesting to find out
whether the problem persists after a postmaster restart.
[ wanders away wondering if the troublesome machine has ECC
memory ... ]
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bryn Llewellyn | 2022-02-19 01:15:58 | Re: alter function/procedure depends on extension |
Previous Message | Peter J. Holzer | 2022-02-18 21:42:49 | Re: Strange results when casting string to double |