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+9-4
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+6-6
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 19073Sorry 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
