Horton

Re: power() function in Windows: "value out of range: underflow"

David Rowley <david.rowley@2ndquadrant.com>

View thread View on postgr.es
From: David Rowley <david.rowley@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Huong Dangminh <huo-dangminh@ys.jp.nec.com>, Euler Taveira <euler@timbira.com.br>, "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>, Pg Hackers <pgsql-hackers@postgresql.org>, Akio Iwaasa <aki-iwaasa@vt.jp.nec.com>
Date: 2018-04-29T21:59:06Z
Lists: pgsql-bugs, pgsql-hackers 
On 30 April 2018 at 07:24, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Pushed.  I'd mainly note that you need to update all the variant float8
> expected-files, not just the primary one.  (Sometimes this requires a
> bit of guesswork, but here we're expecting all platforms to produce
> the same result.  The buildfarm should tell us if I got it wrong.)

gaur does not seem happy with this. I get the impression that pow(1,
NaN) and pow(NaN, 0) on that machine must be returning NaN and setting
errno to EDOM, and now that we're only using that code path when both
are are non-NaN we no longer hit the special case which does result =
1;

I wonder if it's better just to hard code these two cases before even
calling the pow() function.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Commits

  1. Revert back-branch changes in power()'s behavior for NaN inputs.

  2. Avoid wrong results for power() with NaN input on more platforms.

  3. Avoid wrong results for power() with NaN input on some platforms.