| From: | Emre Hasegeli <emre(at)hasegeli(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: mingw32 floating point diff |
| Date: | 2019-08-24 12:23:11 |
| Message-ID: | CAE2gYzzK06Sn0c+GefaUk+eRp2KyvjRN82N7jBFy0izopO-tgg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> I poked at this a bit more. I can reproduce the problem by using
> -mfpmath=387 on dromedary's host (fairly old 32-bit macOS); although
> I also get half a dozen *other* failures in the core regression tests,
> mostly around detection of float overflow. So I'm not quite sure that
> this is comparable. But at any rate, I tracked the core of the problem
> to pg_hypot:
I couldn't test if it helps, but another solution may be is to rip out
pg_hypot() in favour of the libc implementation. This was discussed
in detail as part of "Improve geometric types" thread.
Last comment about it:
https://www.postgresql.org/message-id/9223.1507039405%40sss.pgh.pa.us
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2019-08-24 14:19:19 | Re: POC: Cleaning up orphaned files using undo logs |
| Previous Message | Robert Haas | 2019-08-24 12:21:30 | Re: POC: Cleaning up orphaned files using undo logs |