Thread: regression failure - horology
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
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
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
*** ./expected/horology.out Fri Feb 21 16:28:17 2003
--- ./results/horology.out Fri Feb 21 21:54:15 2003
***************
*** 329,355 ****
(1 row)
SELECT timestamp without time zone 'Nov 24, 4714 BC' + interval '1000000000 days' AS "Nov 27, 2733194";
! Nov 27, 2733194
! -----------------------------
! Sun Nov 27 00:00:00 2733194
! (1 row)
!
SELECT timestamp without time zone 'Nov 24, 4714 BC' + interval '2000000000 days' AS "Nov 30, 5471101";
Nov 30, 5471101
! -----------------------------
! Sat Nov 30 00:00:00 5471101
(1 row)
SELECT timestamp without time zone 'Nov 25, 4714 BC' + interval '2147483492 days' AS "Dec 31, 5874897";
Dec 31, 5874897
! -----------------------------
! Tue Dec 31 00:00:00 5874897
(1 row)
SELECT timestamp without time zone '12/31/5874897' - timestamp without time zone 'Nov 24, 4714 BC' AS "2147483493
Days";
2147483493 Days
! -------------------
! @ 2147483493 days
(1 row)
-- Shorthand values
--- 329,351 ----
(1 row)
SELECT timestamp without time zone 'Nov 24, 4714 BC' + interval '1000000000 days' AS "Nov 27, 2733194";
! ERROR: Unable to format timestamp; internal coding error
SELECT timestamp without time zone 'Nov 24, 4714 BC' + interval '2000000000 days' AS "Nov 30, 5471101";
Nov 30, 5471101
! -----------------------------------
! Thu Jun 20 23:43:34.035456 210115
(1 row)
SELECT timestamp without time zone 'Nov 25, 4714 BC' + interval '2147483492 days' AS "Dec 31, 5874897";
Dec 31, 5874897
! ---------------------------------
! Mon Jul 04 15:41:44.48384 29357
(1 row)
SELECT timestamp without time zone '12/31/5874897' - timestamp without time zone 'Nov 24, 4714 BC' AS "2147483493
Days";
2147483493 Days
! ---------------------------------------------
! @ 12443669 days 15 hours 41 mins 44.48 secs
(1 row)
-- Shorthand values
======================================================================
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
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
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
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 overthe full range of values. However eight-byte integer timestamps have a reduced range of dates from 4713 BC up to294276 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
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
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 arein use. 3. Document the different ranges for timestamps depending on if integer timestamps are in use.
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, Pennsylvania19073
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; } }