From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | emre(at)hasegeli(dot)com, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [PATCH] Improve geometric types |
Date: | 2018-09-27 10:57:12 |
Message-ID: | b738ef47-bcb9-940b-7b9f-5436408d7f6b@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 09/27/2018 12:48 AM, Tom Lane wrote:
> Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
>> On 09/26/2018 06:45 PM, Tom Lane wrote:
>>> gaur's not happy, but rather surprisingly, it looks like we're
>>> mostly OK elsewhere. Do you need me to trace down exactly what's
>>> going wrong on gaur?
>
>> Or you could just try doing
>> select '(0,0)'::point * '(-3,4)'::point;
>> If this is what's going on, I'd say the best solution is to make it
>> produce (0,0) everywhere, so that we don't expect -0.0 anywhere.
>
> Actually, it seems simpler than that: gaur produces plus zero already
> from the multiplication:
>
> regression=# select '-3'::float8 * '0'::float8;
> ?column?
> ----------
> 0
> (1 row)
>
> whereas I get -0 elsewhere. I'm surprised that this doesn't create
> more widely-visible regression failures, but there you have it.
>
Hmmm, interesting. But I still don't quite understand why the test
program still produced -0.000000 and not 0.000000. That seems like a
direct contradiction to what we see in regression tests, doesn't it?
>> We could do that either by adding the == 0.0 check to yet another place,
>> or to point_construct() directly. Adding it to point_construct() means
>> we'll pay the price always, but I guess there are few paths where we
>> know we don't need it. And if we add it to many places it's likely about
>> as expensive as adding it to point_construct.
>
> If gaur is the only machine showing this failure, which seems more
> likely by the hour, I'm not sure that we should give up performance
> across-the-board to make it happy. Perhaps a variant expected-file
> is a better answer; or we could remove these specific test cases.
>
> Anyway, I'd counsel doing nothing for a day or so, till the buildfarm
> breakage from the strerror/snprintf changes clears up. Then we'll
> have a better idea of whether any other machines are affected.
>
Yep, gaur seems to be the only animal affected by this, so no need to
rush anyway.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-09-27 12:51:55 | Re: Problem while setting the fpw with SIGHUP |
Previous Message | Amit Kapila | 2018-09-27 10:49:02 | Re: Problem while setting the fpw with SIGHUP |