Carsten Klein 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
On 19.02.2022 20:34 Tom Lane wrote:
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.
The OS would
Carsten Klein 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, t
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` (regula
On Sat, Feb 19, 2022 at 8:35 AM Tomas Pospisek wrote:
>
> On 18.02.22 22:42, Peter J. Holzer wrote:
>
> > If there has been a glibc update (or a postgresql update) in those 480
> > days (Ubuntu 14.04 is out of its normal maintenance period but ESM is
> > still available) the running processes may
On 18.02.22 22:42, Peter J. Holzer wrote:
If there has been a glibc update (or a postgresql update) in those 480
days (Ubuntu 14.04 is out of its normal maintenance period but ESM is
still available) the running processes may well run different code than
a newly started program. So it could be a
"Peter J. Holzer" 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 rese
On 2022-02-18 18:07:35 +0100, Carsten Klein wrote:
> both PostgreSQL and my C program are linked to the same libc.so.6. Same
> path, same MD5 sum. Since libc is a Shared Object (so), both processes
> should really run the identical code. Am I missing something? I've written
> and compiled the small
Carsten Klein writes:
> So, you're not aware of any ways this behavior could be achieved from
> within PostgreSQL? Something like a custom cast (actually, there is
> none) or something that could intercept string to double conversion?
Well, you asserted that these installations are all alike .
On 18.02.2022 16:32, Tom Lane wrote:
Yeah, you said that upthread, which makes the whole thing pretty
baffling. One possible explanation is that your small program got linked
against a different version of libc than what the Postgres backend is
using ("ldd" would help you check that, but giv
Carsten Klein writes:
> On 18.02.2022 13:28, Peter Eisentraut wrote:
>> float8in() really just calls the operating system's strtod() function. I
>> would test that one directly with a small C program.
> That's what I did. Here's my small C program: (nicht lachen *g*)
Yeah, you said that upthrea
On 18.02.2022 13:28, Peter Eisentraut wrote:
float8in() really just calls the operating system's strtod() function. I
would test that one directly with a small C program.
It's also possible that different compiler options lead to different
optimizations.
That's what I did. Here's my sma
On 16.02.22 14:27, Carsten Klein wrote:
AFAIK, this conversion is done by internal function float8in, which,
when called directly, yields the same results:
SELECT float8in('1.56');
--> 1.55 (wrong!) on one server, and
--> 1.56 (correct!) on all other servers.
fl
AOn Thu, Feb 17, 2022 at 10:27 AM Peter J. Holzer wrote
I don't think these explain the difference. I'd check whether the
postgresql binaries and all the the shared libraries are the same.
Or - since this only happens on the test system and not on the production
system - I'd just clone the p
On 2022-02-16 22:02:02 +0100, Carsten Klein wrote:
> On of the virtualized servers was created as a clone of the other one (using
> VMware to clone the VM). So, basically, these are very equal. Of course,
> they diverged over time.
>
> Focusing on PostgreSQL, here are the differences of postgresql
On Thu, Feb 17, 2022 at 09:41 AM Thomas Kellerer wrote:
Carsten Klein schrieb am 16.02.2022 um 14:27:
Ah, man versteht sich :)
I'm using several (now unsupported) PostgreSQL 9.3.24 servers on
different (ancient) Ubuntu 14.04 LTS machines. On only one of those
servers, I get strange/wrong result
Carsten Klein schrieb am 16.02.2022 um 14:27:
> I'm using several (now unsupported) PostgreSQL 9.3.24 servers on
> different (ancient) Ubuntu 14.04 LTS machines. On only one of those
> servers, I get strange/wrong results when converting a string into a
> double value:
>
> SELECT 1.56::double preci
On Thu, Feb 17, 2022 at 00:07 Gavan Schneider wrote:
Harking back to my long distant formative years I was taught to never ever rely
on equality tests when it came to floating point values. Nothing has changed in
this regard.
If binary exact is part of the requirement then the answer is I
On 17 Feb 2022, at 8:02, Carsten Klein wrote:
> We have a trigger, that monitors such updates and it reports a changed value,
> which is not correct. The problem is, that the assignment
>
> SET xyz = 1.56
>
> actually means
>
> SET xyz = 1.55999
>
> since getting a double value from the strin
On Wed, Feb 16, 2022 at 08:11 PM David G. Johnston wrote:
You said they are more or less the same. Problems like these tend to
hide in the "less" portion of the inequality.
On of the virtualized servers was created as a clone of the other one
(using VMware to clone the VM). So, basically,
On Wed, Feb 16, 2022 at 11:38 AM Carsten Klein wrote:
>
>
> On Wed, Feb 16, 2022 at 05:46 PM Adrian Klaver wrote
> > On 2/16/22 05:27, Carsten Klein wrote:
> >> Hi there,
> >>
> >> I'm using several (now unsupported) PostgreSQL 9.3.24 servers on
> >> different (ancient) Ubuntu 14.04 LTS machines.
On Wed, Feb 16, 2022 at 05:46 PM Adrian Klaver wrote
On 2/16/22 05:27, Carsten Klein wrote:
Hi there,
I'm using several (now unsupported) PostgreSQL 9.3.24 servers on
different (ancient) Ubuntu 14.04 LTS machines. On only one of those
servers, I get strange/wrong results when converting a
On 2/16/22 05:27, Carsten Klein wrote:
Hi there,
I'm using several (now unsupported) PostgreSQL 9.3.24 servers on
different (ancient) Ubuntu 14.04 LTS machines. On only one of those
servers, I get strange/wrong results when converting a string into a
double value:
Has anyone an idea of wh
Hi there,
I'm using several (now unsupported) PostgreSQL 9.3.24 servers on
different (ancient) Ubuntu 14.04 LTS machines. On only one of those
servers, I get strange/wrong results when converting a string into a
double value:
SELECT 1.56::double precision;
--> 1.55 (wrong!)
A
24 matches
Mail list logo
