Thread: AW: 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:gsez020@kryten.bedford.waii.com] > Gesendet: Dienstag, 07. November 2000 11:55 > An: pgsql-hackers@postgresql.org > 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 > pete.forman@westgeo.com -./\.- the opinion of Baker Hughes or > http://www.crosswinds.net/~petef -./\.- its divisions. >
Zeugswetter Andreas SB writes:> 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> postmasterwill only work in the configured location. (gmake> runcheck will fail, since it installs into a different location) Indeed. runtest has passed on 7.0.2 and 7.0.3. 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 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. -- Pete Forman -./\.- Disclaimer: This post is originated Western Geophysical -./\.- by myself and does not represent pete.forman@westgeo.com -./\.- the opinion of Baker Hughes or http://www.crosswinds.net/~petef -./\.- its divisions.
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 theresults 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 pete.forman@westgeo.com -./\.- the opinion of Baker Hughes or http://www.crosswinds.net/~petef -./\.- its divisions.
Pete Forman <gsez020@kryten.bedford.waii.com> 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
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 <gsez020@kryten.bedford.waii.com> 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: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> 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