The following shell script has been seen to produce incorrect output on both Cygwin and FreeBSD:
#!/bin/sh
trap ' st=$? echo status = $st exit $st ' 0
(exit 9); exit
I'm not sure how we get a portable solution (other than maybe converting the shell script to perl).
cheers
andrew
I wrote:
I have seen several cases where either pg_regress appears not to exit with the expected non-zero exit status or "make check" does not apparently exit with the expected non-zero status.
In particular, I've seen it on cygwin, windows, and have at least a suspicion of it happening on FreeBSD.
The apparently offending code is this:
message "initializing database system"
[ "$debug" = yes ] && initdb_options='--debug'
"$bindir/initdb" -D "$PGDATA" -L "$datadir" --noclean $initdb_options >"$LOGDIR/initdb.log" 2>&1
if [ $? -ne 0 ] then echo echo "$me: initdb failed" echo "Examine $LOGDIR/initdb.log for the reason." echo (exit 2); exit fi
and it's called from this makefile target:
check: all
-rm -rf ./testtablespace
mkdir ./testtablespace
$(SHELL) ./pg_regress --temp-install --top-builddir=$(top_builddir) --schedule=$(srcdir)/parallel_schedule --multibyte=$(MULTIBYTE) $(MAXCONNOPT)
The practical consequence of this is that instead of failing at this stage, the buildfarm script continues on until it somewhat inexplicably fails at the initdb stage.
Now, perhaps I'm calling it wrong, but I don't think so. The relevant perl code is this:
my @makeout = `cd $pgsql/src/test/regress && $make check 2>&1`; my $status = $? >>8;
which idiom seems to work as expected everywhere else quite happily. And in fact I've seen "make check" fail as expected on other failure paths (such as not matching the expected result.)
Anyone have any penetrating thoughts?
cheers
andrew
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
