On 09/27/2018 12:48 AM, Tom Lane wrote:
Tomas Vondra <tomas.von...@2ndquadrant.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
