I said:
> AFAICT, the diffs simply indicate that psql isn't echoing the input
> commands --- ie, it's not honoring the "\set ECHO all" command that
> is fed to it by the regression script. Which is odd in itself, and
> especially odd that it happens only in two out of 90-odd tests. I
> think you have a psql bug to chase.
I thought of another possibility. The part of pg_regress that is doing
this looks like
(cat <<EOF
\\set ECHO all
EOF cat "$inputdir/sql/$name.sql") | \ $PSQL -d $dbname >"$outputdir/results/$name.out" 2>&1
which means that the \set ECHO command is sourced from a separate "cat"
process than the one that emits the test script proper. If, for some
reason, that "cat" failed in those two regression tests, then we'd see
the observed symptoms --- and AFAIK the regression script wouldn't
complain otherwise.
The trouble with this theory is thinking of a plausible reason for those
two "cat"s to fail when everything else works. The only thing that
comes to mind for me is running into a per-user limit on the number of
processes. However, these two tests appear in a sixteen-test parallel
set, which is not the widest parallelism in the regression tests
(there's a twenty-way test set earlier). So it's a little hard to
credit that these would fail when the earlier set passed. You would
have to assume that in between the 20-way step and the 16-way step,
a whole bunch of other postgres-owned processes were started.
So the theory seems shaky to me, but maybe you can think of a variant
that is plausible for your environment.
Another thing worth asking is whether the failure is repeatable? Try
ten or so regression runs and see if they all act the same.
regards, tom lane
