Re: [HACKERS] 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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] regression failure - horology
In article [EMAIL PROTECTED], Tom Lane [EMAIL PROTECTED] wrote: Joe Conway [EMAIL PROTECTED] 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. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] regression failure - horology
Joe Conway [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] regression failure - horology
Tom Lane wrote: Joe Conway [EMAIL PROTECTED] 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 '10 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 '20 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 '10 days' AS Nov 27, 2733194; ! ERROR: Unable to format timestamp; internal coding error SELECT timestamp without time zone 'Nov 24, 4714 BC' + interval '20 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 == ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] regression failure - horology
Joe Conway [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] regression failure - horology
Tom Lane wrote: Joe Conway [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] regression failure - horology
Joe Conway [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] regression failure - horology
Joe Conway [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
