Re: [HACKERS] ecpg test suite
We changed some things that should remove most of the differences you had. Two other diffs looked like you had an older version of ecpglib running. Could that be? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] ecpg test suite
Michael Meskes [EMAIL PROTECTED] writes: We changed some things that should remove most of the differences you had. Two other diffs looked like you had an older version of ecpglib running. Could that be? Bingo --- I had been doing make clean, make all, make check. It seems this is managing to invoke the installed version of ecpglib not the just-built version, probably because of the rpath switches we use on HPUX. With make install before make check, I get a clean pass with this morning's CVS tip (using gcc ... will try HP's cc in a bit). You really oughta support make installcheck anyway; aside from being less vulnerable to this issue, it's a lot less overhead to run. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] ecpg test suite
I wrote: With make install before make check, I get a clean pass with this morning's CVS tip (using gcc ... will try HP's cc in a bit). Further results: * The vulnerability to using a previously installed ecpglib exists in our default Linux configuration as well as HPUX. * Still fails with HP's cc on HPUX: *** expected/sql-desc.stdoutThu Aug 3 09:24:58 2006 --- results//sql-desc.stdoutTue Aug 8 09:03:35 2006 *** *** 1,4 output = 1 ! val1=1 (ind1: 0) val2='one' (ind2: 0) val1=2 val2=null val1=2 val2=null --- 1,4 output = 1 ! val1=654311425 (ind1: 0) val2='one' (ind2: 0) val1=2 val2=null val1=2 val2=null * Still fails with gcc on x86_64: *** expected/pgtypeslib-num_test2.stdoutMon Aug 7 09:17:02 2006 --- results//pgtypeslib-num_test2.stdoutTue Aug 8 08:51:06 2006 *** *** 53,59 (no errno set) - num[4,3]: 592490.0 (no errno set) - num[4,4]: 592490.00 (no errno set) - num[4,5]: 0.00 ! (errno == PGTYPES_NUM_OVERFLOW) - num[4,6]: 0 (r: -1) (errno == PGTYPES_NUM_OVERFLOW) - num[4,8]: 0 (r: -1) (errno == PGTYPES_NUM_OVERFLOW) - num[4,10]: 592490.000 (r: 0) (no errno set) - num[4,11]: 592490.00 (cmp: 0) --- 53,60 (no errno set) - num[4,3]: 592490.0 (no errno set) - num[4,4]: 592490.00 (no errno set) - num[4,5]: 0.00 ! (no errno set) - num[4,6]: 592490 (r: 0) ! (no errno set) - num[4,7]: 592490.00 (cmp: 0) (errno == PGTYPES_NUM_OVERFLOW) - num[4,8]: 0 (r: -1) (errno == PGTYPES_NUM_OVERFLOW) - num[4,10]: 592490.000 (r: 0) (no errno set) - num[4,11]: 592490.00 (cmp: 0) *** expected/sql-dynalloc.stderrTue Aug 8 08:43:33 2006 --- results//sql-dynalloc.stderrTue Aug 8 08:51:06 2006 *** *** 34,75 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 3 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGstore_result: line 43: allocating 21 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_data line 43: RESULT: varchar offset: -1 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_data line 43: RESULT: offset: -1 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 4 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGstore_result: line 44: allocating 16 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_data line 44: RESULT: v offset: -1 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_data line 44: RESULT: v offset: -1 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 5 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGstore_result: line 45: allocating 22 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_data line 45: RESULT: coffset: -1 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_data line 45: RESULT: coffset: -1 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 6 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGstore_result: line 46: allocating 70 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_data line 46: RESULT: Mon Mar 03 11:33:07 2003 PST offset: -1 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_data line 46: RESULT: Mon Mar 03 11:33:07 2003 PST offset: -1 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 7 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGstore_result: line 47: allocating 16 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_data line 47: RESULT: t offset: -1 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_data line 47: RESULT: f offset: -1 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 9 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGstore_result: line 50: allocating 46 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_data line 50: RESULT: 2001:4f8:3:ba:2e0:81ff:fe22:d1f1 offset: -1 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_data line 50: RESULT: offset: -1 array: Yes --- 34,75 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 3 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGstore_result: line 43: allocating 33 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_data line 43: RESULT: varchar offset: -1 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_data line 43: RESULT: offset: -1 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc:
Re: [HACKERS] ecpg test suite
On Tue, Aug 08, 2006 at 09:09:17AM -0400, Tom Lane wrote: * The vulnerability to using a previously installed ecpglib exists in our default Linux configuration as well as HPUX. On my linux box the libs get built with -rpath as well and I think that there's no portable way to remove it once it is in. Doesn't the backend regression test (using psql) suffer from the same problem with libpq? Joachim -- Joachim Wieland [EMAIL PROTECTED] GPG key available ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] ecpg test suite
On 8/2/06, Michael Meskes [EMAIL PROTECTED] wrote: I'm in the process of committing the first version of the ecpg regression test suite to CVS. This is not exactly finished work, but it shows OK on all test on my machine and on Joachim's machine. The tests need to be tweaked some before it's finished, but I'd like to hear about what others are seeing soon enough to be able to fix bugs before 8.2. Just run make check in src/interfaces/ecpg and tell us if there is some test that fails. just fyi: did a cvs update around 12pm est today and am getting a make error: make[4]: Entering directory `/usr/src/pgsql/src/interfaces/ecpg/test' sed -e 's,@bindir@,/usr/local/pgsql/bin,g' \ -e 's,@libdir@,/usr/local/pgsql/lib,g' \ -e 's,@pkglibdir@,/usr/local/pgsql/lib,g' \ -e 's,@datadir@,/usr/local/pgsql/share,g' \ -e 's/@VERSION@/8.2devel/g' \ -e 's/@host_tuple@/i686-pc-linux-gnu/g' \ -e 's,@GMAKE@,make,g' \ -e 's/@enable_shared@/yes/g' \ -e 's/@GCC@/yes/g' \ pg_regress.inc.sh.in pg_regress.inc.sh make -C connect all make: *** connect: No such file or directory. Stop. make: Entering an unknown directorymake: Leaving an unknown directorymake[4]: *** [all] Error 2 make[4]: Leaving directory `/usr/src/pgsql/src/interfaces/ecpg/test' make[3]: *** [all] Error 2 make[3]: Leaving directory `/usr/src/pgsql/src/interfaces/ecpg' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/src/pgsql/src/interfaces' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/src/pgsql/src' make: *** [all] Error 2 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ecpg test suite
Merlin, On Tue, Aug 08, 2006 at 12:32:05PM -0400, Merlin Moncure wrote: just fyi: did a cvs update around 12pm est today and am getting a make error: make -C connect all make: *** connect: No such file or directory. Stop. make: Entering an unknown directorymake: Leaving an unknown directorymake[4]: *** [all] Error 2 You don't have ecpg/test/connect/ ? http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/connect/ Joachim -- Joachim Wieland [EMAIL PROTECTED] GPG key available ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] ecpg test suite
On 8/8/06, Joachim Wieland [EMAIL PROTECTED] wrote: Merlin, On Tue, Aug 08, 2006 at 12:32:05PM -0400, Merlin Moncure wrote: just fyi: did a cvs update around 12pm est today and am getting a make error: make -C connect all make: *** connect: No such file or directory. Stop. make: Entering an unknown directorymake: Leaving an unknown directorymake[4]: *** [all] Error 2 You don't have ecpg/test/connect/ ? my fault...needed to to cvs update -d regards, merlin ---(end of broadcast)--- TIP 1: 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] ecpg test suite
On Fri, Aug 04, 2006 at 12:59:35PM -0400, Tom Lane wrote: *** expected/complex-test4.stdout Wed Aug 2 10:14:02 2006 --- results//complex-test4.stdout Fri Aug 4 12:56:13 2006 *** *** 1,4 ! Found f=14,07 text=0123456789 b=1 Found a[0] = 9 Found a[1] = 8 Found a[2] = 7 --- 1,4 ! Found f=14.07 text=0123456789 b=1 Found a[0] = 9 Found a[1] = 8 Found a[2] = 7 Locale problem. Fixed by setting locale to C. *** expected/pgtypeslib-dt_test.stderrThu Aug 3 09:24:58 2006 --- results//pgtypeslib-dt_test.stderrFri Aug 4 12:56:14 2006 *** *** 22,28 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_data line 37: RESULT: 2000-07-12 17:34:29 offset: 8 array: Yes [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGget_data line 37: RESULT: 13556 days 12:34:00 offset: 12 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGtrans line 354 action = rollback connection = regress1 [NO_PID]: sqlca: code: 0, state: 0 --- 22,28 Some types have different internal sizes on different systems. I wonder what we do with these difference as a log file usually prints this info which is important for debugging sometimes. *** expected/pgtypeslib-dt_test.stdoutWed Aug 2 10:14:03 2006 --- results//pgtypeslib-dt_test.stdoutFri Aug 4 12:56:14 2006 *** *** 41,47 18 October %34 17:28:44 CEST 80, abc%n %C %B %%%d %H:%M:%S %Z %y) = 1880-10-31 15:28:44, error (should be error!): 1 timestamp_defmt_asc(abc 18 October %34 17:28:44 CEST 80, ) = 1880-10-31 15:28:44, error (should be error!): 1 ! timestamp_defmt_asc(1980-04-12 3:49:44 , (null)) = 1980-04-12 03:49:44, error: 0 timestamp_defmt_asc(July 14, 1988. Time: 9:15am, %B %d, %Y. Time: %I:%M%p) = 1988-07-14 09:15:00, error: 0 timestamp_defmt_asc(September 6 at 01:30 pm in the year 1983, %B %d at %I:%M %p in the year %Y) = 1983-09-06 13:30:00, error: 0 timestamp_defmt_asc( 1976, July 14. Time: 9:15am, %Y, %B %d. Time: %I:%M %p) = 1976-07-14 09:15:00, error: 0 --- 41,47 18 October %34 17:28:44 CEST 80, abc%n %C %B %%%d %H:%M:%S %Z %y) = 1880-10-31 15:28:44, error (should be error!): 1 timestamp_defmt_asc(abc 18 October %34 17:28:44 CEST 80, ) = 1880-10-31 15:28:44, error (should be error!): 1 ! timestamp_defmt_asc(1980-04-12 3:49:44 , ) = 1980-04-12 03:49:44, error: 0 timestamp_defmt_asc(July 14, 1988. Time: 9:15am, %B %d, %Y. Time: %I:%M%p) = 1988-07-14 09:15:00, error: 0 timestamp_defmt_asc(September 6 at 01:30 pm in the year 1983, %B %d at %I:%M %p in the year %Y) = 1983-09-06 13:30:00, error: 0 timestamp_defmt_asc( 1976, July 14. Time: 9:15am, %Y, %B %d. Time: %I:%M %p) = 1976-07-14 09:15:00, error: 0 Different compiler gets different output for NULL value. Fixed. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] ecpg test suite
Michael Meskes [EMAIL PROTECTED] writes: Some types have different internal sizes on different systems. I wonder what we do with these difference as a log file usually prints this info which is important for debugging sometimes. If there's only a small number of possibilities, you could fix it by treating these as if they were locale differences --- that is, provide multiple expected files test.out, test_1.out, etc. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] ecpg test suite
On Sat, Aug 05, 2006 at 01:14:25PM -0400, Tom Lane wrote: If there's only a small number of possibilities, you could fix it by treating these as if they were locale differences --- that is, provide multiple expected files test.out, test_1.out, etc. Frankly I have no idea. I was thinking about removing this bit of information from the log if it is a regression test run because it doesn't bring us more information in terms of regresseion testing. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] ecpg test suite
On Thu, Aug 03, 2006 at 02:56:15PM -0400, Rocco Altier wrote: BTW, I do have --enable-integer-datetimes configured for this machine, which might explain the timestamp differences. Yes, that might be the reason. What effect does it have if you run the backend regression suite? The remaining problems are: - out of memory in complex/test4: This needs some debugging on an AIX machine. Is it possible for me to get access to your machine? Or else could you build with debugging enabled on C level and trace down the function where the out of memory occurs? - different value in sql/desc: This is strange as the stderr output seems to be the same. This could be a memory problem too. - sql/dyntest2 with a different output: Strange again as the log output seems to be identical. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] ecpg test suite
Here's the ecpg regression test diffs as of CVS tip on an HPUX box. regards, tom lane *** expected/complex-test4.stdout Wed Aug 2 10:14:02 2006 --- results//complex-test4.stdout Fri Aug 4 10:12:19 2006 *** *** 1,4 ! Found f=14,07 text=0123456789 b=1 Found a[0] = 9 Found a[1] = 8 Found a[2] = 7 --- 1,4 ! Found f=14.07 text=0123456789 b=1 Found a[0] = 9 Found a[1] = 8 Found a[2] = 7 *** expected/pgtypeslib-dt_test.stderr Thu Aug 3 09:24:58 2006 --- results//pgtypeslib-dt_test.stderr Fri Aug 4 10:12:20 2006 *** *** 22,28 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_data line 37: RESULT: 2000-07-12 17:34:29 offset: 8 array: Yes [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGget_data line 37: RESULT: 13556 days 12:34:00 offset: 12 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGtrans line 354 action = rollback connection = regress1 [NO_PID]: sqlca: code: 0, state: 0 --- 22,28 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_data line 37: RESULT: 2000-07-12 17:34:29 offset: 8 array: Yes [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGget_data line 37: RESULT: 13556 days 12:34:00 offset: 16 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGtrans line 354 action = rollback connection = regress1 [NO_PID]: sqlca: code: 0, state: 0 *** expected/pgtypeslib-dt_test.stdout Wed Aug 2 10:14:03 2006 --- results//pgtypeslib-dt_test.stdout Fri Aug 4 10:12:20 2006 *** *** 41,47 18 October %34 17:28:44 CEST 80, abc%n %C %B %%%d %H:%M:%S %Z %y) = 1880-10-31 15:28:44, error (should be error!): 1 timestamp_defmt_asc(abc 18 October %34 17:28:44 CEST 80, ) = 1880-10-31 15:28:44, error (should be error!): 1 ! timestamp_defmt_asc(1980-04-12 3:49:44 , (null)) = 1980-04-12 03:49:44, error: 0 timestamp_defmt_asc(July 14, 1988. Time: 9:15am, %B %d, %Y. Time: %I:%M%p) = 1988-07-14 09:15:00, error: 0 timestamp_defmt_asc(September 6 at 01:30 pm in the year 1983, %B %d at %I:%M %p in the year %Y) = 1983-09-06 13:30:00, error: 0 timestamp_defmt_asc( 1976, July 14. Time: 9:15am, %Y, %B %d. Time: %I:%M %p) = 1976-07-14 09:15:00, error: 0 --- 41,47 18 October %34 17:28:44 CEST 80, abc%n %C %B %%%d %H:%M:%S %Z %y) = 1880-10-31 15:28:44, error (should be error!): 1 timestamp_defmt_asc(abc 18 October %34 17:28:44 CEST 80, ) = 1880-10-31 15:28:44, error (should be error!): 1 ! timestamp_defmt_asc(1980-04-12 3:49:44 , ) = 1980-04-12 03:49:44, error: 0 timestamp_defmt_asc(July 14, 1988. Time: 9:15am, %B %d, %Y. Time: %I:%M%p) = 1988-07-14 09:15:00, error: 0 timestamp_defmt_asc(September 6 at 01:30 pm in the year 1983, %B %d at %I:%M %p in the year %Y) = 1983-09-06 13:30:00, error: 0 timestamp_defmt_asc( 1976, July 14. Time: 9:15am, %Y, %B %d. Time: %I:%M %p) = 1976-07-14 09:15:00, error: 0 *** expected/sql-dyntest2.stderrFri Aug 4 08:50:50 2006 --- results//sql-dyntest2.stderrFri Aug 4 10:12:23 2006 *** *** 58,64 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 2 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGget_data line 127: RESULT: 10297 offset: 1024 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 3 [NO_PID]: sqlca: code: 0, state: 0 --- 58,64 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 2 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGget_data line 127: RESULT: 10300 offset: 1024 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 3 [NO_PID]: sqlca: code: 0, state: 0 *** *** 198,204 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 2 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGget_data line 127: RESULT: 10300 offset: 1024 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 3 [NO_PID]: sqlca: code: 0, state: 0 --- 198,204 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 2 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGget_data line 127: RESULT: 10303 offset: 1024 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 3 [NO_PID]: sqlca: code: 0, state: 0 *** expected/sql-dyntest2.stdoutFri Aug 4 08:50:50 2006 --- results//sql-dyntest2.stdoutFri Aug 4 10:12:23 2006 *** *** 4,10 = _RETURN 2ev_class (type: -26 length: -5 precision: -1 scale: 65531 octet_length: 4 returned_octet_length: 5) ! = 10297 3ev_attr (type: 5 length: -5 precision: -1 scale: 65531 octet_length: 2
Re: [HACKERS] ecpg test suite
BTW, I tried building with HP's cc instead of gcc, and got slightly different regression failures (same HPUX/HPPA machine): *** expected/complex-test4.stdout Wed Aug 2 10:14:02 2006 --- results//complex-test4.stdout Fri Aug 4 12:56:13 2006 *** *** 1,4 ! Found f=14,07 text=0123456789 b=1 Found a[0] = 9 Found a[1] = 8 Found a[2] = 7 --- 1,4 ! Found f=14.07 text=0123456789 b=1 Found a[0] = 9 Found a[1] = 8 Found a[2] = 7 *** expected/pgtypeslib-dt_test.stderr Thu Aug 3 09:24:58 2006 --- results//pgtypeslib-dt_test.stderr Fri Aug 4 12:56:14 2006 *** *** 22,28 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_data line 37: RESULT: 2000-07-12 17:34:29 offset: 8 array: Yes [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGget_data line 37: RESULT: 13556 days 12:34:00 offset: 12 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGtrans line 354 action = rollback connection = regress1 [NO_PID]: sqlca: code: 0, state: 0 --- 22,28 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_data line 37: RESULT: 2000-07-12 17:34:29 offset: 8 array: Yes [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGget_data line 37: RESULT: 13556 days 12:34:00 offset: 16 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGtrans line 354 action = rollback connection = regress1 [NO_PID]: sqlca: code: 0, state: 0 *** expected/pgtypeslib-dt_test.stdout Wed Aug 2 10:14:03 2006 --- results//pgtypeslib-dt_test.stdout Fri Aug 4 12:56:14 2006 *** *** 41,47 18 October %34 17:28:44 CEST 80, abc%n %C %B %%%d %H:%M:%S %Z %y) = 1880-10-31 15:28:44, error (should be error!): 1 timestamp_defmt_asc(abc 18 October %34 17:28:44 CEST 80, ) = 1880-10-31 15:28:44, error (should be error!): 1 ! timestamp_defmt_asc(1980-04-12 3:49:44 , (null)) = 1980-04-12 03:49:44, error: 0 timestamp_defmt_asc(July 14, 1988. Time: 9:15am, %B %d, %Y. Time: %I:%M%p) = 1988-07-14 09:15:00, error: 0 timestamp_defmt_asc(September 6 at 01:30 pm in the year 1983, %B %d at %I:%M %p in the year %Y) = 1983-09-06 13:30:00, error: 0 timestamp_defmt_asc( 1976, July 14. Time: 9:15am, %Y, %B %d. Time: %I:%M %p) = 1976-07-14 09:15:00, error: 0 --- 41,47 18 October %34 17:28:44 CEST 80, abc%n %C %B %%%d %H:%M:%S %Z %y) = 1880-10-31 15:28:44, error (should be error!): 1 timestamp_defmt_asc(abc 18 October %34 17:28:44 CEST 80, ) = 1880-10-31 15:28:44, error (should be error!): 1 ! timestamp_defmt_asc(1980-04-12 3:49:44 , ) = 1980-04-12 03:49:44, error: 0 timestamp_defmt_asc(July 14, 1988. Time: 9:15am, %B %d, %Y. Time: %I:%M%p) = 1988-07-14 09:15:00, error: 0 timestamp_defmt_asc(September 6 at 01:30 pm in the year 1983, %B %d at %I:%M %p in the year %Y) = 1983-09-06 13:30:00, error: 0 timestamp_defmt_asc( 1976, July 14. Time: 9:15am, %Y, %B %d. Time: %I:%M %p) = 1976-07-14 09:15:00, error: 0 *** expected/sql-desc.stdoutThu Aug 3 09:24:58 2006 --- results//sql-desc.stdoutFri Aug 4 12:56:15 2006 *** *** 1,4 output = 1 ! val1=1 (ind1: 0) val2='one' (ind2: 0) val1=2 val2=null val1=2 val2=null --- 1,4 output = 1 ! val1=654311425 (ind1: 0) val2='one' (ind2: 0) val1=2 val2=null val1=2 val2=null *** expected/sql-dyntest2.stderrFri Aug 4 08:50:50 2006 --- results//sql-dyntest2.stderrFri Aug 4 12:56:17 2006 *** *** 58,64 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 2 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGget_data line 127: RESULT: 10297 offset: 1024 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 3 [NO_PID]: sqlca: code: 0, state: 0 --- 58,64 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 2 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGget_data line 127: RESULT: 10300 offset: 1024 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 3 [NO_PID]: sqlca: code: 0, state: 0 *** *** 198,204 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 2 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGget_data line 127: RESULT: 10300 offset: 1024 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 3 [NO_PID]: sqlca: code: 0, state: 0 --- 198,204 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 2 [NO_PID]: sqlca: code: 0, state: 0 ! [NO_PID]: ECPGget_data line 127: RESULT: 10303 offset: 1024 array: Yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGget_desc: reading items for tuple 3 [NO_PID]: sqlca: code: 0, state: 0 *** expected/sql-dyntest2.stdoutFri Aug 4
Re: [HACKERS] ecpg test suite
Hi, I just committed some changes by Joachim that should reduce the problems and the differences by a large margin. Could you please rerun the test and send us the regression.diff? Thanks a lot in advance. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] ecpg test suite
Michael Meskes [EMAIL PROTECTED] writes: I just committed some changes by Joachim that should reduce the problems and the differences by a large margin. Could you please rerun the test and send us the regression.diff? Thanks a lot in advance. While init.pgc no longer fails outright, it still generates a pile of unsightly compiler warnings, eg on Fedora 5 (gcc 4.1.1) dyntest.pgc:66: WARNING: nullable is always 1 dyntest2.pgc:72: WARNING: nullable is always 1 init.pgc:8: warning: no previous prototype for 'fa' init.pgc:15: warning: no previous prototype for 'fb' init.pgc:22: warning: no previous prototype for 'fc' init.pgc:28: warning: no previous prototype for 'fd' init.pgc:34: warning: no previous prototype for 'fe' init.pgc:40: warning: no previous prototype for 'sqlnotice' init.pgc: In function 'main': init.pgc:76: warning: unused variable 'f' init.pgc:73: warning: unused variable 'iax' init.pgc:72: warning: unused variable 'iay' init.pgc:71: warning: unused variable 'h' init.pgc:70: warning: unused variable 'c' init.pgc:69: warning: unused variable 'e' init.pgc:67: warning: unused variable 'j' init.pgc:66: warning: unused variable 'i' init.pgc:65: warning: unused variable 'g' init.pgc:64: warning: unused variable 'd' init.pgc:63: warning: unused variable 'b2' init.pgc:62: warning: unused variable 'b' init.pgc:61: warning: unused variable 'a' init.pgc:69: warning: 'y' is used uninitialized in this function test_informix.pgc: In function 'main': test_informix.pgc:20: warning: implicit declaration of function 'exit' test_informix.pgc:20: warning: incompatible implicit declaration of built-in function 'exit' I find this really unacceptable. There is no other part of the Postgres tree besides ecpg that generates any warnings at all. As for the actual test, I get: $ make check ... if [ all = clean ]; then rm -f results/*.stdout results/*.stderr results/*.c; rm -rf tmp_check/; rm -f log/*.log; rm -f pg_regress.inc.sh regression.diff; fi sh ./pg_regress.sh --dbname=regress1 --debug --temp-install --top-builddir=../. ./../.. --temp-port=55444 --listen-on-tcp --multibyte=SQL_ASCII --load-language= plpgsql == creating temporary installation== == initializing database system == == starting postmaster== running on port 55444 with pid 10754 == creating database regress1 == CREATE DATABASE == installing plpgsql == == creating database connectdb == CREATE DATABASE == installing plpgsql == == running regression test queries== /home/tgl/pgsql/src/interfaces/ecpg/test/./tmp_check/install//home/tgl/testversion/bin/createuser -R -S -D -q regressuser1 /home/tgl/pgsql/src/interfaces/ecpg/test/./tmp_check/install//home/tgl/testversion/bin/createuser -R -S -D -q connectuser testing connect/test1.pgc ... FAILED (log, output, source) testing connect/test2.pgc ... FAILED (log, output, source) testing connect/test3.pgc ... FAILED (log, output, source) testing connect/test4.pgc ... FAILED (log, output, source) testing compat_informix/test_informix.pgc ... FAILED (log, output, source) testing compat_informix/test_informix2.pgc ... FAILED (log, output, source) testing complex/test1.pgc ... FAILED (log, output, source) testing complex/test2.pgc ... FAILED (log, output, source) testing complex/test3.pgc ... FAILED (log, output, source) testing complex/test4.pgc ... FAILED (log, output, source) testing complex/test5.pgc ... FAILED (log, output, source) testing errors/init.pgc... FAILED (log, output, source) testing pgtypeslib/dt_test.pgc ... FAILED (log, output, source) testing pgtypeslib/dt_test2.pgc... FAILED (log, output, source) testing pgtypeslib/num_test.pgc... FAILED (log, output, source) testing sql/code100.pgc... FAILED (log, output, source) testing sql/copystdout.pgc ... FAILED (log, output, source) testing sql/define.pgc ... FAILED (log, output, source) testing sql/desc.pgc ... FAILED (log, output, source) testing sql/dynalloc.pgc ... FAILED (log, output, source) testing sql/dynalloc2.pgc ... FAILED (log, output, source) testing sql/dyntest.pgc... FAILED (log, output, source) testing sql/dyntest2.pgc ... FAILED (log, output, source) testing sql/func.pgc ... FAILED (log, output, source) testing sql/indicators.pgc ... FAILED (log,
Re: [HACKERS] ecpg test suite
On Thu, Aug 03, 2006 at 09:47:27AM -0400, Tom Lane wrote: While init.pgc no longer fails outright, it still generates a pile of unsightly compiler warnings, eg on Fedora 5 (gcc 4.1.1) ... I find this really unacceptable. There is no other part of the Postgres tree besides ecpg that generates any warnings at all. Tom, keep in mind that we are working on this. The tests were originally just some files I used to develop with. We are now making them become part of the source tree. The warnings should be gone by now, except for the ECPG warning that is supposed to come out. Maybe we remove that line. Joachim didn't want me to commit his SoC stuff before he finishes work, but I felt this is the better way because we get some testing on other architectures/OSes so everything should be up and running come release time. diff: `-3' option is obsolete; omit it diff: Try `diff --help' for more information. Strange, works well on my Linux system. However, I tried correcting the option but I'm unsure if it works for you now since both versions worked for me. Regression.diffs is empty, possibly because of the incorrect diff invocation hinted at by the last message, but looking into the results directory makes it look like you've not got everything on the same page about which port number to use: [NO_PID]: connect: could not open database connectdb on localhost port 55432 for user connectuser in line 41 could not connect to server: Connection refused Is the server running on host localhost and accepting TCP/IP connections on port 55432? That's not the port the temp postmaster is listening on; I suspect you've got some hard-wired assumption in there that the user hasn't specified a nonstandard --port option to configure. I find it disturbing that the regression test script doesn't mention having shut down the temp postmaster, too. No idea. Joachim? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] ecpg test suite
On Thu, Aug 03, 2006 at 04:54:35PM +0200, Michael Meskes wrote: diff: `-3' option is obsolete; omit it diff: Try `diff --help' for more information. Strange, works well on my Linux system. However, I tried correcting the option but I'm unsure if it works for you now since both versions worked for me. This got introduced by Rocco's Makefile patch, it worked for me, so I thought it's fine. Rocco, your AIX box will work with only diff -c as well, won't it? [NO_PID]: connect: could not open database connectdb on localhost port 55432 for user connectuser in line 41 could not connect to server: Connection refused Is the server running on host localhost and accepting TCP/IP connections on port 55432? That's not the port the temp postmaster is listening on; I suspect you've got some hard-wired assumption in there that the user hasn't specified a nonstandard --port option to configure. I find it disturbing that the regression test script doesn't mention having shut down the temp postmaster, too. No idea. Joachim? Yes, it's hardcoded but in just one file. Only one of the connect-Tests does tcp/ip connects. This can't be changed by a simple #define nor exec sql define, so I added a template file and replaced the port number with sed. Michael, in a few minutes I'll send you a patch that fixes all of Tom's suggestions (however you might have done parts of it already by yourself, like the diff options and the warnings...). Joachim -- Joachim Wieland [EMAIL PROTECTED] GPG key available ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] ecpg test suite
Joachim Wieland [EMAIL PROTECTED] writes: diff: `-3' option is obsolete; omit it diff: Try `diff --help' for more information. This got introduced by Rocco's Makefile patch, it worked for me, so I thought it's fine. Rocco, your AIX box will work with only diff -c as well, won't it? The spelling we've used for many years is diff -w -C3 Is there a reason to change from that? Yes, it's hardcoded but in just one file. Only one of the connect-Tests does tcp/ip connects. This can't be changed by a simple #define nor exec sql define, so I added a template file and replaced the port number with sed. At least from my perspective, it would be good if there were a way to run the regression tests without any use of TCP ports. The problem is that Red Hat's build system tends to try to build 32-bit and 64-bit variants of the same architecture concurrently in different chroots on the same machine. Tests using unix sockets work fine in this environment, tests using TCP sockets conflict and fail. If there's no way to run an ecpg test without TCP then I'll never be able to enable ecpg regression tests in Red Hat RPMs. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ecpg test suite
On Thu, Aug 03, 2006 at 11:36:22AM -0400, Tom Lane wrote: The spelling we've used for many years is diff -w -C3 I found only -w, but will append -C3 as well. Is there a reason to change from that? No. At least from my perspective, it would be good if there were a way to run the regression tests without any use of TCP ports. It's not necessary, ecpglib uses libpq as any other program, however it does its own parsing of the connect options and there are quite a few different formats you could use so it would be nice to cover that by a few small tests. Do you see a possibility to select what test should be run? Maybe no tcp connections by default but with an additional make-target checktcp? Joachim -- Joachim Wieland [EMAIL PROTECTED] GPG key available ---(end of broadcast)--- TIP 1: 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] ecpg test suite
Joachim Wieland [EMAIL PROTECTED] writes: On Thu, Aug 03, 2006 at 11:36:22AM -0400, Tom Lane wrote: At least from my perspective, it would be good if there were a way to run the regression tests without any use of TCP ports. Do you see a possibility to select what test should be run? Maybe no tcp connections by default but with an additional make-target checktcp? That would work for me. Note there are other reasons besides my Red-Hat-specific problem for not wanting to enable TCP connections during regression tests, for instance * on some platforms they will fail due to aggressive kernel packet filtering * one might not care to expose a postmaster running with auth-method trust to the network, even for just a few seconds. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] ecpg test suite
Joachim Wieland [EMAIL PROTECTED] writes: On Thu, Aug 03, 2006 at 11:36:22AM -0400, Tom Lane wrote: The spelling we've used for many years is diff -w -C3 I found only -w, but will append -C3 as well. Careful, there are two different usages: we use -C3 to generate the pretty report to regression.diffs, but not in the preliminary testing step. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] ecpg test suite
From: Joachim Wieland [mailto:[EMAIL PROTECTED] Sent: Thursday, August 03, 2006 11:23 AM To: Tom Lane; Michael Meskes; Rocco Altier; PostgreSQL Hacker Subject: Re: [HACKERS] ecpg test suite On Thu, Aug 03, 2006 at 04:54:35PM +0200, Michael Meskes wrote: diff: `-3' option is obsolete; omit it diff: Try `diff --help' for more information. Strange, works well on my Linux system. However, I tried correcting the option but I'm unsure if it works for you now since both versions worked for me. This got introduced by Rocco's Makefile patch, it worked for me, so I thought it's fine. Rocco, your AIX box will work with only diff -c as well, won't it? I had used -c to replace the -u. The '-c3' does not work on my machine, but '-C3' does, so I think we should go with that. Thanks, -rocco ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ecpg test suite
Here is my updated regression.diff. Like Tom, I was running with my server configured to run on 5678, instead of 5432, so it seems like the test is using a wrong port number somewhere. I changed my local pg_regress.sh to use -C3 on the diffs, until we figure out what the final form of that will be. BTW, I do have --enable-integer-datetimes configured for this machine, which might explain the timestamp differences. Thanks, -rocco -Original Message- From: Michael Meskes [mailto:[EMAIL PROTECTED] Sent: Thursday, August 03, 2006 9:12 AM To: Rocco Altier Cc: Michael Meskes; PostgreSQL Hacker; [EMAIL PROTECTED] Subject: Re: [HACKERS] ecpg test suite Hi, I just committed some changes by Joachim that should reduce the problems and the differences by a large margin. Could you please rerun the test and send us the regression.diff? Thanks a lot in advance. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! regression.diff Description: regression.diff ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] ecpg test suite
On Thu, Aug 03, 2006 at 11:36:22AM -0400, Tom Lane wrote: The spelling we've used for many years is diff -w -C3 Is there a reason to change from that? This was my fault. When I changed the options I mixed upper and lowercase and used lowercase 'c' instead of uppercase 'C'. That should be fixed now. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] ecpg test suite
Michael Meskes wrote: I'm in the process of committing the first version of the ecpg regression test suite to CVS. This is not exactly finished work, but it shows OK on all test on my machine and on Joachim's machine. The tests need to be tweaked some before it's finished, but I'd like to hear about what others are seeing soon enough to be able to fix bugs before 8.2. Just run make check in src/interfaces/ecpg and tell us if there is some test that fails. This should be set up so that we can easily run it on the buildfarm automated setup - the simplest way would probably be with an installcheck target. Feel free to ping me if you need help in making it buildfarm friendly. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
