SEO

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.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, 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

---------------------------(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

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

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

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 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

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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

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

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

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

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

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!

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

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