Re: [HACKERS] Test of PG7.3.2b2 on SGI Irix
Dear Tom, All the regression tests pass except for tests involving Savings Time which are off by one hour. --Bob Details? If you ran it today then the DST-boundary problems shouldn't be there anymore. Here are the diffs: It looks like your files match the solaris-1947 variants; would you confirm that? If so, please send a patch with a resultmap addition that matches your platform. There is already an entry horology/.*-irix6=horology-no-DST-before-1970 but it looks like that's not triggering on your system. It's not the same as the solaris-1947 variants. I compared all three horology files in the expected directory -- none match. There is no such irix6 file in the distribution. Please let me know what else you'd like me to do WRT to this diff. --Bob +-++ | Robert E. Bruccoleri, Ph.D. | email: [EMAIL PROTECTED]| | P.O. Box 314| URL: http://www.congen.com/~bruc | | Pennington, NJ 08534|| +-++ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Test of PG7.3.2b2 on SGI Irix
I've built and run the regression tests on PostgreSQL7.3 beta 2 on SGI Irix and found the following suspicious compiler error message: gmake[4]: Entering directory `/pg/postgresql-7.3b2/src/backend/utils/hash' cc -64 -g -woff 1164,1171,1185,1195,1552 -I../../../../src/include -I/stf/sys64/include -I/stf/sys64/include/readline -U_NO_XOPEN4 -c dynahash.c -o dynahash.o cc-1184 cc: WARNING File = dynahash.c, Line = 543 = is used where where == may have been intended. Assert(currBucket !(saveState.currBucket = NULL)); ^ Looks like a bug to me. All the regression tests pass except for tests involving Savings Time which are off by one hour. --Bob +-++ | Robert E. Bruccoleri, Ph.D. | email: [EMAIL PROTECTED]| | P.O. Box 314| URL: http://www.congen.com/~bruc | | Pennington, NJ 08534|| +-++ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Test of PG7.3.2b2 on SGI Irix
Robert E. Bruccoleri [EMAIL PROTECTED] writes: gmake[4]: Entering directory `/pg/postgresql-7.3b2/src/backend/utils/hash' cc -64 -g -woff 1164,1171,1185,1195,1552 -I../../../../src/include -I/stf/sys64/include -I/stf/sys64/include/readline -U_NO_XOPEN4 -c dynahash.c -o dynahash.o cc-1184 cc: WARNING File = dynahash.c, Line = 543 = is used where where == may have been intended. Assert(currBucket !(saveState.currBucket = NULL)); ^ Looks like a bug to me. No, the code is correct, although no doubt too clever by half :-( All the regression tests pass except for tests involving Savings Time which are off by one hour. --Bob Details? If you ran it today then the DST-boundary problems shouldn't be there anymore. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Test of PG7.3.2b2 on SGI Irix
Dear Tom, Robert E. Bruccoleri [EMAIL PROTECTED] writes: gmake[4]: Entering directory `/pg/postgresql-7.3b2/src/backend/utils/hash' cc -64 -g -woff 1164,1171,1185,1195,1552 -I../../../../src/include -I/stf/sys64/include -I/stf/sys64/include/readline -U_NO_XOPEN4 -c dynahash.c -o dynahash.o cc-1184 cc: WARNING File = dynahash.c, Line = 543 = is used where where == may have been intended. Assert(currBucket !(saveState.currBucket = NULL)); ^ Looks like a bug to me. No, the code is correct, although no doubt too clever by half :-( How can it be correct? If the assertion checking is turned off, then saveState.currBucket will not be changed, but if assertion checking is on, it will be set to NULL. The only way that it would make no difference would be if the saveState.currBucket were NULL to begin with, but then, why make the assignment? All the regression tests pass except for tests involving Savings Time which are off by one hour. --Bob Details? If you ran it today then the DST-boundary problems shouldn't be there anymore. Here are the diffs: *** abstime.out Thu Oct 31 13:18:04 2002 --- ../expected/abstime.out Wed Nov 21 13:27:25 2001 *** *** 44,50 | Wed Dec 31 16:00:00 1969 PST | infinity | -infinity !| Sat May 10 22:59:12 1947 PST | invalid (7 rows) --- 44,50 | Wed Dec 31 16:00:00 1969 PST | infinity | -infinity !| Sat May 10 23:59:12 1947 PST | invalid (7 rows) *** *** 56,62 | Mon May 01 00:30:30 1995 PDT | Wed Dec 31 16:00:00 1969 PST | -infinity ! | Sat May 10 22:59:12 1947 PST (5 rows) SELECT '' AS six, ABSTIME_TBL.* --- 56,62 | Mon May 01 00:30:30 1995 PDT | Wed Dec 31 16:00:00 1969 PST | -infinity ! | Sat May 10 23:59:12 1947 PST (5 rows) SELECT '' AS six, ABSTIME_TBL.* *** *** 67,73 | Mon May 01 00:30:30 1995 PDT | Wed Dec 31 16:00:00 1969 PST | infinity ! | Sat May 10 22:59:12 1947 PST | invalid (6 rows) --- 67,73 | Mon May 01 00:30:30 1995 PDT | Wed Dec 31 16:00:00 1969 PST | infinity ! | Sat May 10 23:59:12 1947 PST | invalid (6 rows) *** *** 89,95 ---+-- | Wed Dec 31 16:00:00 1969 PST | -infinity !| Sat May 10 22:59:12 1947 PST (3 rows) SELECT '' AS four, ABSTIME_TBL.* --- 89,95 ---+-- | Wed Dec 31 16:00:00 1969 PST | -infinity !| Sat May 10 23:59:12 1947 PST (3 rows) SELECT '' AS four, ABSTIME_TBL.* *** *** 99,105 | Sun Jan 14 03:14:21 1973 PST | Wed Dec 31 16:00:00 1969 PST | -infinity ! | Sat May 10 22:59:12 1947 PST (4 rows) SELECT '' AS four, ABSTIME_TBL.* --- 99,105 | Sun Jan 14 03:14:21 1973 PST | Wed Dec 31 16:00:00 1969 PST | -infinity ! | Sat May 10 23:59:12 1947 PST (4 rows) SELECT '' AS four, ABSTIME_TBL.* *** *** 121,127 ORDER BY abstime; four | abstime| year | month | day | hour | minute | second --+--+--+---+-+--++ ! | Sat May 10 22:59:12 1947 PST | 1947 | 5 | 10 | 22 | 59 | 12 | Wed Dec 31 16:00:00 1969 PST | 1969 |12 | 31 | 16 | 0 | 0 | Sun Jan 14 03:14:21 1973 PST | 1973 | 1 | 14 |3 | 14 | 21 | Mon May 01 00:30:30 1995 PDT | 1995 | 5 | 1 |0 | 30 | 30 --- 121,127 ORDER BY abstime; four | abstime| year | month | day | hour | minute | second --+--+--+---+-+--++ ! | Sat May 10 23:59:12 1947 PST | 1947 | 5 | 10 | 23 | 59 | 12 | Wed Dec 31 16:00:00 1969 PST | 1969 |12 | 31 | 16 | 0 | 0 | Sun Jan 14 03:14:21 1973 PST | 1973 | 1 | 14 |3 | 14 | 21 | Mon May 01 00:30:30 1995 PDT | 1995 | 5 | 1 |0 | 30 | 30 *** horology.outThu Oct 31 13:18:19 2002 --- ../expected/horology.outWed Sep 18 17:35:25 2002 *** *** 1741,1750 | Wed Mar 15 13:14:02 2000 PST | @ 34 years| Tue Mar 15 13:14:02 1966 PST | Sun Dec 31 17:32:01 2000 PST | @ 34 years| Sat Dec 31 17:32:01 1966 PST | Mon Jan 01 17:32:01 2001 PST | @ 34 years| Sun Jan 01 17:32:01 1967 PST ! | Sat Sep 22 18:19:20 2001 PDT | @ 34 years| Fri Sep 22 17:19:20 1967 PST ! | Thu Jan 01 00:00:00 1970 PST | @ 5 mons 12 hours | Thu Jul 31 11:00:00 1969 PST ! | Thu Jan 01
Re: [HACKERS] Test of PG7.3.2b2 on SGI Irix
Robert E. Bruccoleri [EMAIL PROTECTED] writes: No, the code is correct, although no doubt too clever by half :-( How can it be correct? If the assertion checking is turned off, then saveState.currBucket will not be changed, but if assertion checking is on, it will be set to NULL. The only way that it would make no difference would be if the saveState.currBucket were NULL to begin with, but then, why make the assignment? If assertion checking is off (and the code is otherwise correct) then there's no need to reset saveState.currBucket to NULL, or so at least I interpret the author's intent. Notice that an == test would be completely redundant with the first part of the Assert, since the local currBucket was just assigned from saveState.currBucket. What is really being accomplished here is equivalent to Assert(currBucket); #ifdef USE_ASSERT_CHECKING saveState.currBucket = NULL; #endif However, it's a tad silly to confuse readers this much in order to save one lousy store instruction, so I'm inclined to change it to Assert(currBucket); saveState.currBucket = NULL; IIRC, you're not the first to look at that code and think it's wrong. All the regression tests pass except for tests involving Savings Time which are off by one hour. --Bob Details? If you ran it today then the DST-boundary problems shouldn't be there anymore. Here are the diffs: It looks like your files match the solaris-1947 variants; would you confirm that? If so, please send a patch with a resultmap addition that matches your platform. There is already an entry horology/.*-irix6=horology-no-DST-before-1970 but it looks like that's not triggering on your system. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
