Re: Interval aggregate regression failure (expected seems

Michael Glaesemann wrote:
>
> On Nov 7, 2005, at 17:24 , Michael Paesold wrote:
>
>> Using both PostgreSQL 8.1.0 and CVS current of Nov 7, 9:00 am CET I
>> get a regression failure in the interval tests. I am no export for
>> the interval type, but the expected "9 days 28 hours" seem wrong,
>> don't they? The actual value seems to be the same.
>>
>> Is it possible that this is broken on the platform where the expected
>> results were generated?
>
> What platform are you testing on? With or without integer-datetimes?

Ok, forgot. This is *without* integer-datetimes, RHEL 3 (Linux 2.4.21,
glibc 2.3.2, gcc 3.2.3 20030502) on i686 (Xeon without x86-64).

> I just ran make check on for PostgreSQL 8.1.0 on Mac OS X 10.4.3
[snip]
> I didn't have any regression failures. I'd also expect we'd see a lot
> more failures on the build farm if it were the case that it was broken
> just on the platform that the expected results were generated on. From
> a quick look at the current build farm failures on HEAD and
> REL8_1_STABLE, it doesn't look like any of the failures are failing here.

I just started to wonder about buildfarm, too, but found that most build
farm members have --enable-integer-datetimes. Could that be an
explanation? Is it possible that the code is wrong with
--enable-integer-datetimes?

So what do you have in results/interval.out?
@ 4 years 1 mon 9 days 28 hours 18 mins 23 secs seems wrong to me, no?

Tom wrote for that commit:
revision 1.14
date: 2005/10/25 17:13:07; author: tgl; state: Exp; lines: +1 -1
Remove justify_hours call from interval_mul and interval_div, and make
some small stylistic improvements in these functions. Also fix several
places where TMODULO() was being used with wrong-sized quotient argument,
creating a risk of overflow --- interval2tm was actually capable of going
into an infinite loop because of this.

Perhaps it is an intended behavior? If so, it still fails without
integer-datetimes.

Best Regards,
Michael Paesold