Re: [PATCH] Improve geometric types

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(dot)munro(at)enterprisedb(dot)com> wrote:
>>> On Sun, Jul 29, 2018 at 10:35 PM, Tomas Vondra
>>> <tomas(dot)vondra(at)2ndquadrant(dot)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 <tgl(at)sss(dot)pgh(dot)pa(dot)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