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

-----Original Message-----
From: The Hermit Hacker [mailto:scrappy@postgresql.org]
Sent: Tuesday, August 05, 2003 5:01 PM
To: pgsql-general@postgresql.org
Cc: pgsql-announce@postgresql.org
Subject: [GENERAL] v7.4 Beta 1 Bundle Available for Testing ...

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

For me, I can only find these directories:
ftp://ftp8.us.postgresql.org/pub/pgsql/source/v7.4/
ftp://ftp8.us.postgresql.org/pub/postgresql/source/v7.4/
And both of them are empty.

When the drop eventually does become available will it contain any Win32
stuff (raw as it is)?

On Tue, 2003-08-05 at 20:18, Dann Corbit wrote:

-----Original Message-----
From: The Hermit Hacker [mailto:scrappy@postgresql.org]
Sent: Tuesday, August 05, 2003 5:01 PM
To: pgsql-general@postgresql.org
Cc: pgsql-announce@postgresql.org
Subject: [GENERAL] v7.4 Beta 1 Bundle Available for Testing ...

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

For me, I can only find these directories:
ftp://ftp8.us.postgresql.org/pub/pgsql/source/v7.4/
ftp://ftp8.us.postgresql.org/pub/postgresql/source/v7.4/
And both of them are empty.

Might be some lag in that mirror synching; try
ftp://ftp3.us.postgresql.org/pub/postgresql/source/v7.4/

When the drop eventually does become available will it contain any Win32
stuff (raw as it is)?

depends on what you mean by any. I believe that the standard tarball
will compile under windows, but to what extent it will actually run I
couldn't say. This release is not intended for native use on windows
(that had to be pushed back to 7.5), though it will certainly run via
cygwin.

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Wed, 6 Aug 2003, Robert Treat wrote:

depends on what you mean by any. I believe that the standard tarball
will compile under windows, but to what extent it will actually run I
couldn't say. This release is not intended for native use on windows
(that had to be pushed back to 7.5), though it will certainly run via
cygwin.

Ummm ... will it compile? I thought that the issue with the Windows
native port was that it wouldn't yet ... something about fork() vs exec()
that Bruce was working on?

It compiles, but does not link because of the missing fork/exec and
signals.

---------------------------------------------------------------------------

The Hermit Hacker wrote:

On Wed, 6 Aug 2003, Robert Treat wrote:

depends on what you mean by any. I believe that the standard tarball
will compile under windows, but to what extent it will actually run I
couldn't say. This release is not intended for native use on windows
(that had to be pushed back to 7.5), though it will certainly run via
cygwin.

Ummm ... will it compile? I thought that the issue with the Windows
native port was that it wouldn't yet ... something about fork() vs exec()
that Bruce was working on?

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Wed, 2003-08-06 at 09:22, The Hermit Hacker wrote:

On Wed, 6 Aug 2003, Robert Treat wrote:

depends on what you mean by any. I believe that the standard tarball
will compile under windows, but to what extent it will actually run I
couldn't say. This release is not intended for native use on windows
(that had to be pushed back to 7.5), though it will certainly run via
cygwin.

Ummm ... will it compile? I thought that the issue with the Windows
native port was that it wouldn't yet ... something about fork() vs exec()
that Bruce was working on?

Since it's always more fun to speculate than to wait for the proper
answer... I thought it would compile, but wouldn't actually run due to
exec/fork issues? Course that may have been someones development code
and not what got checked in I suppose...

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On 6 Aug 2003, Robert Treat wrote:

On Tue, 2003-08-05 at 20:18, Dann Corbit wrote:

For me, I can only find these directories:
ftp://ftp8.us.postgresql.org/pub/pgsql/source/v7.4/
ftp://ftp8.us.postgresql.org/pub/postgresql/source/v7.4/
And both of them are empty.

Might be some lag in that mirror synching; try
ftp://ftp3.us.postgresql.org/pub/postgresql/source/v7.4/

I just checked, and out of the 6 listed US mirrors, all but ftp8 and
ftp15 are updated. ftp15 seems more out of sync than ftp8, as it doesn't
even have 7.3.4 yet. Maybe it's sync script only runs once a week or so.

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

On Wed, 2003-08-06 at 11:17, scott.marlowe wrote:

On 6 Aug 2003, Robert Treat wrote:

On Tue, 2003-08-05 at 20:18, Dann Corbit wrote:

For me, I can only find these directories:
ftp://ftp8.us.postgresql.org/pub/pgsql/source/v7.4/
ftp://ftp8.us.postgresql.org/pub/postgresql/source/v7.4/
And both of them are empty.

Might be some lag in that mirror synching; try
ftp://ftp3.us.postgresql.org/pub/postgresql/source/v7.4/

I just checked, and out of the 6 listed US mirrors, all but ftp8 and
ftp15 are updated. ftp15 seems more out of sync than ftp8, as it doesn't
even have 7.3.4 yet. Maybe it's sync script only runs once a week or so.

Hmm.. the mirror ftp page is suppose to check that the site has rsynced
in the last 48 hours, perhaps a bug in the rsync parsing script?

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

just looking at the rsyncd.conf file on svr1 itself, is the following a
valid address:

hosts allow = \
114.73.139.66.in-addr.arpa, \

On Wed, 6 Aug 2003, Robert Treat wrote:

On Wed, 2003-08-06 at 11:17, scott.marlowe wrote:

On 6 Aug 2003, Robert Treat wrote:

On Tue, 2003-08-05 at 20:18, Dann Corbit wrote:

For me, I can only find these directories:
ftp://ftp8.us.postgresql.org/pub/pgsql/source/v7.4/
ftp://ftp8.us.postgresql.org/pub/postgresql/source/v7.4/
And both of them are empty.

Might be some lag in that mirror synching; try
ftp://ftp3.us.postgresql.org/pub/postgresql/source/v7.4/

I just checked, and out of the 6 listed US mirrors, all but ftp8 and
ftp15 are updated. ftp15 seems more out of sync than ftp8, as it doesn't
even have 7.3.4 yet. Maybe it's sync script only runs once a week or so.

Hmm.. the mirror ftp page is suppose to check that the site has rsynced
in the last 48 hours, perhaps a bug in the rsync parsing script?

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

On Wed, Aug 06, 2003 at 13:40:29 -0300,
The Hermit Hacker <scrappy@postgresql.org> wrote:

just looking at the rsyncd.conf file on svr1 itself, is the following a
valid address:

hosts allow = \
114.73.139.66.in-addr.arpa, \

You could have an A record with a domain name using the typical format
used for PTR records. However in this case there is no A record for
114.73.139.66.in-addr.arpa. The ptr record points to doodah.gremlins.biz.
There is an a record for doodah.gremlins.biz which lists 66.139.73.114,
which matches the original ptr record.

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.

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

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