v7.0.3 *pre-release* ...

The Hermit Hacker writes:

ftp://ftp.postgresql.org/pub/source/v7.0.3

Please take a minute to download and test these out, so that when
we release, we don't get a bunch of "oops, you forgot this"
messages :)

I've tried it on a couple of platforms:

IRIX 6.5.5m, MIPSpro 7.3.

Configure detection of accept() is working.

Several regression tests fail. Two patches that I'd submitted to
fix these on IRIX have not been applied:

2000-08-18: Update tests/regress/resultmap for IRIX 6
2000-10-12: Regression tests - expected file for IRIX geometry test

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.

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

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 ?

Andreas

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.

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

My guess is that your patches are in current, but not in this
subrelease. We only put in show-stopper fixes.

The Hermit Hacker writes:

ftp://ftp.postgresql.org/pub/source/v7.0.3

Please take a minute to download and test these out, so that when
we release, we don't get a bunch of "oops, you forgot this"
messages :)

I've tried it on a couple of platforms:

IRIX 6.5.5m, MIPSpro 7.3.

Configure detection of accept() is working.

Several regression tests fail. Two patches that I'd submitted to
fix these on IRIX have not been applied:

2000-08-18: Update tests/regress/resultmap for IRIX 6
2000-10-12: Regression tests - expected file for IRIX geometry test

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.

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

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

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
postmaster will 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 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
pete.forman@westgeo.com -./\.- the opinion of Baker Hughes or
http://www.crosswinds.net/~petef -./\.- its divisions.

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

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

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.

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

Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:

This looks like a different plan is chosen now. I don't beleive this can be
platform dependent.

Well, the plan choice *could* be platform-dependent, given that the
planner uses comparisons of floating-point cost estimates. But I agree
that's pretty unlikely. What seems to be more common is platform-
specific differences of behavior of qsort(). If you have any equal
keys in the row set being sorted, then the output ordering depends on
the whim of the qsort implementor...

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