Re: 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:meskes(at)postgresql(dot)org]
> Sent: Thursday, August 03, 2006 9:12 AM
> To: Rocco Altier
> Cc: Michael Meskes; PostgreSQL Hacker; joe(at)mcknight(dot)de
> 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: meskes(at)jabber(dot)org
> Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
>

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: meskes(at)jabber(dot)org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

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,070000 text=0123456789 b=1
Found a[0] = 9
Found a[1] = 8
Found a[2] = 7
--- 1,4 ----
! Found f=14.070000 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: 00000
[NO_PID]: ECPGget_data line 37: RESULT: 2000-07-12 17:34:29 offset: 8 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 37: RESULT: 13556 days 12:34:00 offset: 12 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGtrans line 354 action = rollback connection = regress1
[NO_PID]: sqlca: code: 0, state: 00000
--- 22,28 ----
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 37: RESULT: 2000-07-12 17:34:29 offset: 8 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 37: RESULT: 13556 days 12:34:00 offset: 16 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGtrans line 354 action = rollback connection = regress1
[NO_PID]: sqlca: code: 0, state: 00000
*** 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.stderr Fri Aug 4 08:50:50 2006
--- results//sql-dyntest2.stderr Fri Aug 4 10:12:23 2006
***************
*** 58,64 ****
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 2
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 127: RESULT: 10297 offset: 1024 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 3
[NO_PID]: sqlca: code: 0, state: 00000
--- 58,64 ----
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 2
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 127: RESULT: 10300 offset: 1024 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 3
[NO_PID]: sqlca: code: 0, state: 00000
***************
*** 198,204 ****
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 2
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 127: RESULT: 10300 offset: 1024 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 3
[NO_PID]: sqlca: code: 0, state: 00000
--- 198,204 ----
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 2
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 127: RESULT: 10303 offset: 1024 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 3
[NO_PID]: sqlca: code: 0, state: 00000
*** expected/sql-dyntest2.stdout Fri Aug 4 08:50:50 2006
--- results//sql-dyntest2.stdout Fri Aug 4 10:12:23 2006
***************
*** 4,10 ****
= <"_RETURN">
2 ev_class (type: -26 length: -5 precision: -1 scale: 65531
octet_length: 4 returned_octet_length: 5)
! = <"10297">
3 ev_attr (type: 5 length: -5 precision: -1 scale: 65531
octet_length: 2 returned_octet_length: 2)
= -1
--- 4,10 ----
= <"_RETURN">
2 ev_class (type: -26 length: -5 precision: -1 scale: 65531
octet_length: 4 returned_octet_length: 5)
! = <"10300">
3 ev_attr (type: 5 length: -5 precision: -1 scale: 65531
octet_length: 2 returned_octet_length: 2)
= -1
***************
*** 22,28 ****
= <"_RETURN">
2 ev_class (type: -26 length: -5 precision: -1 scale: 65531
octet_length: 4 returned_octet_length: 5)
! = <"10300">
3 ev_attr (type: 5 length: -5 precision: -1 scale: 65531
octet_length: 2 returned_octet_length: 2)
= -1
--- 22,28 ----
= <"_RETURN">
2 ev_class (type: -26 length: -5 precision: -1 scale: 65531
octet_length: 4 returned_octet_length: 5)
! = <"10303">
3 ev_attr (type: 5 length: -5 precision: -1 scale: 65531
octet_length: 2 returned_octet_length: 2)
= -1

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,070000 text=0123456789 b=1
Found a[0] = 9
Found a[1] = 8
Found a[2] = 7
--- 1,4 ----
! Found f=14.070000 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: 00000
[NO_PID]: ECPGget_data line 37: RESULT: 2000-07-12 17:34:29 offset: 8 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 37: RESULT: 13556 days 12:34:00 offset: 12 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGtrans line 354 action = rollback connection = regress1
[NO_PID]: sqlca: code: 0, state: 00000
--- 22,28 ----
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 37: RESULT: 2000-07-12 17:34:29 offset: 8 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 37: RESULT: 13556 days 12:34:00 offset: 16 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGtrans line 354 action = rollback connection = regress1
[NO_PID]: sqlca: code: 0, state: 00000
*** 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.stdout Thu Aug 3 09:24:58 2006
--- results//sql-desc.stdout Fri 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.stderr Fri Aug 4 08:50:50 2006
--- results//sql-dyntest2.stderr Fri Aug 4 12:56:17 2006
***************
*** 58,64 ****
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 2
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 127: RESULT: 10297 offset: 1024 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 3
[NO_PID]: sqlca: code: 0, state: 00000
--- 58,64 ----
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 2
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 127: RESULT: 10300 offset: 1024 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 3
[NO_PID]: sqlca: code: 0, state: 00000
***************
*** 198,204 ****
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 2
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 127: RESULT: 10300 offset: 1024 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 3
[NO_PID]: sqlca: code: 0, state: 00000
--- 198,204 ----
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 2
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGget_data line 127: RESULT: 10303 offset: 1024 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 3
[NO_PID]: sqlca: code: 0, state: 00000
*** expected/sql-dyntest2.stdout Fri Aug 4 08:50:50 2006
--- results//sql-dyntest2.stdout Fri Aug 4 12:56:17 2006
***************
*** 4,10 ****
= <"_RETURN">
2 ev_class (type: -26 length: -5 precision: -1 scale: 65531
octet_length: 4 returned_octet_length: 5)
! = <"10297">
3 ev_attr (type: 5 length: -5 precision: -1 scale: 65531
octet_length: 2 returned_octet_length: 2)
= -1
--- 4,10 ----
= <"_RETURN">
2 ev_class (type: -26 length: -5 precision: -1 scale: 65531
octet_length: 4 returned_octet_length: 5)
! = <"10300">
3 ev_attr (type: 5 length: -5 precision: -1 scale: 65531
octet_length: 2 returned_octet_length: 2)
= -1
***************
*** 22,28 ****
= <"_RETURN">
2 ev_class (type: -26 length: -5 precision: -1 scale: 65531
octet_length: 4 returned_octet_length: 5)
! = <"10300">
3 ev_attr (type: 5 length: -5 precision: -1 scale: 65531
octet_length: 2 returned_octet_length: 2)
= -1
--- 22,28 ----
= <"_RETURN">
2 ev_class (type: -26 length: -5 precision: -1 scale: 65531
octet_length: 4 returned_octet_length: 5)
! = <"10303">
3 ev_attr (type: 5 length: -5 precision: -1 scale: 65531
octet_length: 2 returned_octet_length: 2)
= -1

regards, tom lane

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,070000 text=0123456789 b=1
> Found a[0] = 9
> Found a[1] = 8
> Found a[2] = 7
> --- 1,4 ----
> ! Found f=14.070000 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.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: 00000
> [NO_PID]: ECPGget_data line 37: RESULT: 2000-07-12 17:34:29 offset: 8 array: Yes
> [NO_PID]: sqlca: code: 0, state: 00000
> ! [NO_PID]: ECPGget_data line 37: RESULT: 13556 days 12:34:00 offset: 12 array: Yes
> [NO_PID]: sqlca: code: 0, state: 00000
> [NO_PID]: ECPGtrans line 354 action = rollback connection = regress1
> [NO_PID]: sqlca: code: 0, state: 00000
> --- 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.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

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: meskes(at)jabber(dot)org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

Michael Meskes <meskes(at)postgresql(dot)org> 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

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: meskes(at)jabber(dot)org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

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: meskes(at)jabber(dot)org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

Michael Meskes <meskes(at)postgresql(dot)org> 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

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.stdout Thu Aug 3 09:24:58 2006
--- results//sql-desc.stdout Tue 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.stdout Mon Aug 7 09:17:02 2006
--- results//pgtypeslib-num_test2.stdout Tue Aug 8 08:51:06 2006
***************
*** 53,59 ****
(no errno set) - num[4,3]: 5924900000.0
(no errno set) - num[4,4]: 5924900000.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]: 5924900000.0000000 (r: 0)
(no errno set) - num[4,11]: 5924900000.00 (cmp: 0)
--- 53,60 ----
(no errno set) - num[4,3]: 5924900000.0
(no errno set) - num[4,4]: 5924900000.00
(no errno set) - num[4,5]: 0.00
! (no errno set) - num[4,6]: 5924900000 (r: 0)
! (no errno set) - num[4,7]: 5924900000.00 (cmp: 0)
(errno == PGTYPES_NUM_OVERFLOW) - num[4,8]: 0 (r: -1)
(errno == PGTYPES_NUM_OVERFLOW) - num[4,10]: 5924900000.0000000 (r: 0)
(no errno set) - num[4,11]: 5924900000.00 (cmp: 0)
*** expected/sql-dynalloc.stderr Tue Aug 8 08:43:33 2006
--- results//sql-dynalloc.stderr Tue Aug 8 08:51:06 2006
***************
*** 34,75 ****
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 3
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 43: allocating 21 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 43: RESULT: varchar offset: -1 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 43: RESULT: offset: -1 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 4
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 44: allocating 16 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 44: RESULT: v offset: -1 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 44: RESULT: v offset: -1 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 5
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 45: allocating 22 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 45: RESULT: c offset: -1 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 45: RESULT: c offset: -1 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 6
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 46: allocating 70 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
[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: 00000
[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: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 7
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 47: allocating 16 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 47: RESULT: t offset: -1 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 47: RESULT: f offset: -1 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 9
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 50: allocating 46 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
[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: 00000
[NO_PID]: ECPGget_data line 50: RESULT: offset: -1 array: Yes
--- 34,75 ----
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 3
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 43: allocating 33 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 43: RESULT: varchar offset: -1 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 43: RESULT: offset: -1 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 4
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 44: allocating 28 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 44: RESULT: v offset: -1 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 44: RESULT: v offset: -1 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 5
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 45: allocating 34 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 45: RESULT: c offset: -1 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 45: RESULT: c offset: -1 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 6
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 46: allocating 82 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
[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: 00000
[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: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 7
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 47: allocating 28 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 47: RESULT: t offset: -1 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 47: RESULT: f offset: -1 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 9
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 50: allocating 58 bytes for 2 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
[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: 00000
[NO_PID]: ECPGget_data line 50: RESULT: offset: -1 array: Yes
*** expected/sql-dynalloc2.stderr Tue Aug 8 08:43:33 2006
--- results//sql-dynalloc2.stderr Tue Aug 8 08:51:06 2006
***************
*** 54,60 ****
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 2
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 34: allocating 49 bytes for 6 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 34: RESULT: one offset: -1 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 34: RESULT: two offset: -1 array: Yes
--- 54,60 ----
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_desc: reading items for tuple 2
[NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: ECPGstore_result: line 34: allocating 77 bytes for 6 tuples (char**=0)[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 34: RESULT: one offset: -1 array: Yes
[NO_PID]: sqlca: code: 0, state: 00000
[NO_PID]: ECPGget_data line 34: RESULT: two offset: -1 array: Yes

regards, tom lane

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 joe(at)mcknight(dot)de
GPG key available