Re: AW: [HACKERS] v7.0.3 *pre-release* ...
The Hermit Hacker [EMAIL PROTECTED] writes: If its that easy to fix the regress test so that it passes, can we get it committed and build a new tarball so that ppl doing regression on v7.0.3 see a clean regress? The way I want to fix it will probably require getting new geometry files for all the platform variants (or at least, those that are still distinct after controlling for sort order). Not worth holding up 7.0.3 for that. But I thought Pete was having trouble reproducing the sort-order issue anyway, so there may still be some investigation to do beforehand. regards, tom lane
Re: AW: [HACKERS] v7.0.3 *pre-release* ...
If its that easy to fix the regress test so that it passes, can we get it
committed and build a new tarball so that ppl doing regression on v7.0.3
see a clean regress?
On Tue, 7 Nov 2000, Tom Lane wrote:
Pete Forman [EMAIL PROTECTED] writes:
The only remaining failure is geometry. The results I got were nearly
identical to geometry-powerpc-aix4.out. The only differences were the
order of rows returned by three of the tables. I'll submit the
results file to pgsql-patches.
Rather than making still another results file, let's fix the .sql file
to do an explicit ORDER BY for those queries. The regress tests are
mostly pretty lazy about ensuring a platform-independent ordering of
query results. In many places we can get away with that, but every so
often we notice another place where we can't. Looks like you've just
identified another.
regards, tom lane
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
Re: AW: [HACKERS] v7.0.3 *pre-release* ...
Pete Forman writes: The only remaining failure is geometry. The results I got were nearly identical to geometry-powerpc-aix4.out. The only differences were the order of rows returned by three of the tables. I'll submit the results file to pgsql-patches. I've submitted a one line patch on resultmap. There was an oddity, on that one runtest on 7.0.3 the geometry.out had the rows in a different order from three of the select statements. Repeating the runtest five times passed consistently (with the new resultmap). Now I realise that in an RDB the set of results have no intrinsic order but find it a bit surprising that the regression tests are not consistent. -- Pete Forman -./\.- Disclaimer: This post is originated Western Geophysical -./\.- by myself and does not represent [EMAIL PROTECTED] -./\.- the opinion of Baker Hughes or http://www.crosswinds.net/~petef -./\.- its divisions.
AW: AW: [HACKERS] v7.0.3 *pre-release* ...
Pete Forman [EMAIL PROTECTED] writes: The only remaining failure is geometry. The results I got were nearly identical to geometry-powerpc-aix4.out. The only differences were the order of rows returned by three of the tables. I'll submit the results file to pgsql-patches. Rather than making still another results file, let's fix the .sql file to do an explicit ORDER BY for those queries. The regress tests are mostly pretty lazy about ensuring a platform-independent ordering of query results. In many places we can get away with that, but every so often we notice another place where we can't. Looks like you've just identified another. Has there been a change to geometry.out that was not incorporated into the platform specific geometry-powerpc-aix4.out between 7.0.2 and 7.0.3 ? This looks like a different plan is chosen now. I don't beleive this can be platform dependent. Andreas
AW: [HACKERS] v7.0.3 *pre-release* ...
How do you run the regression tests ? gmake all gmake install initdb start postmaster cd src/test/regress gmake runtest ? The build looks ok, but remember, that all shared libs and postmaster will only work in the configured location. (gmake runcheck will fail, since it installs into a different location) Andreas -Ursprüngliche Nachricht- Von: Pete Forman [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 07. November 2000 11:55 An: [EMAIL PROTECTED] Betreff: AW: [HACKERS] v7.0.3 *pre-release* ... Zeugswetter Andreas SB writes: AIX 4.3.2, xlc 3.6.6. Same regression test failures as 7.0.2. The nasty failures are triggers, misc, and plgpgsql which consistently give "pqReadData() -- backend closed the channel unexpectedly." at the same point. Also the sanity_check hangs during a VACUUM. Killing the backend was the only way to continue. This should not be so. Your setup should definitely work without regression failures. There is something wrong with your dynamic loading of shared libs. Can you give more details, e.g. did you add optimization which does not work yet ? No extra flags were added by me. The only build warnings were duplicate symbol errors. (There were a couple of warnings about 0.0/0.0 used to represent a NaN.) Here are a couple of extracts from my build log. xlc -I../include -I../backend -qmaxmem=16384 -qhalt=w -qsrcmsg -qlanglvl=extended -qlonglong -o postgres access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o parser/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o ../utils/version.o -lPW -lcrypt -lld -lnsl -ldl -lm -lcurses Making postgres.imp ../backend/port/aix/mkldexport.sh postgres /usr/local/pgsql/bin postgres.imp xlc -Wl,-bE:../backend/postgres.imp -o postgres access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o parser/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o ../utils/version.o -lPW -lcrypt -lld -lnsl -ldl -lm -lcurses xlc -I../../include -I../../backend -qmaxmem=16384 -qhalt=w -qsrcmsg -qlanglvl=extended -qlonglong -DFRONTEND -c pqsignal.c -o pqsignal.o ar crs libpq.a fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o pqexpbuffer.o dllist.o pqsignal.o touch libpq.a ../../backend/port/aix/mkldexport.sh libpq.a /usr/local/pgsql/lib libpq.exp ld -H512 -bM:SRE -bI:../../backend/postgres.imp -bE:libpq.exp -o libpq.so libpq.a -lPW -lcrypt -lld -lnsl -ldl -lm -lcurses -lcrypt -lc ld: 0711-224 WARNING: Duplicate symbol: .crypt ld: 0711-224 WARNING: Duplicate symbol: crypt ld: 0711-224 WARNING: Duplicate symbol: .strlen ld: 0711-224 WARNING: Duplicate symbol: strlen ld: 0711-224 WARNING: Duplicate symbol: .PQuntrace ld: 0711-224 WARNING: Duplicate symbol: .PQtrace ld: 0711-224 WARNING: Duplicate symbol: .setsockopt ld: 0711-224 WARNING: Duplicate symbol: setsockopt [and others] -- Pete Forman -./\.- Disclaimer: This post is originated Western Geophysical -./\.- by myself and does not represent [EMAIL PROTECTED] -./\.- the opinion of Baker Hughes or http://www.crosswinds.net/~petef -./\.- its divisions.
AW: [HACKERS] v7.0.3 *pre-release* ...
Zeugswetter Andreas SB writes: AIX 4.3.2, xlc 3.6.6. Same regression test failures as 7.0.2. The nasty failures are triggers, misc, and plgpgsql which consistently give "pqReadData() -- backend closed the channel unexpectedly." at the same point. Also the sanity_check hangs during a VACUUM. Killing the backend was the only way to continue. This should not be so. Your setup should definitely work without regression failures. There is something wrong with your dynamic loading of shared libs. Can you give more details, e.g. did you add optimization which does not work yet ? No extra flags were added by me. The only build warnings were duplicate symbol errors. (There were a couple of warnings about 0.0/0.0 used to represent a NaN.) Here are a couple of extracts from my build log. xlc -I../include -I../backend -qmaxmem=16384 -qhalt=w -qsrcmsg -qlanglvl=extended -qlonglong -o postgres access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o parser/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o ../utils/version.o -lPW -lcrypt -lld -lnsl -ldl -lm -lcurses Making postgres.imp ../backend/port/aix/mkldexport.sh postgres /usr/local/pgsql/bin postgres.imp xlc -Wl,-bE:../backend/postgres.imp -o postgres access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o parser/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o ../utils/version.o -lPW -lcrypt -lld -lnsl -ldl -lm -lcurses xlc -I../../include -I../../backend -qmaxmem=16384 -qhalt=w -qsrcmsg -qlanglvl=extended -qlonglong -DFRONTEND -c pqsignal.c -o pqsignal.o ar crs libpq.a fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o pqexpbuffer.o dllist.o pqsignal.o touch libpq.a ../../backend/port/aix/mkldexport.sh libpq.a /usr/local/pgsql/lib libpq.exp ld -H512 -bM:SRE -bI:../../backend/postgres.imp -bE:libpq.exp -o libpq.so libpq.a -lPW -lcrypt -lld -lnsl -ldl -lm -lcurses -lcrypt -lc ld: 0711-224 WARNING: Duplicate symbol: .crypt ld: 0711-224 WARNING: Duplicate symbol: crypt ld: 0711-224 WARNING: Duplicate symbol: .strlen ld: 0711-224 WARNING: Duplicate symbol: strlen ld: 0711-224 WARNING: Duplicate symbol: .PQuntrace ld: 0711-224 WARNING: Duplicate symbol: .PQtrace ld: 0711-224 WARNING: Duplicate symbol: .setsockopt ld: 0711-224 WARNING: Duplicate symbol: setsockopt [and others] -- Pete Forman -./\.- Disclaimer: This post is originated Western Geophysical -./\.- by myself and does not represent [EMAIL PROTECTED] -./\.- the opinion of Baker Hughes or http://www.crosswinds.net/~petef -./\.- its divisions.
AW: [HACKERS] v7.0.3 *pre-release* ...
I was unable to get runcheck to pass even when I altered all the LD_LIBRARY_PATH entries in run_check.sh to LIBPATH for the benefit of AIX. If this cannot be fixed there ought to be an entry added to the faq-aix. The fix for AIX below 4.3 would be to relink both postmaster and the libs with altered paths in the imp and exp files, which is imho impractical. For AIX 4.3 there might be a fix with new options in the first line of the imp and exp files that ld understands. If time permits I will take a go at that. Andreas
Re: AW: [HACKERS] v7.0.3 *pre-release* ...
Pete Forman [EMAIL PROTECTED] writes: The only remaining failure is geometry. The results I got were nearly identical to geometry-powerpc-aix4.out. The only differences were the order of rows returned by three of the tables. I'll submit the results file to pgsql-patches. Rather than making still another results file, let's fix the .sql file to do an explicit ORDER BY for those queries. The regress tests are mostly pretty lazy about ensuring a platform-independent ordering of query results. In many places we can get away with that, but every so often we notice another place where we can't. Looks like you've just identified another. regards, tom lane
