
Just a quick note to everyone that v7.4 is now official in Beta Freeze,
with the first Bundle available for download, testing and bug reports ...

The Bundle is available on all FTP mirrors (in both .gz and .bz2 format)
under:

	/pub/source/v7.4

We encourage everyone that is able to download, test and report any bugs
on this release to do so, so that we can ensure that this release is as
strong as all our past releases.

All bug reports should be addressed to: pgsql-bugs@postgresql.org

Thank you

Marc G. Fournier
Co-ordinator
PostgreSQL Global Development Group



Tue, 5 Aug 2003 21:00:53 -0300 (ADT)
The Hermit Hacker <scrappy@postgresql.org>
v7.4 Beta 1 Bundle Available for Testing ...
The first beta fails two regression tests
on alphaev67-dec-osf4.0g, compiled by cc -std -std
i.e. Compaq/HP Digital Unix/Tru64/name-of-the-day

They are "join" (FAILED) and "random" (failed ignored). Attached is the
regression diff.

During configuration a warning stated that our version of Bison was
outdated, can it be related?

-- 
Alessio F. Bragadini		alessio@albourne.com
APL Financial Services		http://village.albourne.com
Nicosia, Cyprus		 	phone: +357-22755750

"It is more complicated than you think"
		-- The Eighth Networking Truth from RFC 1925
06 Aug 2003 18:57:17 +0300
Alessio Bragadini <alessio@albourne.com>
Re: v7.4 Beta 1 fails regression on Digital Unix/Tru64 4.0
On Tue, Aug 05, 2003 at 21:00:53 -0300,
  The Hermit Hacker <scrappy@postgresql.org> wrote:
> 
> Just a quick note to everyone that v7.4 is now official in Beta Freeze,
> with the first Bundle available for download, testing and bug reports ...

http://developer.postgresql.org/beta.php doesn't point to the 7.4 betas
but instead says to check back in a few months.

Wed, 6 Aug 2003 12:51:21 -0500
Bruno Wolff III <bruno@wolff.to>
Re: v7.4 Beta 1 Bundle Available for Testing ...
Alessio Bragadini <alessio@albourne.com> writes:
> The first beta fails two regression tests
> on alphaev67-dec-osf4.0g, compiled by cc -std -std
> i.e. Compaq/HP Digital Unix/Tru64/name-of-the-day

> They are "join" (FAILED) and "random" (failed ignored). Attached is the
> regression diff.

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.

> During configuration a warning stated that our version of Bison was
> outdated, can it be related?

No.  psql doesn't depend on bison.  A build from a tarball doesn't
use your local bison anyway (unless you build contrib).

			regards, tom lane

Wed, 06 Aug 2003 13:57:30 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: v7.4 Beta 1 fails regression on Digital Unix/Tru64 4.0 
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

Wed, 06 Aug 2003 20:05:13 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: v7.4 Beta 1 fails regression on Digital Unix/Tru64 4.0 