regressin failure on latest CVS
Hi,
I tried the latest cvs this morning (07/22 11:00 CET)
and interval test fails.
Here's the regression.diffs.
*** ./expected/interval.out Fri Jul 22 10:32:21 2005
--- ./results/interval.out Fri Jul 22 11:07:54 2005
***************
*** 217,224 ****
-- updating pg_aggregate.agginitval
select avg(f1) from interval_tbl;
avg
! -------------------------------------------------
! @ 4 years 1 mon 10 days 4 hours 18 mins 23 secs
(1 row) -- test long interval input
--- 217,224 ----
-- updating pg_aggregate.agginitval
select avg(f1) from interval_tbl;
avg
! ------------------------------------------------
! @ 4 years 1 mon 9 days 4 hours 18 mins 23 secs
(1 row)-- test long interval input
======================================================================
Regards
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)
On Jul 22, 2005, at 6:28 PM, ohp@pyrenet.fr wrote:
I tried the latest cvs this morning (07/22 11:00 CET)
and interval test fails.
Here's the regression.diffs.
*** ./expected/interval.out Fri Jul 22 10:32:21 2005 --- ./results/interval.out Fri Jul 22 11:07:54 2005 *************** *** 217,224 **** -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ------------------------------------------------- ! @ 4 years 1 mon 10 days 4 hours 18 mins 23 secs (1 row)-- test long interval input --- 217,224 ---- -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ------------------------------------------------ ! @ 4 years 1 mon 9 days 4 hours 18 mins 23 secs (1 row)-- test long interval input
Could you provide platform information? Did you build with --enable-
integer-datetimes? Looking at the buildfarm, kookaburra (AIX 5.2) is
also failing the interval test at the same point, but the result is
different.
http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=kookaburra&br=HEAD
================== pgsql.36852/src/test/regress/regression.diffs
===================
*** ./expected/interval.out Fri Jul 22 01:25:05 2005
--- ./results/interval.out Fri Jul 22 01:34:20 2005
***************
*** 217,224 ****
-- updating pg_aggregate.agginitval
select avg(f1) from interval_tbl;
avg
! -------------------------------------------------
! @ 4 years 1 mon 10 days 4 hours 18 mins 23 secs
(1 row) -- test long interval input
--- 217,224 ----
-- updating pg_aggregate.agginitval
select avg(f1) from interval_tbl;
avg
! ----------------------------------------------------
! @ 4 years 1 mon 10 days 4 hours 18 mins 22.99 secs
(1 row)Michael Glaesemann
grzm myrealbox com
Michael Glaesemann wrote:
On Jul 22, 2005, at 6:28 PM, ohp@pyrenet.fr wrote:
I tried the latest cvs this morning (07/22 11:00 CET)
and interval test fails.
Here's the regression.diffs.*** ./expected/interval.out Fri Jul 22 10:32:21 2005 --- ./results/interval.out Fri Jul 22 11:07:54 2005 *************** *** 217,224 **** -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ------------------------------------------------- ! @ 4 years 1 mon 10 days 4 hours 18 mins 23 secs (1 row)-- test long interval input --- 217,224 ---- -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ------------------------------------------------ ! @ 4 years 1 mon 9 days 4 hours 18 mins 23 secs (1 row)-- test long interval input
Could you provide platform information? Did you build with --enable-
integer-datetimes? Looking at the buildfarm, kookaburra (AIX 5.2) is
also failing the interval test at the same point, but the result is
different.
Interesting. I don't see the error with our without
--enable-integer-datetimes. I even tried changing my timezone to Paris
time and still could not reproduce the failure.
On the AIX problem below, we are going to get rounding issues.
---------------------------------------------------------------------------
http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=kookaburra&br=HEAD
================== pgsql.36852/src/test/regress/regression.diffs =================== *** ./expected/interval.out Fri Jul 22 01:25:05 2005 --- ./results/interval.out Fri Jul 22 01:34:20 2005 *************** *** 217,224 **** -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ------------------------------------------------- ! @ 4 years 1 mon 10 days 4 hours 18 mins 23 secs (1 row)-- test long interval input --- 217,224 ---- -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ---------------------------------------------------- ! @ 4 years 1 mon 10 days 4 hours 18 mins 22.99 secs (1 row)Michael Glaesemann
grzm myrealbox com---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
This patch fixes the interval regression on my AIX box (kookaburra) by
only doing integer math on the interval, instead of float/double math.
I think this is the correct way to handle this, since it's an integer
data type.
I don't know if it will fix Olivier's problem, since I wasn't able to
reproduce it.
Thanks,
-rocco
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Bruce Momjian
Sent: Friday, July 22, 2005 10:41 AM
To: Michael Glaesemann
Cc: ohp@pyrenet.fr; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] regressin failure on latest CVSMichael Glaesemann wrote:
On Jul 22, 2005, at 6:28 PM, ohp@pyrenet.fr wrote:
I tried the latest cvs this morning (07/22 11:00 CET)
and interval test fails.
Here's the regression.diffs.*** ./expected/interval.out Fri Jul 22 10:32:21 2005 --- ./results/interval.out Fri Jul 22 11:07:54 2005 *************** *** 217,224 **** -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ------------------------------------------------- ! @ 4 years 1 mon 10 days 4 hours 18 mins 23 secs (1 row)-- test long interval input --- 217,224 ---- -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ------------------------------------------------ ! @ 4 years 1 mon 9 days 4 hours 18 mins 23 secs (1 row)-- test long interval input
Could you provide platform information? Did you build with
--enable-
integer-datetimes? Looking at the buildfarm, kookaburra
(AIX 5.2) is
also failing the interval test at the same point, but the
result is
different.
Interesting. I don't see the error with our without
--enable-integer-datetimes. I even tried changing my
timezone to Paris
time and still could not reproduce the failure.On the AIX problem below, we are going to get rounding issues.
--------------------------------------------------------------
-------------http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=kookaburra&br=HEAD
================== pgsql.36852/src/test/regress/regression.diffs =================== *** ./expected/interval.out Fri Jul 22 01:25:05 2005 --- ./results/interval.out Fri Jul 22 01:34:20 2005 *************** *** 217,224 **** -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ------------------------------------------------- ! @ 4 years 1 mon 10 days 4 hours 18 mins 23 secs (1 row)-- test long interval input --- 217,224 ---- -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ---------------------------------------------------- ! @ 4 years 1 mon 10 days 4 hours 18 mins 22.99 secs (1 row)Michael Glaesemann
grzm myrealbox com---------------------------(end of
broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.orgso that your
message can get through to the mailing list cleanly
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073---------------------------(end of
broadcast)---------------------------
TIP 4: Have you searched our list archives?
Attachments:
timestamp.patchapplication/octet-stream; name=timestamp.patchDownload
Index: timestamp.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/timestamp.c,v
retrieving revision 1.140
diff -c -r1.140 timestamp.c
*** timestamp.c 22 Jul 2005 15:15:38 -0000 1.140
--- timestamp.c 22 Jul 2005 16:14:31 -0000
***************
*** 2294,2300 ****
--- 2294,2302 ----
{
Interval *span = PG_GETARG_INTERVAL_P(0);
float8 factor = PG_GETARG_FLOAT8(1);
+ #ifndef HAVE_INT64_TIMESTAMP
double month_remainder, day_remainder;
+ #endif
Interval *result;
result = (Interval *) palloc(sizeof(Interval));
***************
*** 2308,2313 ****
--- 2310,2322 ----
result->day = span->day / factor;
result->time = span->time / factor;
+ #ifdef HAVE_INT64_TIMESTAMP
+ /* Cascade fractions to lower units */
+ /* fractional months partial days into time */
+ result->time += ((span->day - (result->day * factor)) * USECS_PER_DAY) / factor;
+ /* fractional months full days into days */
+ result->day += ((span->month - (result->month * factor)) * DAYS_PER_MONTH) / factor;
+ #else
/* Computer remainders */
month_remainder = (span->month - result->month * factor) / factor;
day_remainder = (span->day - result->day * factor) / factor;
***************
*** 2317,2326 ****
result->day += month_remainder * DAYS_PER_MONTH;
/* fractional months partial days into time */
day_remainder += (month_remainder * DAYS_PER_MONTH) - (int)(month_remainder * DAYS_PER_MONTH);
-
- #ifdef HAVE_INT64_TIMESTAMP
- result->time += day_remainder * USECS_PER_DAY;
- #else
result->time += day_remainder * SECS_PER_DAY;
result->time = JROUND(result->time);
#endif
--- 2326,2331 ----
Import Notes
Resolved by subject fallback
Rocco Altier wrote:
This patch fixes the interval regression on my AIX box (kookaburra) by
only doing integer math on the interval, instead of float/double math.I think this is the correct way to handle this, since it's an integer
data type.I don't know if it will fix Olivier's problem, since I wasn't able to
reproduce it.
I have changed the way I compute the remainder values --- instead of
using multiplication, I use division and then subtraction. This should
fix your rounding problem. Looking at your fix, I don't see how adding
USECS changes things because the factor is already a float, but I think
the problem was more the way I was computing the remainders.
Patch attached --- let me know if it does not fix your problem.
---------------------------------------------------------------------------
Thanks,
-rocco-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Bruce Momjian
Sent: Friday, July 22, 2005 10:41 AM
To: Michael Glaesemann
Cc: ohp@pyrenet.fr; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] regressin failure on latest CVSMichael Glaesemann wrote:
On Jul 22, 2005, at 6:28 PM, ohp@pyrenet.fr wrote:
I tried the latest cvs this morning (07/22 11:00 CET)
and interval test fails.
Here's the regression.diffs.*** ./expected/interval.out Fri Jul 22 10:32:21 2005 --- ./results/interval.out Fri Jul 22 11:07:54 2005 *************** *** 217,224 **** -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ------------------------------------------------- ! @ 4 years 1 mon 10 days 4 hours 18 mins 23 secs (1 row)-- test long interval input --- 217,224 ---- -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ------------------------------------------------ ! @ 4 years 1 mon 9 days 4 hours 18 mins 23 secs (1 row)-- test long interval input
Could you provide platform information? Did you build with
--enable-
integer-datetimes? Looking at the buildfarm, kookaburra
(AIX 5.2) is
also failing the interval test at the same point, but the
result is
different.
Interesting. I don't see the error with our without
--enable-integer-datetimes. I even tried changing my
timezone to Paris
time and still could not reproduce the failure.On the AIX problem below, we are going to get rounding issues.
--------------------------------------------------------------
-------------http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=kookaburra&br=HEAD
================== pgsql.36852/src/test/regress/regression.diffs =================== *** ./expected/interval.out Fri Jul 22 01:25:05 2005 --- ./results/interval.out Fri Jul 22 01:34:20 2005 *************** *** 217,224 **** -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ------------------------------------------------- ! @ 4 years 1 mon 10 days 4 hours 18 mins 23 secs (1 row)-- test long interval input --- 217,224 ---- -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ---------------------------------------------------- ! @ 4 years 1 mon 10 days 4 hours 18 mins 22.99 secs (1 row)Michael Glaesemann
grzm myrealbox com---------------------------(end of
broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.orgso that your
message can get through to the mailing list cleanly
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073---------------------------(end of
broadcast)---------------------------
TIP 4: Have you searched our list archives?
Content-Description: timestamp.patch
[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Attachments:
/bjm/difftext/plainDownload
Index: src/backend/utils/adt/timestamp.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/utils/adt/timestamp.c,v
retrieving revision 1.144
diff -c -c -r1.144 timestamp.c
*** src/backend/utils/adt/timestamp.c 23 Jul 2005 14:25:34 -0000 1.144
--- src/backend/utils/adt/timestamp.c 23 Jul 2005 14:51:05 -0000
***************
*** 2308,2316 ****
result->day = span->day / factor;
result->time = span->time / factor;
! /* Computer remainders */
! month_remainder = (span->month - result->month * factor) / factor;
! day_remainder = (span->day - result->day * factor) / factor;
/* Cascade fractions to lower units */
/* fractional months full days into days */
--- 2308,2316 ----
result->day = span->day / factor;
result->time = span->time / factor;
! /* Compute remainders */
! month_remainder = span->month / factor - result->month;
! day_remainder = span->day / factor - result->day;
/* Cascade fractions to lower units */
/* fractional months full days into days */
This still does not fix the problem.
I had done my patch to try to mimic the way 8.0 had handled the math
with the remainders, but to carry it over another bucket (day).
The problem that I see is that we are taking day_remainder and
multiplying by USECS_PER_DAY. Which is a double * int64, thus there is
the precision loss there.
I think initial division by the factor can't be helped, but repeatedly
doing more floating point math on with it is causing the rounding error.
Thanks,
-rocco
Show quoted text
-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Saturday, July 23, 2005 10:54 AM
To: Rocco Altier
Cc: Michael Glaesemann; pgsql-patches@postgresql.org;
pgsql-hackers@postgresql.org; ohp@pyrenet.fr
Subject: Re: [HACKERS] regressin failure on latest CVSRocco Altier wrote:
This patch fixes the interval regression on my AIX box
(kookaburra) by
only doing integer math on the interval, instead of
float/double math.
I think this is the correct way to handle this, since it's
an integer
data type.
I don't know if it will fix Olivier's problem, since I
wasn't able to
reproduce it.
I have changed the way I compute the remainder values --- instead of
using multiplication, I use division and then subtraction.
This should
fix your rounding problem. Looking at your fix, I don't see
how adding
USECS changes things because the factor is already a float,
but I think
the problem was more the way I was computing the remainders.Patch attached --- let me know if it does not fix your problem.
--------------------------------------------------------------
Import Notes
Resolved by subject fallback
I just checked latest CVS (5 mn ago) the problem is still the same,
BTW, this is on Unixware 714 and no --enable-integer-datetime
Regards
On Sat, 23 Jul 2005, Rocco Altier wrote:
Date: Sat, 23 Jul 2005 11:15:44 -0400
From: Rocco Altier <RoccoA@Routescape.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Michael Glaesemann <grzm@myrealbox.com>, pgsql-patches@postgresql.org,
pgsql-hackers@postgresql.org, ohp@pyrenet.fr
Subject: RE: [HACKERS] regressin failure on latest CVSThis still does not fix the problem.
I had done my patch to try to mimic the way 8.0 had handled the math
with the remainders, but to carry it over another bucket (day).The problem that I see is that we are taking day_remainder and
multiplying by USECS_PER_DAY. Which is a double * int64, thus there is
the precision loss there.I think initial division by the factor can't be helped, but repeatedly
doing more floating point math on with it is causing the rounding error.Thanks,
-rocco-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Saturday, July 23, 2005 10:54 AM
To: Rocco Altier
Cc: Michael Glaesemann; pgsql-patches@postgresql.org;
pgsql-hackers@postgresql.org; ohp@pyrenet.fr
Subject: Re: [HACKERS] regressin failure on latest CVSRocco Altier wrote:
This patch fixes the interval regression on my AIX box
(kookaburra) by
only doing integer math on the interval, instead of
float/double math.
I think this is the correct way to handle this, since it's
an integer
data type.
I don't know if it will fix Olivier's problem, since I
wasn't able to
reproduce it.
I have changed the way I compute the remainder values --- instead of
using multiplication, I use division and then subtraction.
This should
fix your rounding problem. Looking at your fix, I don't see
how adding
USECS changes things because the factor is already a float,
but I think
the problem was more the way I was computing the remainders.Patch attached --- let me know if it does not fix your problem.
--------------------------------------------------------------
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)
ohp@pyrenet.fr wrote:
I just checked latest CVS (5 mn ago) the problem is still the same,
BTW, this is on Unixware 714 and no --enable-integer-datetime
Do you have the latest patch included int that version of CVS?
Anonymous CVS has a delay, and what was the problem you were seeing, the
rounding or the day - 1 result?
---------------------------------------------------------------------------
Regards
On Sat, 23 Jul 2005, Rocco Altier wrote:Date: Sat, 23 Jul 2005 11:15:44 -0400
From: Rocco Altier <RoccoA@Routescape.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Michael Glaesemann <grzm@myrealbox.com>, pgsql-patches@postgresql.org,
pgsql-hackers@postgresql.org, ohp@pyrenet.fr
Subject: RE: [HACKERS] regressin failure on latest CVSThis still does not fix the problem.
I had done my patch to try to mimic the way 8.0 had handled the math
with the remainders, but to carry it over another bucket (day).The problem that I see is that we are taking day_remainder and
multiplying by USECS_PER_DAY. Which is a double * int64, thus there is
the precision loss there.I think initial division by the factor can't be helped, but repeatedly
doing more floating point math on with it is causing the rounding error.Thanks,
-rocco-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Saturday, July 23, 2005 10:54 AM
To: Rocco Altier
Cc: Michael Glaesemann; pgsql-patches@postgresql.org;
pgsql-hackers@postgresql.org; ohp@pyrenet.fr
Subject: Re: [HACKERS] regressin failure on latest CVSRocco Altier wrote:
This patch fixes the interval regression on my AIX box
(kookaburra) by
only doing integer math on the interval, instead of
float/double math.
I think this is the correct way to handle this, since it's
an integer
data type.
I don't know if it will fix Olivier's problem, since I
wasn't able to
reproduce it.
I have changed the way I compute the remainder values --- instead of
using multiplication, I use division and then subtraction.
This should
fix your rounding problem. Looking at your fix, I don't see
how adding
USECS changes things because the factor is already a float,
but I think
the problem was more the way I was computing the remainders.Patch attached --- let me know if it does not fix your problem.
--------------------------------------------------------------
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073On Sat, 23 Jul 2005, Bruce Momjian wrote:
Date: Sat, 23 Jul 2005 11:36:43 -0400 (EDT)
From: Bruce Momjian <pgman@candle.pha.pa.us>
To: ohp@pyrenet.fr
Cc: Rocco Altier <RoccoA@Routescape.com>,
Michael Glaesemann <grzm@myrealbox.com>, pgsql-patches@postgresql.org,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] regressin failure on latest CVSohp@pyrenet.fr wrote:
I just checked latest CVS (5 mn ago) the problem is still the same,
BTW, this is on Unixware 714 and no --enable-integer-datetimeDo you have the latest patch included int that version of CVS?
Anonymous CVS has a delay, and what was the problem you were seeing, the
rounding or the day - 1 result?
I was seeing (and still see) the day -1 result. However, if I ./configure
--with-integer-datetimes I see the rounding of the day.
---------------------------------------------------------------------------
Regards
On Sat, 23 Jul 2005, Rocco Altier wrote:Date: Sat, 23 Jul 2005 11:15:44 -0400
From: Rocco Altier <RoccoA@Routescape.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Michael Glaesemann <grzm@myrealbox.com>, pgsql-patches@postgresql.org,
pgsql-hackers@postgresql.org, ohp@pyrenet.fr
Subject: RE: [HACKERS] regressin failure on latest CVSThis still does not fix the problem.
I had done my patch to try to mimic the way 8.0 had handled the math
with the remainders, but to carry it over another bucket (day).The problem that I see is that we are taking day_remainder and
multiplying by USECS_PER_DAY. Which is a double * int64, thus there is
the precision loss there.I think initial division by the factor can't be helped, but repeatedly
doing more floating point math on with it is causing the rounding error.Thanks,
-rocco-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Saturday, July 23, 2005 10:54 AM
To: Rocco Altier
Cc: Michael Glaesemann; pgsql-patches@postgresql.org;
pgsql-hackers@postgresql.org; ohp@pyrenet.fr
Subject: Re: [HACKERS] regressin failure on latest CVSRocco Altier wrote:
This patch fixes the interval regression on my AIX box
(kookaburra) by
only doing integer math on the interval, instead of
float/double math.
I think this is the correct way to handle this, since it's
an integer
data type.
I don't know if it will fix Olivier's problem, since I
wasn't able to
reproduce it.
I have changed the way I compute the remainder values --- instead of
using multiplication, I use division and then subtraction.
This should
fix your rounding problem. Looking at your fix, I don't see
how adding
USECS changes things because the factor is already a float,
but I think
the problem was more the way I was computing the remainders.Patch attached --- let me know if it does not fix your problem.
--------------------------------------------------------------
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)
I think the patch is ok now, intervall is not failing anymore as of
18:50 CET.
However stats fails.
regression.diffs:
*** ./expected/stats.out Sat Jul 23 17:18:20 2005
--- ./results/stats.out Sat Jul 23 18:55:17 2005
***************
*** 53,59 ****
WHERE st.relname='tenk2' AND cl.relname='tenk2';
?column? | ?column? | ?column? | ?column?
----------+----------+----------+----------
! t | t | t | t
(1 row) SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages,
--- 53,59 ----
WHERE st.relname='tenk2' AND cl.relname='tenk2';
?column? | ?column? | ?column? | ?column?
----------+----------+----------+----------
! f | f | t | t
(1 row) SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages,
***************
*** 62,68 ****
WHERE st.relname='tenk2' AND cl.relname='tenk2';
?column? | ?column?
----------+----------
! t | t
(1 row)
-- End of Stats Test
--- 62,68 ----
WHERE st.relname='tenk2' AND cl.relname='tenk2';
?column? | ?column?
----------+----------
! f | t
(1 row)-- End of Stats Test
======================================================================
On Sat, 23 Jul 2005, Bruce Momjian wrote:
Date: Sat, 23 Jul 2005 11:36:43 -0400 (EDT)
From: Bruce Momjian <pgman@candle.pha.pa.us>
To: ohp@pyrenet.fr
Cc: Rocco Altier <RoccoA@Routescape.com>,
Michael Glaesemann <grzm@myrealbox.com>, pgsql-patches@postgresql.org,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] regressin failure on latest CVSohp@pyrenet.fr wrote:
I just checked latest CVS (5 mn ago) the problem is still the same,
BTW, this is on Unixware 714 and no --enable-integer-datetimeDo you have the latest patch included int that version of CVS?
Anonymous CVS has a delay, and what was the problem you were seeing, the
rounding or the day - 1 result?---------------------------------------------------------------------------
Regards
On Sat, 23 Jul 2005, Rocco Altier wrote:Date: Sat, 23 Jul 2005 11:15:44 -0400
From: Rocco Altier <RoccoA@Routescape.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Michael Glaesemann <grzm@myrealbox.com>, pgsql-patches@postgresql.org,
pgsql-hackers@postgresql.org, ohp@pyrenet.fr
Subject: RE: [HACKERS] regressin failure on latest CVSThis still does not fix the problem.
I had done my patch to try to mimic the way 8.0 had handled the math
with the remainders, but to carry it over another bucket (day).The problem that I see is that we are taking day_remainder and
multiplying by USECS_PER_DAY. Which is a double * int64, thus there is
the precision loss there.I think initial division by the factor can't be helped, but repeatedly
doing more floating point math on with it is causing the rounding error.Thanks,
-rocco-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Saturday, July 23, 2005 10:54 AM
To: Rocco Altier
Cc: Michael Glaesemann; pgsql-patches@postgresql.org;
pgsql-hackers@postgresql.org; ohp@pyrenet.fr
Subject: Re: [HACKERS] regressin failure on latest CVSRocco Altier wrote:
This patch fixes the interval regression on my AIX box
(kookaburra) by
only doing integer math on the interval, instead of
float/double math.
I think this is the correct way to handle this, since it's
an integer
data type.
I don't know if it will fix Olivier's problem, since I
wasn't able to
reproduce it.
I have changed the way I compute the remainder values --- instead of
using multiplication, I use division and then subtraction.
This should
fix your rounding problem. Looking at your fix, I don't see
how adding
USECS changes things because the factor is already a float,
but I think
the problem was more the way I was computing the remainders.Patch attached --- let me know if it does not fix your problem.
--------------------------------------------------------------
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)
Yes, we have seen those stat tests fail randomly. We are working on a
solution.
---------------------------------------------------------------------------
ohp@pyrenet.fr wrote:
I think the patch is ok now, intervall is not failing anymore as of
18:50 CET.However stats fails.
regression.diffs:*** ./expected/stats.out Sat Jul 23 17:18:20 2005 --- ./results/stats.out Sat Jul 23 18:55:17 2005 *************** *** 53,59 **** WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? | ?column? | ?column? ----------+----------+----------+---------- ! t | t | t | t (1 row)SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages, --- 53,59 ---- WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? | ?column? | ?column? ----------+----------+----------+---------- ! f | f | t | t (1 row)SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages,
***************
*** 62,68 ****
WHERE st.relname='tenk2' AND cl.relname='tenk2';
?column? | ?column?
----------+----------
! t | t
(1 row)-- End of Stats Test --- 62,68 ---- WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? ----------+---------- ! f | t (1 row)-- End of Stats Test
======================================================================
On Sat, 23 Jul 2005, Bruce Momjian wrote:
Date: Sat, 23 Jul 2005 11:36:43 -0400 (EDT)
From: Bruce Momjian <pgman@candle.pha.pa.us>
To: ohp@pyrenet.fr
Cc: Rocco Altier <RoccoA@Routescape.com>,
Michael Glaesemann <grzm@myrealbox.com>, pgsql-patches@postgresql.org,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] regressin failure on latest CVSohp@pyrenet.fr wrote:
I just checked latest CVS (5 mn ago) the problem is still the same,
BTW, this is on Unixware 714 and no --enable-integer-datetimeDo you have the latest patch included int that version of CVS?
Anonymous CVS has a delay, and what was the problem you were seeing, the
rounding or the day - 1 result?---------------------------------------------------------------------------
Regards
On Sat, 23 Jul 2005, Rocco Altier wrote:Date: Sat, 23 Jul 2005 11:15:44 -0400
From: Rocco Altier <RoccoA@Routescape.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Michael Glaesemann <grzm@myrealbox.com>, pgsql-patches@postgresql.org,
pgsql-hackers@postgresql.org, ohp@pyrenet.fr
Subject: RE: [HACKERS] regressin failure on latest CVSThis still does not fix the problem.
I had done my patch to try to mimic the way 8.0 had handled the math
with the remainders, but to carry it over another bucket (day).The problem that I see is that we are taking day_remainder and
multiplying by USECS_PER_DAY. Which is a double * int64, thus there is
the precision loss there.I think initial division by the factor can't be helped, but repeatedly
doing more floating point math on with it is causing the rounding error.Thanks,
-rocco-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Saturday, July 23, 2005 10:54 AM
To: Rocco Altier
Cc: Michael Glaesemann; pgsql-patches@postgresql.org;
pgsql-hackers@postgresql.org; ohp@pyrenet.fr
Subject: Re: [HACKERS] regressin failure on latest CVSRocco Altier wrote:
This patch fixes the interval regression on my AIX box
(kookaburra) by
only doing integer math on the interval, instead of
float/double math.
I think this is the correct way to handle this, since it's
an integer
data type.
I don't know if it will fix Olivier's problem, since I
wasn't able to
reproduce it.
I have changed the way I compute the remainder values --- instead of
using multiplication, I use division and then subtraction.
This should
fix your rounding problem. Looking at your fix, I don't see
how adding
USECS changes things because the factor is already a float,
but I think
the problem was more the way I was computing the remainders.Patch attached --- let me know if it does not fix your problem.
--------------------------------------------------------------
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Would you please try the attached patch and let me know if it fixes the
problem? I avoided accumulating into a float8.
---------------------------------------------------------------------------
Rocco Altier wrote:
This still does not fix the problem.
I had done my patch to try to mimic the way 8.0 had handled the math
with the remainders, but to carry it over another bucket (day).The problem that I see is that we are taking day_remainder and
multiplying by USECS_PER_DAY. Which is a double * int64, thus there is
the precision loss there.I think initial division by the factor can't be helped, but repeatedly
doing more floating point math on with it is causing the rounding error.Thanks,
-rocco-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Saturday, July 23, 2005 10:54 AM
To: Rocco Altier
Cc: Michael Glaesemann; pgsql-patches@postgresql.org;
pgsql-hackers@postgresql.org; ohp@pyrenet.fr
Subject: Re: [HACKERS] regressin failure on latest CVSRocco Altier wrote:
This patch fixes the interval regression on my AIX box
(kookaburra) by
only doing integer math on the interval, instead of
float/double math.
I think this is the correct way to handle this, since it's
an integer
data type.
I don't know if it will fix Olivier's problem, since I
wasn't able to
reproduce it.
I have changed the way I compute the remainder values --- instead of
using multiplication, I use division and then subtraction.
This should
fix your rounding problem. Looking at your fix, I don't see
how adding
USECS changes things because the factor is already a float,
but I think
the problem was more the way I was computing the remainders.Patch attached --- let me know if it does not fix your problem.
--------------------------------------------------------------
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Attachments:
/pgpatches/intervaltext/plainDownload
Index: src/backend/utils/adt/timestamp.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/utils/adt/timestamp.c,v
retrieving revision 1.145
diff -c -c -r1.145 timestamp.c
*** src/backend/utils/adt/timestamp.c 23 Jul 2005 14:53:21 -0000 1.145
--- src/backend/utils/adt/timestamp.c 23 Jul 2005 18:45:56 -0000
***************
*** 2309,2327 ****
result->time = span->time / factor;
/* Compute remainders */
! month_remainder = span->month / factor - result->month;
! day_remainder = span->day / factor - result->day;
/* Cascade fractions to lower units */
/* fractional months full days into days */
result->day += month_remainder * DAYS_PER_MONTH;
- /* fractional months partial days into time */
- day_remainder += (month_remainder * DAYS_PER_MONTH) - (int)(month_remainder * DAYS_PER_MONTH);
#ifdef HAVE_INT64_TIMESTAMP
! result->time += day_remainder * USECS_PER_DAY;
#else
! result->time += day_remainder * SECS_PER_DAY;
result->time = JROUND(result->time);
#endif
--- 2309,2328 ----
result->time = span->time / factor;
/* Compute remainders */
! month_remainder = (span->month / factor - result->month);
! day_remainder = (span->day / factor - result->day);
/* Cascade fractions to lower units */
/* fractional months full days into days */
result->day += month_remainder * DAYS_PER_MONTH;
+ /* fractional months partial days into time */
#ifdef HAVE_INT64_TIMESTAMP
! result->time += (day_remainder + month_remainder * DAYS_PER_MONTH -
! (int)(month_remainder * DAYS_PER_MONTH)) * USECS_PER_DAY;
#else
! result->time += (day_remainder + month_remainder * DAYS_PER_MONTH -
! (int)(month_remainder * DAYS_PER_MONTH)) * SECS_PER_DAY;
result->time = JROUND(result->time);
#endif
Sorry to follow up my own post but this is weird.
I've tested again and more closely.
And intervall check is ok when configured with --enable-debug and fails
(with the same error) otherwise.
It could be a compiler optimizer bug or the way the code is written.
Could someone point me to the source file so that I have a look?
BTW this is still on UnixWare 714
Regards,
On Fri, 22 Jul 2005 ohp@pyrenet.fr wrote:
Date: Fri, 22 Jul 2005 11:28:52 +0200 (MET DST)
From: ohp@pyrenet.fr
Newsgroups: pgsql.hackers
Subject: regressin failure on latest CVSHi,
I tried the latest cvs this morning (07/22 11:00 CET)
and interval test fails.
Here's the regression.diffs.*** ./expected/interval.out Fri Jul 22 10:32:21 2005 --- ./results/interval.out Fri Jul 22 11:07:54 2005 *************** *** 217,224 **** -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ------------------------------------------------- ! @ 4 years 1 mon 10 days 4 hours 18 mins 23 secs (1 row)-- test long interval input --- 217,224 ---- -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ------------------------------------------------ ! @ 4 years 1 mon 9 days 4 hours 18 mins 23 secs (1 row)-- test long interval input
======================================================================
Regards
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)
On Jul 25 2005, ohp@pyrenet.fr wrote:
Sorry to follow up my own post but this is weird.
I've tested again and more closely.
And intervall check is ok when configured with --enable-debug and fails
(with the same error) otherwise.It could be a compiler optimizer bug or the way the code is written.
Could someone point me to the source file so that I have a look?
Look at 'firefly' on the pgbuildfarm, and tell me what I need
to change to duplicate your setup.
LER
BTW this is still on UnixWare 714
Regards,
On Fri, 22 Jul 2005 ohp@pyrenet.fr wrote:Date: Fri, 22 Jul 2005 11:28:52 +0200 (MET DST)
From: ohp@pyrenet.fr
Newsgroups: pgsql.hackers
Subject: regressin failure on latest CVSHi,
I tried the latest cvs this morning (07/22 11:00 CET)
and interval test fails.
Here's the regression.diffs.*** ./expected/interval.out Fri Jul 22 10:32:21 2005 --- ./results/interval.out Fri Jul 22 11:07:54 2005 *************** *** 217,224 **** -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ------------------------------------------------- ! @ 4 years 1 mon 10 days 4 hours 18 mins 23 secs (1 row)-- test long interval input --- 217,224 ---- -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ------------------------------------------------ ! @ 4 years 1 mon 9 days 4 hours 18 mins 23 secs (1 row)-- test long interval input
======================================================================
Regards
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611
Import Notes
Resolved by subject fallback
Hi Larry,
I'm quitge sure you'll see a problem if you remove --enable-debug
--enable-cassert from your ./configure
This is the problem I have.
Regards
On Mon, 25 Jul 2005, Larry Rosenman wrote:
Date: 25 Jul 2005 09:00:41 -0500
From: Larry Rosenman <ler@lerctr.org>
To: ohp@pyrenet.fr
Cc: pgsql-hackers list <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] regression failure on latest CVSOn Jul 25 2005, ohp@pyrenet.fr wrote:
Sorry to follow up my own post but this is weird.
I've tested again and more closely.
And intervall check is ok when configured with --enable-debug and fails
(with the same error) otherwise.It could be a compiler optimizer bug or the way the code is written.
Could someone point me to the source file so that I have a look?Look at 'firefly' on the pgbuildfarm, and tell me what I need
to change to duplicate your setup.LER
BTW this is still on UnixWare 714
Regards,
On Fri, 22 Jul 2005 ohp@pyrenet.fr wrote:Date: Fri, 22 Jul 2005 11:28:52 +0200 (MET DST)
From: ohp@pyrenet.fr
Newsgroups: pgsql.hackers
Subject: regressin failure on latest CVSHi,
I tried the latest cvs this morning (07/22 11:00 CET)
and interval test fails.
Here's the regression.diffs.*** ./expected/interval.out Fri Jul 22 10:32:21 2005 --- ./results/interval.out Fri Jul 22 11:07:54 2005 *************** *** 217,224 **** -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ------------------------------------------------- ! @ 4 years 1 mon 10 days 4 hours 18 mins 23 secs (1 row)-- test long interval input --- 217,224 ---- -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ------------------------------------------------ ! @ 4 years 1 mon 9 days 4 hours 18 mins 23 secs (1 row)-- test long interval input
======================================================================
Regards
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)
On Jul 25 2005, ohp@pyrenet.fr wrote:
Hi Larry,
I'm quitge sure you'll see a problem if you remove --enable-debug
--enable-cassert from your ./configure
Do we have a clue as to which .c module the compiler/optimizer is (possibly)
screwing up?
I have connections in SCO's compiler group....
(They'll want a small test case :( )
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611
Import Notes
Resolved by subject fallback
On Mon, 25 Jul 2005, Larry Rosenman wrote:
Date: 25 Jul 2005 12:47:01 -0500
From: Larry Rosenman <ler@lerctr.org>
To: ohp@pyrenet.fr
Cc: pgsql-hackers list <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] regression failure on latest CVSOn Jul 25 2005, ohp@pyrenet.fr wrote:
Hi Larry,
I'm quitge sure you'll see a problem if you remove --enable-debug
--enable-cassert from your ./configureDo we have a clue as to which .c module the compiler/optimizer is (possibly)
screwing up?
According to Bruce, it's in timestamp.c
Did you get the same problem?
I have connections in SCO's compiler group....
(They'll want a small test case :( )
LER
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)
On Jul 25 2005, ohp@pyrenet.fr wrote:
On Mon, 25 Jul 2005, Larry Rosenman wrote:
Date: 25 Jul 2005 12:47:01 -0500
From: Larry Rosenman <ler@lerctr.org>
To: ohp@pyrenet.fr
Cc: pgsql-hackers list <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] regression failure on latest CVSOn Jul 25 2005, ohp@pyrenet.fr wrote:
Hi Larry,
I'm quitge sure you'll see a problem if you remove --enable-debug
--enable-cassert from your ./configureDo we have a clue as to which .c module the compiler/optimizer is
(possibly) screwing up?According to Bruce, it's in timestamp.c
Did you get the same problem?
Haven't tried (I can't get to my box from here, easily), but I did
give a heads up to my contacts at SCO.
Will try tonight.
LER
I have connections in SCO's compiler group....
(They'll want a small test case :( )
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611
Import Notes
Resolved by subject fallback
Would it be useful to hackers if build animals periodically ran builds
with those options removed?
On Mon, Jul 25, 2005 at 07:19:05PM +0200, ohp@pyrenet.fr wrote:
Hi Larry,
I'm quitge sure you'll see a problem if you remove --enable-debug
--enable-cassert from your ./configureThis is the problem I have.
Regards
On Mon, 25 Jul 2005, Larry Rosenman wrote:Date: 25 Jul 2005 09:00:41 -0500
From: Larry Rosenman <ler@lerctr.org>
To: ohp@pyrenet.fr
Cc: pgsql-hackers list <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] regression failure on latest CVSOn Jul 25 2005, ohp@pyrenet.fr wrote:
Sorry to follow up my own post but this is weird.
I've tested again and more closely.
And intervall check is ok when configured with --enable-debug and fails
(with the same error) otherwise.It could be a compiler optimizer bug or the way the code is written.
Could someone point me to the source file so that I have a look?Look at 'firefly' on the pgbuildfarm, and tell me what I need
to change to duplicate your setup.LER
BTW this is still on UnixWare 714
Regards,
On Fri, 22 Jul 2005 ohp@pyrenet.fr wrote:Date: Fri, 22 Jul 2005 11:28:52 +0200 (MET DST)
From: ohp@pyrenet.fr
Newsgroups: pgsql.hackers
Subject: regressin failure on latest CVSHi,
I tried the latest cvs this morning (07/22 11:00 CET)
and interval test fails.
Here's the regression.diffs.*** ./expected/interval.out Fri Jul 22 10:32:21 2005 --- ./results/interval.out Fri Jul 22 11:07:54 2005 *************** *** 217,224 **** -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ------------------------------------------------- ! @ 4 years 1 mon 10 days 4 hours 18 mins 23 secs (1 row)-- test long interval input --- 217,224 ---- -- updating pg_aggregate.agginitval select avg(f1) from interval_tbl; avg ! ------------------------------------------------ ! @ 4 years 1 mon 9 days 4 hours 18 mins 23 secs (1 row)-- test long interval input
======================================================================
Regards
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
ohp@pyrenet.fr wrote:
On Mon, 25 Jul 2005, Larry Rosenman wrote:
Date: 25 Jul 2005 12:47:01 -0500
From: Larry Rosenman <ler@lerctr.org>
To: ohp@pyrenet.fr
Cc: pgsql-hackers list <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] regression failure on latest CVSOn Jul 25 2005, ohp@pyrenet.fr wrote:
Hi Larry,
I'm quitge sure you'll see a problem if you remove --enable-debug
--enable-cassert from your ./configure
For those following along at home:
Removing --enable-cassert and --enable-debug from the options causes
Firefly to fail.
I'm forcing a run with --enable-cassert only, to see what happens (per
request from SCO).
I've saved off the first failure to send to SCO.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US
Larry Rosenman wrote:
ohp@pyrenet.fr wrote:
On Mon, 25 Jul 2005, Larry Rosenman wrote:
Date: 25 Jul 2005 12:47:01 -0500
From: Larry Rosenman <ler@lerctr.org>
To: ohp@pyrenet.fr
Cc: pgsql-hackers list <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] regression failure on latest CVSOn Jul 25 2005, ohp@pyrenet.fr wrote:
Hi Larry,
I'm quitge sure you'll see a problem if you remove --enable-debug
--enable-cassert from your ./configureFor those following along at home:
Removing --enable-cassert and --enable-debug from the options causes
Firefly to fail.I'm forcing a run with --enable-cassert only, to see what happens
(per request from SCO).I've saved off the first failure to send to SCO.
Just --enable-cassert fails as well. SCO also asked if 8.0-STABLE also has
issues. Running
That test now.
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US
Larry Rosenman wrote:
ohp@pyrenet.fr wrote:
On Mon, 25 Jul 2005, Larry Rosenman wrote:
Date: 25 Jul 2005 12:47:01 -0500
From: Larry Rosenman <ler@lerctr.org>
To: ohp@pyrenet.fr
Cc: pgsql-hackers list <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] regression failure on latest CVSOn Jul 25 2005, ohp@pyrenet.fr wrote:
Hi Larry,
I'm quitge sure you'll see a problem if you remove --enable-debug
--enable-cassert from your ./configureFor those following along at home:
Removing --enable-cassert and --enable-debug from the options causes
Firefly to fail.I'm forcing a run with --enable-cassert only, to see what happens (per
request from SCO).I've saved off the first failure to send to SCO.
I assume that in the SCO compiler turning debugging on turns
optimisation off? If so, that would at least make some kind of sense
(i.e. this would a case of bad optimisation).
cheers
andrew
Andrew Dunstan wrote:
Larry Rosenman wrote:
ohp@pyrenet.fr wrote:
On Mon, 25 Jul 2005, Larry Rosenman wrote:
Date: 25 Jul 2005 12:47:01 -0500
From: Larry Rosenman <ler@lerctr.org>
To: ohp@pyrenet.fr
Cc: pgsql-hackers list <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] regression failure on latest CVSOn Jul 25 2005, ohp@pyrenet.fr wrote:
Hi Larry,
I'm quitge sure you'll see a problem if you remove --enable-debug
--enable-cassert from your ./configureFor those following along at home:
Removing --enable-cassert and --enable-debug from the options causes
Firefly to fail.I'm forcing a run with --enable-cassert only, to see what happens
(per request from SCO).I've saved off the first failure to send to SCO.
I assume that in the SCO compiler turning debugging on turns
optimisation off? If so, that would at least make some kind of sense
(i.e. this would a case of bad optimisation).cheers
andrew
Yes, -g disables -O. And REL8_0_STABLE passes without --enable-cassert and
--enable-debug set.
So, off the stuff goes to my contacts @SCO.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US
"Larry Rosenman" <ler@lerctr.org> writes:
For those following along at home:
Removing --enable-cassert and --enable-debug from the options causes
Firefly to fail.
FWIW, I just checked that CVS tip works OK for me without these options,
with either integer or float timestamps. I don't see any new warnings,
either. It could well be that the recent changes have introduced some
portability problem in the interval code, but someone's going to have to
actually dig for it :-(
regards, tom lane
Tom Lane wrote:
"Larry Rosenman" <ler@lerctr.org> writes:
For those following along at home:
Removing --enable-cassert and --enable-debug from the options causes
Firefly to fail.FWIW, I just checked that CVS tip works OK for me without these
options, with either integer or float timestamps. I don't see any
new warnings, either. It could well be that the recent changes have
introduced some portability problem in the interval code, but
someone's going to have to actually dig for it :-(regards, tom lane
Thanks, Tom. I've reported my findings to the compiler
Guys at SCO. We'll see what they say tomorrow.
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US
On Mon, 25 Jul 2005, Tom Lane wrote:
Date: Mon, 25 Jul 2005 23:26:20 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Larry Rosenman <ler@lerctr.org>
Cc: ohp@pyrenet.fr, 'pgsql-hackers list' <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] regression failure on latest CVS"Larry Rosenman" <ler@lerctr.org> writes:
For those following along at home:
Removing --enable-cassert and --enable-debug from the options causes
Firefly to fail.FWIW, I just checked that CVS tip works OK for me without these options,
with either integer or float timestamps. I don't see any new warnings,
either.
It could well be that the recent changes have introduced some
portability problem in the interval code, but someone's going to have to
actually dig for it :-(
That's my feeling but I have no clue where to start.
I know this was introduced at the end of last week.
regards, tom lane
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)
On Jul 26 2005, ohp@pyrenet.fr wrote:
On Mon, 25 Jul 2005, Tom Lane wrote:
FWIW, I just checked that CVS tip works OK for me without these options,
with either integer or float timestamps. I don't see any new warnings,
either.
It could well be that the recent changes have introduced some
portability problem in the interval code, but someone's going to have to
actually dig for it :-(That's my feeling but I have no clue where to start.
I know this was introduced at the end of last week.
I'm confident the SCO Compiler guys will get to the bottom of it :)
They've got all the info they need, as far as I know, as well as
access to my box.
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611
Import Notes
Resolved by subject fallback
In the meantime would'nt it be nice to try to understand what happens and
correct it?
I'm a bit afraid that 8.1 is not used on unixware because people don't
have/want the patch installed.
Regards
On Tue, 26 Jul 2005, Larry Rosenman wrote:
Date: 26 Jul 2005 08:52:01 -0500
From: Larry Rosenman <ler@lerctr.org>
To: ohp@pyrenet.fr
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
'pgsql-hackers list' <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] regression failure on latest CVSOn Jul 26 2005, ohp@pyrenet.fr wrote:
On Mon, 25 Jul 2005, Tom Lane wrote:
FWIW, I just checked that CVS tip works OK for me without these options,
with either integer or float timestamps. I don't see any new warnings,
either.
It could well be that the recent changes have introduced some
portability problem in the interval code, but someone's going to have to
actually dig for it :-(That's my feeling but I have no clue where to start.
I know this was introduced at the end of last week.I'm confident the SCO Compiler guys will get to the bottom of it :)
They've got all the info they need, as far as I know, as well as
access to my box.LER
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)
ohp@pyrenet.fr wrote:
In the meantime would'nt it be nice to try to understand what happens
and correct it?I'm a bit afraid that 8.1 is not used on unixware because people
don't have/want the patch installed.Regards
Let's see what they find, first. They may have a work-around (they don't
yet, but...).
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US
ohp@pyrenet.fr wrote:
In the meantime would'nt it be nice to try to understand what happens and
correct it?I'm a bit afraid that 8.1 is not used on unixware because people don't
have/want the patch installed.
All the evidence is that this is a compiler bug. The apparent workaround
for now would be to compile with optimisation turned off. Or use another
compiler - gcc is available isn't it?
cheers
andrew
On Jul 27 2005, Andrew Dunstan wrote:
ohp@pyrenet.fr wrote:
In the meantime would'nt it be nice to try to understand what happens and
correct it?I'm a bit afraid that 8.1 is not used on unixware because people don't
have/want the patch installed.All the evidence is that this is a compiler bug. The apparent workaround
for now would be to compile with optimisation turned off. Or use another
compiler - gcc is available isn't it?
Yes. Lets see what the SCO guys come up with. gcc is available as well.
(ancient version, but that's another story).
The SCO guys have, in the past, found other ways to fix the code as well, so
let's give them a few days.
I do know they are working it (I'm getting questions back and forth about
getting their systems up to snuf to compile it :) )
LER
cheers
andrew
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611
Import Notes
Resolved by subject fallback
Andrew Dunstan wrote:
ohp@pyrenet.fr wrote:
In the meantime would'nt it be nice to try to understand what happens and
correct it?I'm a bit afraid that 8.1 is not used on unixware because people don't
have/want the patch installed.All the evidence is that this is a compiler bug. The apparent workaround
for now would be to compile with optimisation turned off. Or use another
compiler - gcc is available isn't it?
The SCO compiler was a buggy mess with any optimization turned on 10
years ago, and it still is. I see no reason our community should waste
time helping fix such a buggy compiler. If it was buggy for the past 10
years, I think it will be buggy for the next 10 too. We should just
turn off optimization for that compiler.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073On Jul 27 2005, Bruce Momjian wrote:
Andrew Dunstan wrote:
ohp@pyrenet.fr wrote:
In the meantime would'nt it be nice to try to understand what happens
and correct it?I'm a bit afraid that 8.1 is not used on unixware because people don't
have/want the patch installed.All the evidence is that this is a compiler bug. The apparent
workaround for now would be to compile with optimisation turned off. Or
use another compiler - gcc is available isn't it?The SCO compiler was a buggy mess with any optimization turned on 10
years ago, and it still is. I see no reason our community should waste
time helping fix such a buggy compiler. If it was buggy for the past 10
years, I think it will be buggy for the next 10 too. We should just
turn off optimization for that compiler.
No we shouldn't. I'm actually working with the SCO compiler guys to get
this BUG fixed.
Let's not pre-judge.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611
Import Notes
Resolved by subject fallback