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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Michael Meskes <meskes@postgresql.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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Michael Meskes <meskes@postgresql.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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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@mcknight.de
GPG key available

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq