On Aug 11, 2006, at 13:48 , Bruce Momjian wrote:
Have we made any progress on this?
I made a bit of progress but am still having issues when --enable-
integer-datetimes is not enabled. I need to spend some time with gdb
and figure out what's going on. I probably won't be able to get time
Have we made any progress on this?
---
Tom Lane wrote:
> Michael Glaesemann <[EMAIL PROTECTED]> writes:
> > ... I think this just confirms that there is some kind of rounding (or
> > lack of) in interval_div. Kind of frust
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> ... I think this just confirms that there is some kind of rounding (or
> lack of) in interval_div. Kind of frustrating that it's not visible
> in the result.
I think the fundamental problem is that the float8 results of division
are inaccurate,
On Jun 23, 2006, at 9:47 , Michael Glaesemann wrote:
# select '41 mon'::interval / 10;
?column?
4 mons 2 days 24:00:00
My understanding is that as month_remainder is a float (as is
month_remainder_days), month_remainder_days may be equal to 24
hours after r
On Jun 23, 2006, at 9:47 , Michael Glaesemann wrote:
It also changes the result of the aggregate test for intervals, but
I think that's to be expected.
My goodness. Of course it changes the aggregate test results. That
was what brought this up in the first place. (*kicks self for not
rea
Tom Lane wrote:
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 ge
I assume no more progress has been made on this?
---
Tom Lane wrote:
> I wrote:
> > Michael Paesold <[EMAIL PROTECTED]> writes:
> >> I am definatly not going to use -march=pentium4 in any production
> >> system. Should I op
Tom Lane wrote:
> Michael Paesold <[EMAIL PROTECTED]> writes:
> > Would you mind reporting this to RedHat Bugzilla? I believe a bug report
> > from you would have more weight then mine, because you actually
> > understand what's going on here. :-)
>
> Actually, given the thought that this may be
Michael Paesold <[EMAIL PROTECTED]> writes:
> Would you mind reporting this to RedHat Bugzilla? I believe a bug report
> from you would have more weight then mine, because you actually
> understand what's going on here. :-)
Actually, given the thought that this may be an artifact of keeping an
i
Tom Lane wrote:
I wrote:
Michael Paesold <[EMAIL PROTECTED]> 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
Gregory Maxwell wrote:
On 07 Nov 2005 14:22:37 -0500, Greg Stark <[EMAIL PROTECTED]> wrote:
IIRC, floating point registers are actually longer than a double so if the
entire calculation is done in registers and then the result rounded off to
store in memory it may get the right answer. Whereas
On 07 Nov 2005 14:22:37 -0500, Greg Stark <[EMAIL PROTECTED]> wrote:
> IIRC, floating point registers are actually longer than a double so if the
> entire calculation is done in registers and then the result rounded off to
> store in memory it may get the right answer. Whereas if it loses the extra
c.f.:
`-ffloat-store'
Do not store floating point variables in registers, and inhibit
other options that might change whether a floating point value is
taken from a register or memory.
This option prevents undesirable excess precision on machines such
as the 68000 where
Tom Lane <[EMAIL PROTECTED]> writes:
> 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 ...
It may have more to do with whether the floating point value can stay in a
floating point register long en
I wrote:
> Michael Paesold <[EMAIL PROTECTED]> 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 hav
Michael Paesold <[EMAIL PROTECTED]> writes:
> I have tested these combination of CFLAGS:
> -O2 OK
> -O2 -mcpu=i686 -march=i686 OK (good, RPMS are built with these)
> -O2 -mcpu=pentium4 -march=i686 OK
> -O2 -mcpu=pentium4 -march=pentium4 fails
> I am d
Michael Glaesemann wrote:
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?
select avg(f1) from interval_tbl;
avg
-
@ 4 years 1 mon 9 days 28 hours 18 mins 2
On Nov 7, 2005, at 18:28 , Michael Paesold wrote:
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
Heh. I forgot, too ;) My test was also
Michael Paesold 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? Th
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?
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 b
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
22 matches
Mail list logo
