Re: Interval aggregate regression failure (expected seems
От | Tom Lane |
---|---|
Тема | Re: Interval aggregate regression failure (expected seems |
Дата | |
Msg-id | 20170.1131383247@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Interval aggregate regression failure (expected seems (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Interval aggregate regression failure (expected seems
Re: Interval aggregate regression failure (expected seems Re: Interval aggregate regression failure (expected seems Re: Interval aggregate regression failure (expected seems |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: