Re: Regression error on float8 - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Regression error on float8
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCEA352EC@algol.sollentuna.se
Whole thread Raw
In response to Regression error on float8  ("Magnus Hagander" <mha@sollentuna.net>)
Responses Re: Regression error on float8  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
> > I'm getting the following regression errors with a backend
> built using
> > Visual C++:
>
> Is HAVE_CBRT getting defined?  Either their cbrt() routine or
> our default one seems to be generating slightly-off answers.
> The default one (at the bottom of float.c) certainly looks a
> bit cheesy, but if it fails this test you'd think we'd have
> heard about that sooner.

HAVE_CBRT is not set.

If I undefine HAVE_CBRT on Linux, I get the exact same failure! So it
seems our own version of cbrt() is broken wrt our own regression tests
:-( Must be that nobody else (at least on i386) uses that code.

The mingw version does appear to work, but it's noticably more complex,
see
http://cvs.sourceforge.net/viewcvs.py/mingw/runtime/mingwex/math/cbrt.c?
rev=1.1&view=auto.

It's placed in the public domain, so we should be able to use it if we
want to
(http://cvs.sourceforge.net/viewcvs.py/mingw/runtime/DISCLAIMER?rev=1.1&
view=auto).

What do you think is best - try to adapt that version, or update our
regression tests outputs to accept the output from our current code?

//Magnus



pgsql-hackers by date:

Previous
From: Gevik Babakhani
Date:
Subject: TODO Item: ACL_CONNECT
Next
From: Mark Wong
Date:
Subject: Re: Further reduction of bufmgr lock contention