Thread: 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, Pennsylvania19073
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 CVS
>
>
> 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
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
http://archives.postgresql.org
Attachment
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 CVS > > > > > > 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 > > > > ---------------------------(end of > > broadcast)--------------------------- > > TIP 4: Have you searched our list archives? > > > http://archives.postgresql.org 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 19073 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
> -----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 CVS
>
>
> 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.
>
> --------------------------------------------------------------
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 CVS > > 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 CVS > > > > > > 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. > > > > -------------------------------------------------------------- > > > -- 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 CVS > > > > 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 CVS > > > > > > > > > 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. > > > > > > -------------------------------------------------------------- > > > > > > > > -- > 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 19073
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 CVS > > 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? > 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 CVS > > > > > > 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 CVS > > > > > > > > > > > > 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. > > > > > > > > -------------------------------------------------------------- > > > > > > > > > > > > > -- > > 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 CVS > > 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 CVS > > > > > > 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 CVS > > > > > > > > > > > > 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. > > > > > > > > -------------------------------------------------------------- > > > > > > > > > > > > > -- > > 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 CVS > > > > 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 CVS > > > > > > > > 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 CVS > > > > > > > > > > > > > > > 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. > > > > > > > > > > -------------------------------------------------------------- > > > > > > > > > > > > > > > > > > -- > > > 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 19073
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 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)