Re: Interval aggregate regression failure (expected seems - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Interval aggregate regression failure (expected seems
Date
Msg-id 200606142252.k5EMqui11765@candle.pha.pa.us
Whole thread Raw
In response to Re: Interval aggregate regression failure (expected seems  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Interval aggregate regression failure (expected seems  (Michael Glaesemann <grzm@myrealbox.com>)
List pgsql-hackers
I assume no more progress has been made on this?

---------------------------------------------------------------------------

Tom Lane wrote:
> I wrote:
> > Michael Paesold <mpaesold@gmx.at> writes:
> >> I am definatly not going to use -march=pentium4 in any production 
> >> system. Should I open a bug report with RedHat (gcc vendor)?
> 
> > Yeah, but they'll probably want a smaller test case than "Postgres fails
> > its regression tests" :-(
> 
> I have just confirmed that the problem still exists in FC4's current
> compiler (gcc 4.0.1, gcc-4.0.1-4.fc4), which probably will boost up the
> priority of the complaint quite a long way in Red Hat's eyes.
> 
> I've also confirmed that the problem is in interval_div; you can
> reproduce the failure with
> 
>     select '41 years 1 mon 11 days'::interval / 10;
> 
> which should give '4 years 1 mon 9 days 26:24:00', but when
> timestamp.o is compiled with "-mcpu=pentium4 -march=pentium4",
> you get '4 years 1 mon 10 days 02:24:00'.  --enable-integer-datetimes
> is not relevant because the interesting part is all double/integer
> arithmetic.
> 
> Looking at this, though, I wonder if the pentium4 answer isn't "more
> correct".  If I'm doing the math by hand correctly, what we end up
> with is having to cascade 3/10ths of a month down into the days field,
> and since the conversion factor is supposed to be 30 days/month, that
> should be exactly 9 days.  Plus the one full day from the 11/10 days
> gives 10 days.  I think what is happening on all the non-Pentium
> platforms is that (3.0/10.0)*30.0 is producing something just a shade
> less than 9.0, whereas the Pentium gives 9.0 or a shade over, possibly
> due to rearrangement of the calculation.  I think we can still file this
> as a compiler bug, because I'm pretty sure the C spec does not allow
> rearrangement of floating-point calculations ... but we might want to
> think about tweaking the code's roundoff behavior just a bit.
> 
> An example that's a little easier to look at is
> 
>     select '41 years 1 mon'::interval / 10;
> 
> I get '4 years 1 mon 9 days' with the pentium4 optimization, and
> '4 years 1 mon 8 days 24:00:00' without, and the former seems more
> correct...
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
> 

--  Bruce Momjian   http://candle.pha.pa.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Chris Browne
Date:
Subject: Re: Fabian Pascal and RDBMS deficiencies in fully implementing
Next
From: Tom Lane
Date:
Subject: Increasing catcache size