v7.4 Beta 1 Bundle Available for Testing ...

Lists: pgsql-announcepgsql-generalpgsql-hackers
From: The Hermit Hacker <scrappy(at)postgresql(dot)org>
To: pgsql-general(at)postgresql(dot)org
Cc: pgsql-announce(at)postgresql(dot)org
Subject: v7.4 Beta 1 Bundle Available for Testing ...
Date: 2003-08-06 00:00:53
Message-ID: 20030805205635.U1434@hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-announce pgsql-general pgsql-hackers


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(at)postgresql(dot)org

Thank you

Marc G. Fournier
Co-ordinator
PostgreSQL Global Development Group


From: Alessio Bragadini <alessio(at)albourne(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Adriaan Joubert <a(dot)joubert(at)albourne(dot)com>
Subject: Re: v7.4 Beta 1 fails regression on Digital Unix/Tru64 4.0
Date: 2003-08-06 15:57:17
Message-ID: 1060185437.18944.643.camel@iris
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-announce pgsql-general pgsql-hackers

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(at)albourne(dot)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

Attachment Content-Type Size
regression.diffs text/x-patch 18.5 KB

From: Bruno Wolff III <bruno(at)wolff(dot)to>
To: The Hermit Hacker <scrappy(at)postgresql(dot)org>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: v7.4 Beta 1 Bundle Available for Testing ...
Date: 2003-08-06 17:51:21
Message-ID: 20030806175121.GA28850@wolff.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-announce pgsql-general pgsql-hackers

On Tue, Aug 05, 2003 at 21:00:53 -0300,
The Hermit Hacker <scrappy(at)postgresql(dot)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.


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alessio Bragadini <alessio(at)albourne(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Adriaan Joubert <a(dot)joubert(at)albourne(dot)com>
Subject: Re: v7.4 Beta 1 fails regression on Digital Unix/Tru64 4.0
Date: 2003-08-06 17:57:30
Message-ID: 1400.1060192650@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-announce pgsql-general pgsql-hackers

Alessio Bragadini <alessio(at)albourne(dot)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


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alessio Bragadini <alessio(at)albourne(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Adriaan Joubert <a(dot)joubert(at)albourne(dot)com>
Subject: Re: v7.4 Beta 1 fails regression on Digital Unix/Tru64 4.0
Date: 2003-08-07 00:05:13
Message-ID: 10256.1060214713@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-announce pgsql-general pgsql-hackers

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