On 07/29/2018 02:03 PM, Tomas Vondra wrote: > > > On 07/29/2018 01:28 PM, Thomas Munro wrote: >> On Sun, Jul 29, 2018 at 10:57 PM, Thomas Munro >> <thomas.mu...@enterprisedb.com> wrote: >>> On Sun, Jul 29, 2018 at 10:35 PM, Tomas Vondra >>> <tomas.von...@2ndquadrant.com> wrote: >>>> It's always 0/-0 difference, and it's limited to power machines. I'll >>>> try to get access to such system and see what's wrong. >>> >>> This is suspicious: >>> >>> /* on some platforms, the preceding expression tends to produce -0 >>> */ >>> if (line->C == 0.0) >>> line->C = 0.0; >> >> I mean, it's suspiciously absent from the new line_construct() >> function. It was introduced here: >> >> commit 43fe90f66a0b200f6c32507428349afb45f661ca >> Author: Tom Lane <t...@sss.pgh.pa.us> >> Date: Fri Oct 25 15:55:15 2013 -0400 >> >> Suppress -0 in the C field of lines computed by line_construct_pts(). >> >> It's not entirely clear why some PPC machines are generating -0 here, >> since >> the underlying computation should be exactly 0 - 0. Perhaps there's some >> wider-than-nominal-precision calculations happening? Anyway, the best >> way >> to avoid platform-dependent results seems to be to explicitly reset -0 to >> regular zero. >> > > Hmm, I see. I think adding it to the else branch should do the trick, > then, I guess. But I'd be much happier if I could test it somewhere > before the commit. >
FWIW I think this should fix it. Can someone with access to an affected machine confirm? regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git a/src/backend/utils/adt/geo_ops.c b/src/backend/utils/adt/geo_ops.c index 1fb2ff2603..fefb03ee86 100644 --- a/src/backend/utils/adt/geo_ops.c +++ b/src/backend/utils/adt/geo_ops.c @@ -1024,6 +1024,9 @@ line_construct(LINE *result, Point *pt, float8 m) result->A = m; result->B = -1.0; result->C = pt->y - m * pt->x; + /* on some platforms, the preceding expression tends to produce -0 */ + if (line->C == 0.0) + line->C = 0.0; } }
