Thread: ecpg test suite
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. 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@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
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
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@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> 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.shregression.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, output, source)
testing sql/quote.pgc ... FAILED (log, output, source)
testing sql/show.pgc ... FAILED (log, output, source)
testing thread/thread.pgc ... FAILED (log, output, source)
testing thread/thread_implicit.pgc ... FAILED (log, output, source)
diff: `-3' option is obsolete; omit it
diff: Try `diff --help' for more information.
make[1]: Leaving directory `/home/tgl/pgsql/src/interfaces/ecpg/test'
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.
regards, tom lane
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: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
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 joe@mcknight.de
GPG key available
Joachim Wieland <joe@mcknight.de> 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 isdiff -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
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 joe@mcknight.de
GPG key available
Joachim Wieland <joe@mcknight.de> 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
Joachim Wieland <joe@mcknight.de> 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
> From: Joachim Wieland [mailto:joe@mcknight.de] > 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
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@postgresql.org]
> Sent: Thursday, August 03, 2006 9:12 AM
> To: Rocco Altier
> Cc: Michael Meskes; PostgreSQL Hacker; joe@mcknight.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@jabber.org
> Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
>
Attachment
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: meskes@jabber.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 yourmachine? Or else could you build with debugging enabled on C level and trace down the function where the out of memoryoccurs? - different value in sql/desc: This is strange as the stderr output seems to be the same. This could be a memory problemtoo. - 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@jabber.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
(shouldbe error!): 1 timestamp_defmt_asc(abc 18 October %34 17:28:44 CEST 80, ) = 1880-10-31 15:28:44, error (should
beerror!): 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
pmin 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
(shouldbe error!): 1 timestamp_defmt_asc(abc 18 October %34 17:28:44 CEST 80, ) = 1880-10-31 15:28:44, error (should
beerror!): 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
theyear 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
(shouldbe error!): 1 timestamp_defmt_asc(abc 18 October %34 17:28:44 CEST 80, ) = 1880-10-31 15:28:44, error (should
beerror!): 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
pmin 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
(shouldbe error!): 1 timestamp_defmt_asc(abc 18 October %34 17:28:44 CEST 80, ) = 1880-10-31 15:28:44, error (should
beerror!): 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
theyear 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@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
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
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@jabber.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@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
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
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_dataline 44: RESULT: v offset: -1 array: Yes [NO_PID]: sqlca: code: 0, state: 00000 [NO_PID]: ECPGget_desc:
readingitems 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_dataline 47: RESULT: f offset: -1 array: Yes [NO_PID]: sqlca: code: 0, state: 00000 [NO_PID]: ECPGget_desc:
readingitems 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_dataline 44: RESULT: v offset: -1 array: Yes [NO_PID]: sqlca: code: 0, state: 00000 [NO_PID]: ECPGget_desc:
readingitems 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_dataline 47: RESULT: f offset: -1 array: Yes [NO_PID]: sqlca: code: 0, state: 00000 [NO_PID]: ECPGget_desc:
readingitems 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_dataline 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_dataline 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@mcknight.de
GPG key available
On 8/2/06, Michael Meskes <meskes@postgresql.org> 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
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 joe@mcknight.de GPG key available
On 8/8/06, Joachim Wieland <joe@mcknight.de> 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