Further investigation has shown that the exit/trap idiom used in
pg_regress.sh is less than 100% portable.
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
>
>
>
>
>
