I'm seeing a regression failure on the horology test on two different 
machines. I'd venture a guess that it is related to this change:

   http://archives.postgresql.org/pgsql-committers/2003-02/msg00166.php

Joe


Fri, 21 Feb 2003 20:43:09 -0800
Joe Conway <mail@joeconway.com>
regression failure - horology
Joe Conway <mail@joeconway.com> writes:
> I'm seeing a regression failure on the horology test on two different 
> machines.

Uh ... what machines, and what failure exactly?

			regards, tom lane

Sat, 22 Feb 2003 02:06:33 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: regression failure - horology 
Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
>>I'm seeing a regression failure on the horology test on two different 
>>machines.
> 
> Uh ... what machines, and what failure exactly?
> 

Sorry -- one is Red Hat 8.0/Intel P3 and one is Red Hat 7.3/AMD Athlon. 
Regression diff attached.

Joe
Fri, 21 Feb 2003 23:37:05 -0800
Joe Conway <mail@joeconway.com>
Re: regression failure - horology
Joe Conway <mail@joeconway.com> writes:
> Sorry -- one is Red Hat 8.0/Intel P3 and one is Red Hat 7.3/AMD Athlon. 

Hm, I just had regression tests pass earlier this evening on RHL 8.0
(also HPUX 10.20).  Are you using default config, or
--enable-integer-datetimes?

			regards, tom lane

Sat, 22 Feb 2003 02:45:06 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: regression failure - horology 
Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
> 
>>Sorry -- one is Red Hat 8.0/Intel P3 and one is Red Hat 7.3/AMD Athlon. 
> 
> Hm, I just had regression tests pass earlier this evening on RHL 8.0
> (also HPUX 10.20).  Are you using default config, or
> --enable-integer-datetimes?
> 

I'm using --enable-integer-datetimes on both.

Joe


Fri, 21 Feb 2003 23:48:26 -0800
Joe Conway <mail@joeconway.com>
Re: regression failure - horology
Joe Conway <mail@joeconway.com> writes:
> Tom Lane wrote:
>> Hm, I just had regression tests pass earlier this evening on RHL 8.0
>> (also HPUX 10.20).  Are you using default config, or
>> --enable-integer-datetimes?

> I'm using --enable-integer-datetimes on both.

Mph.  It fails for me too when I use --enable-integer-datetimes.  Looks
like that patch still needs some work...

			regards, tom lane

Sat, 22 Feb 2003 03:09:13 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: regression failure - horology 
Joe Conway <mail@joeconway.com> writes:
> I'm seeing a regression failure on the horology test on two different 
> machines. I'd venture a guess that it is related to this change:
>    http://archives.postgresql.org/pgsql-committers/2003-02/msg00166.php

It seems to be a problem with signed vs unsigned 8-byte integer
timestamps.  Now that I look at it, the patch actually advertises this:

     When timestamps are stored as eight-byte integers (a compile-time
     option), microsecond precision is available over the full range of
     values. However eight-byte integer timestamps have a reduced range
     of dates from 4713 BC up to 294276 AD.

which seems to make it rather foolish to include horology tests for
dates past 294276 AD.

John, you need to rethink this.  Regression tests that fail with
--enable-integer-datetimes will not do.  Is it even a good idea to claim
a range of dates up to 5874897 AD?  The 8-byte-int representation is
probably the wave of the future.  As such, anything it can't do is
not something we want to commit to supporting.

			regards, tom lane

Sat, 22 Feb 2003 03:40:21 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: regression failure - horology 
On Sat, Feb 22, 2003 at 03:09:13AM -0500, Tom Lane wrote:
> 
> Mph.  It fails for me too when I use --enable-integer-datetimes.  Looks
> like that patch still needs some work...

Yeah.  I'm really, really, *really* sorry for submitting it in the state
it was in.  I shouldn't have done that just before moving to another
country.  I found the problem last night, but couldn't get to a Net
connection until now.

The problem is in src/bin/psql/common.c, around line 250-335 somewhere
depending on the version.  The 2nd and 3rd clauses of the "while" loop
condition:

	(rstatus == PGRES_COPY_IN) &&
	(rstatus == PGRES_COPY_OUT))

should of course be:

	(rstatus != PGRES_COPY_IN) &&
	(rstatus != PGRES_COPY_OUT))


Jeroen


Sat, 22 Feb 2003 16:34:11 +0100
"Jeroen T. Vermeulen" <jtv@xs4all.nl>
Re: regression failure - horology
In article <12354.1045901353@sss.pgh.pa.us>,
Tom Lane <tgl@sss.pgh.pa.us> wrote:
>Joe Conway <mail@joeconway.com> writes:
>> Tom Lane wrote:
>>> Hm, I just had regression tests pass earlier this evening on RHL 8.0
>>> (also HPUX 10.20).  Are you using default config, or
>>> --enable-integer-datetimes?
>
>> I'm using --enable-integer-datetimes on both.
>

It looks like the regression checks need to use two different formats
depending on if integer-timestamps is being used.

For the normal floating point timestamps, the regression checks are correct
since all timestamps between 4713BC to 5874897AD.

However using a 64 bit integer to represented as number of microseconds since
Jan 1, 2000 gives the following reduced range of 4713BC to about 294277AD.
In order to represent to full range of timestamps for julian day counts from 0
to 2147483647 to the nearest microsecond, you require:
   31 bits for the day
   17 bits for the second
   20 bits for the microsecond
for a total of 68 bits needed to represent the full range of timestamps to
the nearest microsecond.

Suggested fix would be one or more of the following:
   1. Reduce the range tested within the regression checks to what is
      capable for integer timestamps.
   2. Use two different regression checks depending on if integer timestamps
      are in use.
   3. Document the different ranges for timestamps depending on if integer
      timestamps are in use.

Mon, 24 Feb 2003 06:23:52 +0000 (UTC)
jdc@smof.fiawol.org (John Cochran)
Re: regression failure - horology

Your patch has been added to the PostgreSQL unapplied patches list at:

	http://momjian.postgresql.org/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------


Jeroen T. Vermeulen wrote:
> On Sat, Feb 22, 2003 at 03:09:13AM -0500, Tom Lane wrote:
> > 
> > Mph.  It fails for me too when I use --enable-integer-datetimes.  Looks
> > like that patch still needs some work...
> 
> Yeah.  I'm really, really, *really* sorry for submitting it in the state
> it was in.  I shouldn't have done that just before moving to another
> country.  I found the problem last night, but couldn't get to a Net
> connection until now.
> 
> The problem is in src/bin/psql/common.c, around line 250-335 somewhere
> depending on the version.  The 2nd and 3rd clauses of the "while" loop
> condition:
> 
> 	(rstatus == PGRES_COPY_IN) &&
> 	(rstatus == PGRES_COPY_OUT))
> 
> should of course be:
> 
> 	(rstatus != PGRES_COPY_IN) &&
> 	(rstatus != PGRES_COPY_OUT))
> 
> 
> Jeroen
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: 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

Mon, 17 Mar 2003 12:23:37 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: regression failure - horology
Patch attached and applied.  Thanks.

---------------------------------------------------------------------------

Jeroen T. Vermeulen wrote:
> On Sat, Feb 22, 2003 at 03:09:13AM -0500, Tom Lane wrote:
> > 
> > Mph.  It fails for me too when I use --enable-integer-datetimes.  Looks
> > like that patch still needs some work...
> 
> Yeah.  I'm really, really, *really* sorry for submitting it in the state
> it was in.  I shouldn't have done that just before moving to another
> country.  I found the problem last night, but couldn't get to a Net
> connection until now.
> 
> The problem is in src/bin/psql/common.c, around line 250-335 somewhere
> depending on the version.  The 2nd and 3rd clauses of the "while" loop
> condition:
> 
> 	(rstatus == PGRES_COPY_IN) &&
> 	(rstatus == PGRES_COPY_OUT))
> 
> should of course be:
> 
> 	(rstatus != PGRES_COPY_IN) &&
> 	(rstatus != PGRES_COPY_OUT))
> 
> 
> Jeroen
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: 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

Index: src/bin/psql/common.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/bin/psql/common.c,v
retrieving revision 1.57
diff -c -c -r1.57 common.c
*** src/bin/psql/common.c	18 Mar 2003 22:15:44 -0000	1.57
--- src/bin/psql/common.c	20 Mar 2003 04:44:04 -0000
***************
*** 252,259 ****
  			}
  			PQclear(res);
  			res = newres;
! 			if (rstatus == PGRES_COPY_IN ||
! 				rstatus == PGRES_COPY_OUT)
  				break;
  		}
  	}
--- 252,259 ----
  			}
  			PQclear(res);
  			res = newres;
! 			if (rstatus != PGRES_COPY_IN &&
! 				rstatus != PGRES_COPY_OUT)
  				break;
  		}
  	}
Wed, 19 Mar 2003 23:45:12 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: regression failure - horology