beta5 ...

The Hermit Hacker <scrappy@hub.org> writes:

things appear to have quieted off nicely ... so would like to put out a
Beta5 for testing ...

Tom, I saw/read your proposal about the JOIN syntax, but haven't seen any
commit on it yet, nor any arguments against the changes ... so just
wondering where those stand right now?

You must have been looking the other way ;-) ... it's committed.

What I'm currently thinking about is the discussion from last week where
Vadim reported that he could get "stuck spinlock" errors during btree
index crash recovery, because the backend fixing the index might hold
disk-buffer locks longer than the ~70 second timeout for spinlocks
(see "Btree runtime recovery. Stuck spins" thread on 2/8 and 2/9).

Vadim says (and I agree) that we really ought to implement a new
lightweight lock manager that would fall between spinlocks and regular
locks in terms of overhead and functionality. But it's not reasonable
to try to do that for 7.1 at this late date. So I was trying to pick a
stopgap solution for 7.1. Unfortunately Vadim's off to Siberia and I
can't consult with him...

I'm currently thinking of modifying the buffer manager so that disk
buffer spinlocks use an alternate version of s_lock() with no timeout,
and perhaps longer sleeps (no zero-delay selects anyway). This was one
of the ideas we kicked around last week, and I think it's about the best
we can do for now. Comments anyone?

Other than that, I have nothing to hold up a beta5. Anyone else?

regards, tom lane

I am GO. SET DIAGNOSTICS is my only open item left.

The Hermit Hacker <scrappy@hub.org> writes:

things appear to have quieted off nicely ... so would like to put out a
Beta5 for testing ...

Tom, I saw/read your proposal about the JOIN syntax, but haven't seen any
commit on it yet, nor any arguments against the changes ... so just
wondering where those stand right now?

You must have been looking the other way ;-) ... it's committed.

What I'm currently thinking about is the discussion from last week where
Vadim reported that he could get "stuck spinlock" errors during btree
index crash recovery, because the backend fixing the index might hold
disk-buffer locks longer than the ~70 second timeout for spinlocks
(see "Btree runtime recovery. Stuck spins" thread on 2/8 and 2/9).

Vadim says (and I agree) that we really ought to implement a new
lightweight lock manager that would fall between spinlocks and regular
locks in terms of overhead and functionality. But it's not reasonable
to try to do that for 7.1 at this late date. So I was trying to pick a
stopgap solution for 7.1. Unfortunately Vadim's off to Siberia and I
can't consult with him...

I'm currently thinking of modifying the buffer manager so that disk
buffer spinlocks use an alternate version of s_lock() with no timeout,
and perhaps longer sleeps (no zero-delay selects anyway). This was one
of the ideas we kicked around last week, and I think it's about the best
we can do for now. Comments anyone?

Other than that, I have nothing to hold up a beta5. Anyone else?

regards, tom lane

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

At 04:17 PM 2/16/01 -0500, Tom Lane wrote:

Vadim says (and I agree) that we really ought to implement a new
lightweight lock manager that would fall between spinlocks and regular
locks in terms of overhead and functionality. But it's not reasonable

Will there be an arbitrary user locking feature? E.g. lock on arbitrary
text string. That would be great :).

BTW, is 7.1 going to be a bit slower than 7.0? Or just Beta 5? Just
curious. Don't mind waiting for 7.2 for the speed-up if necessary.

Cheerio,
Link.

BTW, is 7.1 going to be a bit slower than 7.0? Or just Beta 5? Just
curious. Don't mind waiting for 7.2 for the speed-up if necessary.

We expect 7.1 to be faster than 7.0.X. We may have a small problem that
we may have to address. Not sure yet.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

On Sat, 17 Feb 2001, Lincoln Yeoh wrote:

At 04:17 PM 2/16/01 -0500, Tom Lane wrote:

Vadim says (and I agree) that we really ought to implement a new
lightweight lock manager that would fall between spinlocks and regular
locks in terms of overhead and functionality. But it's not reasonable

Will there be an arbitrary user locking feature? E.g. lock on arbitrary
text string. That would be great :).

BTW, is 7.1 going to be a bit slower than 7.0? Or just Beta 5? Just
curious. Don't mind waiting for 7.2 for the speed-up if necessary.

It is possible that it will be ... the question is whether the slow down
is unbearable or not, as to whether we'll let it hold things up or not ...

From reading one of Tom's email's, it looks like the changes to 'fix' the
slowdown are drastic/large enough that it might not be safe (or desirable)
to fix it at this late of a stage in beta ...

Depending on what is involved, we might put out a v7.1 for March 1st, so
that ppl can feel confident about using the various features, but have a
v7.1.1 that follows relatively closely on its heels that addresses the
performance problem ...

Other than that, I have nothing to hold up a beta5. Anyone else?

regards, tom lane

I see a small problem with the regression test. If PL/pgSQL has been
already to template1, the regression scripts will fail because
createlang fails. Probably we should create the regression database
using template0?
--
Tatsuo Ishii

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

Probably we should create the regression database
using template0?

Seems like a good idea.

regards, tom lane

BTW, is 7.1 going to be a bit slower than 7.0? Or just Beta 5? Just
curious. Don't mind waiting for 7.2 for the speed-up if necessary.

It is possible that it will be ... the question is whether the slow down
is unbearable or not, as to whether we'll let it hold things up or not ...

From reading one of Tom's email's, it looks like the changes to 'fix' the

slowdown are drastic/large enough that it might not be safe (or desirable)
to fix it at this late of a stage in beta ...

Depending on what is involved, we might put out a v7.1 for March 1st, so
that ppl can feel confident about using the various features, but have a
v7.1.1 that follows relatively closely on its heels that addresses the
performance problem ...

The easy fix is to just set the delay to zero. Looks like that will fix
most of the problem. The near-committers thing may indeed be overkill,
and certainly is not worth holding beta.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

On Sat, 17 Feb 2001, Bruce Momjian wrote:

BTW, is 7.1 going to be a bit slower than 7.0? Or just Beta 5? Just
curious. Don't mind waiting for 7.2 for the speed-up if necessary.

It is possible that it will be ... the question is whether the slow down
is unbearable or not, as to whether we'll let it hold things up or not ...

From reading one of Tom's email's, it looks like the changes to 'fix' the

slowdown are drastic/large enough that it might not be safe (or desirable)
to fix it at this late of a stage in beta ...

Depending on what is involved, we might put out a v7.1 for March 1st, so
that ppl can feel confident about using the various features, but have a
v7.1.1 that follows relatively closely on its heels that addresses the
performance problem ...

The easy fix is to just set the delay to zero. Looks like that will fix
most of the problem.

Except that Vadim had a reason for setting it to 5, and I'm loath to see
that changed unless someone actaully understands the ramifications other
then increasing performance ...

The near-committers thing may indeed be overkill, and certainly is not
worth holding beta.

What is this 'near-committers thing'??

The Hermit Hacker <scrappy@hub.org> writes:

The easy fix is to just set the delay to zero. Looks like that will fix
most of the problem.

Except that Vadim had a reason for setting it to 5,

He claimed to have seen better performance with a nonzero delay.
So far none of the rest of us have been able to duplicate that.
Perhaps he was using a machine where a 5-microsecond select() delay
actually is 5 microseconds? If so, he's the outlier, not the
rest of us ...

regards, tom lane

The easy fix is to just set the delay to zero. Looks like that will fix
most of the problem.

Except that Vadim had a reason for setting it to 5, and I'm loath to see
that changed unless someone actaully understands the ramifications other
then increasing performance ...

See post from a few minutes ago with analysis of purpose and actual
affect of Vadim's parameter. I objected to the delay when it was
introduced because of my analysis, but Vadim's argument is that 5
microseconds is very small delay, just enough to yield the CPU. We now
see that is much longer than that.

The near-committers thing may indeed be overkill, and certainly is not
worth holding beta.

What is this 'near-committers thing'??

Other backends about to commit.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

I see a small problem with the regression test. If PL/pgSQL has been
already to template1, the regression scripts will fail because
createlang fails. Probably we should create the regression database
using template0?

Done ...

regards, tom lane

The Hermit Hacker <scrappy@hub.org> writes:

things appear to have quieted off nicely ... so would like to put out a
Beta5 for testing ...

Unless Peter E. has some more commits up his sleeve, I think we're
good to go.

regards, tom lane

Tom Lane writes:

The Hermit Hacker <scrappy@hub.org> writes:

things appear to have quieted off nicely ... so would like to put out a
Beta5 for testing ...

Unless Peter E. has some more commits up his sleeve, I think we're
good to go.

Just uploaded freshly baked man pages, including your createdb change.
That'd be it.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

On Sun, 18 Feb 2001, Tom Lane wrote:

The Hermit Hacker <scrappy@hub.org> writes:

things appear to have quieted off nicely ... so would like to put out a
Beta5 for testing ...

Unless Peter E. has some more commits up his sleeve, I think we're
good to go.

okay, I'll put one out Mon aft, just in case of any strays that come up
tonight, or any final commits from our overseas committers ...

thanks ;:)

The easy fix is to just set the delay to zero. Looks like that will fix
most of the problem.

Except that Vadim had a reason for setting it to 5, and I'm loath to see
that changed unless someone actaully understands the ramifications other
then increasing performance ...

Vadim originally intended 5 milliseconds, he only read the parameter wrong.
Then noticing, that the parameter is actually microseconds, he iirc decided to
leave it as is because the discussion at that time seemed to lead to the conclusion,
that a simple yield would be optimal in lack of some sort of detection, and
the select with 5 us seemed closest to that.

At least on AIX it looks like the select with 0 timeout is a noop, and does not
yield the processor. There was discussion, that other OS's (BSD) also does an
immediate return in case of 0 timeout.

Minimum select(2) delay is 1 msec on AIX (tested with Tom's test.c).

So, what was the case against using yield (2) ?

Andreas

Quoting The Hermit Hacker <scrappy@hub.org>:

On Sun, 18 Feb 2001, Tom Lane wrote:

The Hermit Hacker <scrappy@hub.org> writes:

things appear to have quieted off nicely ... so would like to put

out a

Beta5 for testing ...

Unless Peter E. has some more commits up his sleeve, I think we're
good to go.

okay, I'll put one out Mon aft, just in case of any strays that come up
tonight, or any final commits from our overseas committers ...

I'm not planning on doing any until after Beta5 is out ;-)

Peter

thanks ;:)

--
Peter Mount peter@retep.org.uk
PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/
RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/

At least on AIX it looks like the select with 0 timeout is a noop, and does not
yield the processor. There was discussion, that other OS's (BSD) also does an
immediate return in case of 0 timeout.

Minimum select(2) delay is 1 msec on AIX (tested with Tom's test.c).

So, what was the case against using yield (2) ?

BSDi doesn't have yield(). It does have sched_yield(), but that
controls threads:

force the current pthread to be rescheduled

so there doesn't seem to be any portable way to do this. Sleeps of zero
do no kernel call, and sleeps > 0 sleep for a minimum of one tick.

If you really want a near-zero sleep, you need to do a no-op kernel
call, like umask(), but doing a simple kernel call usually is not enough
because kernels usually favor the last-running process because of the
CPU cache. We need a "try to schedule someone else if they are ready to
run, if not, return right away" call.

I think ultimately, we need the type of near-committers feedback, but
not for 7.1.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:

So, what was the case against using yield (2) ?

$ man 2 yield
No entry for yield in section 2 of the manual.

Lack of portability :-(

regards, tom lane

So, what was the case against using yield (2) ?

$ man 2 yield
No entry for yield in section 2 of the manual.

Lack of portability :-(

I can't beleive that AIX finally has a convenience function that
is missing in mainstream unix :-)

$man 2 yield
Purpose
Yields the processor to processes with higher priorities.
Description
The yield subroutine forces the current running process or thread to relinquish
use of the processor. If the run queue is empty when the yield subroutine is
called, the calling process or kernel thread is immediately rescheduled. If the
calling process has multiple threads, only the calling thread is affected. The
process or thread resumes execution after all threads of equal or greater
priority are scheduled to run.

Andreas

I can't beleive that AIX finally has a convenience function that
is missing in mainstream unix :-)

Better not report it; they'll take it out ;)

- Thomas

Hi all,

As a matter of curiosity, is each beta compiled and then regression
tested against *every* one of the known "supported" platforms before
release?

Like, as an official "checklist" type step?

Regards and best wishes,

Justin Clift
Database Administrator

As a matter of curiosity, is each beta compiled and then regression
tested against *every* one of the known "supported" platforms before
release?

No. But the changes from beta to beta are usually done with platform
compatibility in mind, and we try to stay away from introducing
platform-specific breakage.

We *do* make a great effort to solicit regression tests on all supported
platforms between first beta and final release, with an explicit push
during the last beta cycle, just before docs freeze for the release.
This is easy for the common platforms, and we have been fortunate that
the more exotic platforms have usually had an interested supporter to
run the tests and report results.

Lack of reported regression tests for a release or two is sufficient
cause to drop a platform to the "unsupported" list. We don't remove the
platform from all lists to help remind us that the platform *could* be
supported, and once was, in case someone wants to rehabilitate its
status.

- Thomas

As a matter of curiosity, is each beta compiled and then regression
tested against *every* one of the known "supported" platforms before
release?

Who are you expecting to do that, exactly?

One of the differences between Postgres and a proprietary commercial
database is that there is no vast support machinery behind the scenes.
What you see going on on this list is what you get: beta testing
consists of the activities performed and reported by list members.

Normally, if we are about to push out a beta then two or three people
will double-check that the current CVS tip builds and passes regression
on their personal machines. But the "supported platforms" coverage
depicted in the docs consists of all the platforms that are reported to
us as working during the entire beta test period, including many that
the key developers have no direct access to. There's no way that we
could reverse the process and cause that to happen before a beta release
instead of after; certainly no way that we could cause all that effort
to be repeated for each beta version.

If you are using a beta version then you are part of that testing
process, not a beneficiary of something that's happened behind closed
doors.

regards, tom lane

Would there be any value in setting up a project on sourceforge to make use
of their compile farm? I know that it doesn't cover all platforms, but it
would perhaps be a start to mechanical compile and regression testing.

Just a thought...

MikeA

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 20 February 2001 15:51
To: Justin Clift
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] beta5 ...

As a matter of curiosity, is each beta compiled and then regression
tested against *every* one of the known "supported" platforms before
release?

Who are you expecting to do that, exactly?

One of the differences between Postgres and a proprietary commercial
database is that there is no vast support machinery behind the scenes.
What you see going on on this list is what you get: beta testing
consists of the activities performed and reported by list members.

Normally, if we are about to push out a beta then two or three people
will double-check that the current CVS tip builds and passes regression
on their personal machines. But the "supported platforms" coverage
depicted in the docs consists of all the platforms that are reported to
us as working during the entire beta test period, including many that
the key developers have no direct access to. There's no way that we
could reverse the process and cause that to happen before a beta release
instead of after; certainly no way that we could cause all that effort
to be repeated for each beta version.

If you are using a beta version then you are part of that testing
process, not a beneficiary of something that's happened behind closed
doors.

regards, tom lane

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
Nick West - Global Infrastructure Manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Would there be any value in setting up a project on sourceforge to
make use of their compile farm? I know that it doesn't cover all
platforms, but it would perhaps be a start to mechanical compile and
regression testing.

I haven't looked at the platforms available in the compile farm
recently, but afaik regression coverage for over half a dozen platforms
already happens without (extra) effort: Tom Lane has three or more
platforms, I've got Linux, Bruce has BSDI, Marc has FreeBSD, we have
some active W32 developers, etc etc.

What would SF add to this mix?

- Thomas

* Thomas Lockhart <lockhart@alumni.caltech.edu> [010220 10:51]:

Would there be any value in setting up a project on sourceforge to
make use of their compile farm? I know that it doesn't cover all
platforms, but it would perhaps be a start to mechanical compile and
regression testing.

I haven't looked at the platforms available in the compile farm
recently, but afaik regression coverage for over half a dozen platforms
already happens without (extra) effort: Tom Lane has three or more
platforms, I've got Linux, Bruce has BSDI, Marc has FreeBSD, we have
some active W32 developers, etc etc.

I have a UnixWare 7.1.1 box I run PG on....

What would SF add to this mix?

- Thomas

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Would there be any value in setting up a project on sourceforge to
make use of their compile farm? I know that it doesn't cover all
platforms, but it would perhaps be a start to mechanical compile and
regression testing.

I haven't looked at the platforms available in the compile farm
recently, but afaik regression coverage for over half a dozen platforms
already happens without (extra) effort: Tom Lane has three or more
platforms, I've got Linux, Bruce has BSDI, Marc has FreeBSD, we have
some active W32 developers, etc etc.

I run HPUX and Linux/PPC routinely, so that's only two here. Still, we
have reasonable coverage among the core team and a bunch more platforms
used by active pgsql-hackers people. Also, the project does have an
Alpha in-house at hub.org (if Marc ever gets it back into commission
after that failed OS reinstall...)

What would SF add to this mix?

The current list of machines at cf.sourceforge.net seems to be

lqqqqqqqChoose compile farm server...qqqqqqqk
x A. [x86] Linux 2.2 (Debian 2.2) x
x C. [x86] FreeBSD (4.2-stable) x
x x
x G. [Alpha] Compaq Tru64 (5.1) x
x H. [Alpha] Linux 2.2 (RedHat 7.0) x
x x
x L. [Sparc - E240] Linux 2.2 (Debian 2.2) x
x M. [Sparc - E240] Sun Solaris (8) x
x x
x Exit x
mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj

I think I'll go try a build on that Solaris 8 machine, since we've heard
some reports of problems on Solaris. However, I'm not sure that we need
any organized use of their compilefarm. If they made it easy to
*automatically* run build/install/regress test on multiple machines,
I could see the facility being useful (especially so once a few more
platforms are offered). But right now it looks like it's just shell
access to platforms other than your own, which is not going to help us
all that much.

regards, tom lane

I was just thinking that perhaps as part of the "beta" release process
it would be worthwhile saying "New beta about to be released" (or
similar) and then have the appropriate people for each platform/OS do a
compile against the up-to-the-minute CVS and give a yes/no for each of
their platforms.

In a way, this seems to be done presently, but without the addition of a
formalised checklist of "platforms this beta compiles/regress-tests on
as of release time".

I'm thinking about the release process.

+ Justin

Tom Lane wrote:

As well as Linux I run Solaris 8 SPARC (32-bit not 64), Solaris 7 SPARC
(SMP, 32-bit not 64), Solaris 7 Intel (both SMP and uni-processor) and
Solaris 8 Intel (both SMP and uni-processor).

I can be counted on to do testing of these as required in about 2 weeks
from now, after I get a new permanent connection here.

With luck I'll additionally have the finances to buy some SPARC 64-bit
machines in a few months.

Regards and best wishes,

Justin Clift
Database Administrator

Tom Lane wrote:

Justin Clift wrote:

I was just thinking that perhaps as part of the "beta" release process
it would be worthwhile saying "New beta about to be released" (or
similar) and then have the appropriate people for each platform/OS do a
compile against the up-to-the-minute CVS and give a yes/no for each of
their platforms.

What would the big advantage to releasing the beta and testing _that_ be
?

Apart from delaying the beta, that is ;) ?

It would be nice if someone (pgsql inc., great bridge, etc.) provided a
central web page for registering the results so that you won't need to
scan athe whole list to find out if your platform is already tested.

----------
Hannu

Vince, is this something that PostgreSQL.Org can have on the web page
relatively quickly?

On Wed, 21 Feb 2001, Hannu Krosing wrote:

Justin Clift wrote:

I was just thinking that perhaps as part of the "beta" release process
it would be worthwhile saying "New beta about to be released" (or
similar) and then have the appropriate people for each platform/OS do a
compile against the up-to-the-minute CVS and give a yes/no for each of
their platforms.

What would the big advantage to releasing the beta and testing _that_ be
?

Apart from delaying the beta, that is ;) ?

It would be nice if someone (pgsql inc., great bridge, etc.) provided a
central web page for registering the results so that you won't need to
scan athe whole list to find out if your platform is already tested.

----------
Hannu

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

On Wed, 21 Feb 2001, Tom Lane wrote:

The Hermit Hacker <scrappy@hub.org> writes:

Vince, is this something that PostgreSQL.Org can have on the web page
relatively quickly?

On Wed, 21 Feb 2001, Hannu Krosing wrote:

It would be nice if someone (pgsql inc., great bridge, etc.) provided a
central web page for registering the results so that you won't need to
scan athe whole list to find out if your platform is already tested.

Sounded like a great idea to me too. If Vince doesn't want to mess with
it, I'll try to stir up some interest at Great Bridge.

Something like this, I think, is more appropriate on the project site,
that's all ...

The Hermit Hacker <scrappy@hub.org> writes:

Vince, is this something that PostgreSQL.Org can have on the web page
relatively quickly?

On Wed, 21 Feb 2001, Hannu Krosing wrote:

It would be nice if someone (pgsql inc., great bridge, etc.) provided a
central web page for registering the results so that you won't need to
scan athe whole list to find out if your platform is already tested.

Sounded like a great idea to me too. If Vince doesn't want to mess with
it, I'll try to stir up some interest at Great Bridge.

regards, tom lane

Hannu Krosing writes:

It would be nice if someone (pgsql inc., great bridge, etc.) provided a
central web page for registering the results so that you won't need to
scan athe whole list to find out if your platform is already tested.

"Platform already tested" is a misguided concept. Almost any machine is
customized or deviating in some form or other. A listing of the form

beta1 beta2 ...
Linux ok ok
Solaris ok broken
...

is, IMHO, worse than useless, because it would actually decrease the
amount of wide-spread, diverse testing.

I wouldn't mind an automated process that builds and runs the test suite
regularly on many machines to inform developers during the development
cycle that they broke something really bad, but to make this part of the
beta testing process is sheer folly.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Peter Eisentraut wrote:

Hannu Krosing writes:

It would be nice if someone (pgsql inc., great bridge, etc.) provided a
central web page for registering the results so that you won't need to
scan athe whole list to find out if your platform is already tested.

"Platform already tested" is a misguided concept. Almost any machine is
customized or deviating in some form or other. A listing of the form

beta1 beta2 ...
Linux ok ok
Solaris ok broken
...

is, IMHO, worse than useless, because it would actually decrease the
amount of wide-spread, diverse testing.

It goes even further than that, of course -- there are different
versions to worry about. As a hypothetical, suppose for a moment that
PostgreSQL works fine on a Linux 2.2.17 box with glibc 2.1.3, but does
not work fine on Linux 2.4.1 with glibc 2.2 due to some undocumented
change to strncmp() (;-)). Currently, we're not that fine-grained --
while regression results are useful for ascertaining what is and isn't
supported, the regression results are very dependent on the environment
of the machine.

Any process that would discourage widespread testing is not good, IMHO.

Having a form by which you could register pass/fail/diffs for your
particular platform/environment could be good, with a blank slate each
release. But a blanket 'we support Linux' is, IMHO, not good -- _which_
Linux? 1.0? 1.2? 2.0? 2.0.38 but not 2.0.15? With libc 4 in a.out? Or
do you have to have ELF Libc 5? Libc 5.2.38 works, but 5.4.44 doesn't?
Glibc 2.0.5 but not 2.1.3? RedHat kernel 2.2.17 but not SuSE kernel
2.2.17? And, the worst: RedHat kernel 2.2.18 for RedHat 7 versus RedHat
kernel 2.2.18 for RedHat 6.2 (the kernel patches applied could in fact
be different enough to matter)?

These are all hypothetical examples, of course -- but Linux is not the
only platform that has these versioning problems just waiting to bite.
Linux probably has more of them than most, but it is not alone in having
them.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Wed, 21 Feb 2001, The Hermit Hacker wrote:

Vince, is this something that PostgreSQL.Org can have on the web page
relatively quickly?

The beta or registering the results? After the last time I won't
put beta releases on the website, but if you want the results thing
it can be done in a short time. Just tell me what info you want
in it and it'll be there.

Vince.

On Wed, 21 Feb 2001, Hannu Krosing wrote:

Justin Clift wrote:

I was just thinking that perhaps as part of the "beta" release process
it would be worthwhile saying "New beta about to be released" (or
similar) and then have the appropriate people for each platform/OS do a
compile against the up-to-the-minute CVS and give a yes/no for each of
their platforms.

What would the big advantage to releasing the beta and testing _that_ be
?

Apart from delaying the beta, that is ;) ?

It would be nice if someone (pgsql inc., great bridge, etc.) provided a
central web page for registering the results so that you won't need to
scan athe whole list to find out if your platform is already tested.

----------
Hannu

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

--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

On Wed, 21 Feb 2001, Vince Vielhaber wrote:

On Wed, 21 Feb 2001, The Hermit Hacker wrote:

Vince, is this something that PostgreSQL.Org can have on the web page
relatively quickly?

The beta or registering the results? After the last time I won't
put beta releases on the website, but if you want the results thing
it can be done in a short time. Just tell me what info you want
in it and it'll be there.

Hrmmm ... some sort of input form where someone can enter OS specific
info, and maybe upload the results of the regression tests as far as
'failed' or 'succeeded'? the report generated would list the OS info and
x out of y tests failed ... and a link to a full listing of which
failed/succeeded?

Vince.

On Wed, 21 Feb 2001, Hannu Krosing wrote:

Justin Clift wrote:

I was just thinking that perhaps as part of the "beta" release process
it would be worthwhile saying "New beta about to be released" (or
similar) and then have the appropriate people for each platform/OS do a
compile against the up-to-the-minute CVS and give a yes/no for each of
their platforms.

What would the big advantage to releasing the beta and testing _that_ be
?

Apart from delaying the beta, that is ;) ?

It would be nice if someone (pgsql inc., great bridge, etc.) provided a
central web page for registering the results so that you won't need to
scan athe whole list to find out if your platform is already tested.

----------
Hannu

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

--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

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

I have a bunch of machines here, some are rather old (K6-200s,P133s, some
486s etc) but they're just collecting dust now. I would be more than happy
to install any OS and do build testing for PostgreSQL is there is a need..

What OSes need to have PostgreSQL built/tested on that the developers don't
have access to? If I can get the OS (and install it), I would be happy to
dedicate those machines to PG build testing.. I could set them up on the
network here (proxy, cable modem) or at the office (T1) and give developers
access if needed too.

I have several FreeBSD boxes running PG beta 4 now, but I'd bet at least one
of you is using FreeBSD (and it compiles and installs rather nicely
anyway)..

-Mitch

On Wed, 21 Feb 2001, The Hermit Hacker wrote:

On Wed, 21 Feb 2001, Vince Vielhaber wrote:

On Wed, 21 Feb 2001, The Hermit Hacker wrote:

Vince, is this something that PostgreSQL.Org can have on the web page
relatively quickly?

The beta or registering the results? After the last time I won't
put beta releases on the website, but if you want the results thing
it can be done in a short time. Just tell me what info you want
in it and it'll be there.

Hrmmm ... some sort of input form where someone can enter OS specific
info, and maybe upload the results of the regression tests as far as
'failed' or 'succeeded'? the report generated would list the OS info and
x out of y tests failed ... and a link to a full listing of which
failed/succeeded?

Lemme see what I can cobble together taking into consideration some of
the things Lamar and Peter also mentioned. Note: I'm probably 450
messagees behind due to a 2 day dsl outage; I may have missed some of
the conversation. Some messages trickled in, the rest flooded in over
night. I may be nearing the time for incoming mail folders :)

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

Vince Vielhaber wrote:

the things Lamar and Peter also mentioned. Note: I'm probably 450
messagees behind due to a 2 day dsl outage; I may have missed some of
the conversation. Some messages trickled in, the rest flooded in over
night. I may be nearing the time for incoming mail folders :)

Join the club. I have just finished configuring my Netscape e-mail for
incoming folders -- _important_ direct e-mails (having to to with my
actual job) were getting lost in and amongst the various lists I am a
member of. I get around 600 e-mails per day on fifteen or so different
mailing lists (the ones at PostgreSQL.org, a half dozen at
Broadcast.net, Bugtraq/Linux-alert/RedHat-announce, redhat-beta,
AOLserver/OpenNSD/OpenACS, and a handful of Linux announce lists,
unixODBC, CERT, plus all of our Internet listeners). Netscapes filters
are a lifesaver! Of course, there are other more capable packages out
there, but Netscape works the same on Win9x and Linux, both of which are
in use on my notebook.

I have to keep up, or the e-mail flood after a couple of days is just
about unbearable.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

* Lamar Owen <lamar.owen@wgcr.org> [010221 16:36]:

Vince Vielhaber wrote:

the things Lamar and Peter also mentioned. Note: I'm probably 450
messagees behind due to a 2 day dsl outage; I may have missed some of
the conversation. Some messages trickled in, the rest flooded in over
night. I may be nearing the time for incoming mail folders :)

Join the club. I have just finished configuring my Netscape e-mail for
incoming folders -- _important_ direct e-mails (having to to with my
actual job) were getting lost in and amongst the various lists I am a
member of. I get around 600 e-mails per day on fifteen or so different
mailing lists (the ones at PostgreSQL.org, a half dozen at
Broadcast.net, Bugtraq/Linux-alert/RedHat-announce, redhat-beta,
AOLserver/OpenNSD/OpenACS, and a handful of Linux announce lists,
unixODBC, CERT, plus all of our Internet listeners). Netscapes filters
are a lifesaver! Of course, there are other more capable packages out
there, but Netscape works the same on Win9x and Linux, both of which are
in use on my notebook.

I have to keep up, or the e-mail flood after a couple of days is just
about unbearable.

slocal/procmail/mutt on a Unix Box makes it easier.

My Mailing list stuff gets filtered off.

LER

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

On Wed, 21 Feb 2001, The Hermit Hacker wrote:

On Wed, 21 Feb 2001, Vince Vielhaber wrote:

On Wed, 21 Feb 2001, The Hermit Hacker wrote:

Vince, is this something that PostgreSQL.Org can have on the web page
relatively quickly?

The beta or registering the results? After the last time I won't
put beta releases on the website, but if you want the results thing
it can be done in a short time. Just tell me what info you want
in it and it'll be there.

Hrmmm ... some sort of input form where someone can enter OS specific
info, and maybe upload the results of the regression tests as far as
'failed' or 'succeeded'? the report generated would list the OS info and
x out of y tests failed ... and a link to a full listing of which
failed/succeeded?

http://hub.org/~vev/regress.php

What other info is needed to distinguish these systems?

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

Hi Vince,

That's really nifty.

I don't know how to word it, but I think it might be worth including
something to find out if the machine was "out-of-the box" with just the
recommended installation utils (i.e. a "new build" of AIX, NT, Solaris,
etc, then gcc, bison or whatever) vs. a machine that has been actively
used/developed with for a while.

This is so we can accurately know if a particular version/beta of
PostgreSQL compiles on a stock(-ish) system or if the successful/failed
reports are only coming from those machines with updated/newer/different
things added.

Regards and best wishes,

Justin Clift
Database Administrator

Vince Vielhaber wrote:

<snip>

What about adding a field where they paste the output of 'uname -a' on their
system...?

Chris

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Justin Clift
Sent: Thursday, February 22, 2001 12:52 PM
To: Vince Vielhaber
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] beta5 ...

Hi Vince,

That's really nifty.

I don't know how to word it, but I think it might be worth including
something to find out if the machine was "out-of-the box" with just the
recommended installation utils (i.e. a "new build" of AIX, NT, Solaris,
etc, then gcc, bison or whatever) vs. a machine that has been actively
used/developed with for a while.

This is so we can accurately know if a particular version/beta of
PostgreSQL compiles on a stock(-ish) system or if the successful/failed
reports are only coming from those machines with updated/newer/different
things added.

Regards and best wishes,

Justin Clift
Database Administrator

Vince Vielhaber wrote:

<snip>

http://hub.org/~vev/regress.php

What other info is needed to distinguish these systems?

Vince.
--

==========================================================================

Vince Vielhaber -- KA8CSH email: vev@michvhf.com

http://www.pop4.net

On Thu, 22 Feb 2001, Christopher Kings-Lynne wrote:

What about adding a field where they paste the output of 'uname -a' on their
system...?

Got this and Justin's changes along with compiler version. Anyone think
of anything else?

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

Vince Vielhaber writes:

On Thu, 22 Feb 2001, Christopher Kings-Lynne wrote:

What about adding a field where they paste the output of 'uname
-a' on their system...?

Got this and Justin's changes along with compiler version. Anyone
think of anything else?

Architecture. IRIX, Solaris and AIX allow applications and libraries
to be built 32 or 64 bit.

You may also like to add a field for configure options used. Or is
this just for results OOTB?
--
Pete Forman -./\.- Disclaimer: This post is originated
WesternGeco -./\.- by myself and does not represent
pete.forman@westerngeco.com -./\.- opinion of Schlumberger, Baker
http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.

Vince Vielhaber writes:

http://hub.org/~vev/regress.php

What other info is needed to distinguish these systems?

The operating systems should be ordered by some key other than maybe
author's preference. ;-)

Linux needs to be split into one for each distribution.

'Sun' should probably be SunOS.

Also of interest:

- config.guess output

- Linker version

- GNU make version

- configure command line (`pg_config --configure`)

Bison version is probably not interesting, since anything but 1.28 is not
to be considered serious.

'Platform' could be better named 'CPU type'. 'CPU speed' and 'Total RAM'
are probably not interesting for anything but statistics.

'libc' version is probably not interesting for anything but Linux? If
so, it is already implied if you name the distributor.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Got this and Justin's changes along with compiler version. Anyone think
of anything else?

Hmm. Any suggestions on how we collate the test results for our release
docs? And how we solicit tests for remaining platforms?

In previous releases (and until now), I have kept track of results
posted on the -hackers mailing list, and then when the beta cycle winds
down would send out a list containing those platforms which have not yet
been tested.

It was easy for me to do, and it gave visibility on the developers' list
for the current status of testing.

Should the procedure now change? And if so, have we just signed me up
for more work rummaging around a web page to transcribe results? :/

Could we perhaps have a reference on that page to the current
developer's doc page of "supported platforms"? That would help tie the
current state of the docs to the current state of the web site report
form, and it would let people know that they might also post their
results to the -hackers list to make sure that their results are known
to others. If we are storing this stuff in a database, then perhaps it
would be easy to dump those results in a form which maps into the docs?

<philosophy style=randomthought mode=aside>
I *know* that having web pages for data entry, etc etc are good things.
But at some point, the fun of working on PG is (at least for me)
interacting with *people*, not web sites, and I'd like to avoid building
in procedures which inadvertently discourage that interaction.
</philosophy>

Suggestions?

- Thomas

On Thu, 22 Feb 2001, Pete Forman wrote:

Vince Vielhaber writes:

On Thu, 22 Feb 2001, Christopher Kings-Lynne wrote:

What about adding a field where they paste the output of 'uname
-a' on their system...?

Got this and Justin's changes along with compiler version. Anyone
think of anything else?

Architecture. IRIX, Solaris and AIX allow applications and libraries
to be built 32 or 64 bit.

Added.

You may also like to add a field for configure options used. Or is
this just for results OOTB?

That comes later. This part is just for identifying the system itself.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

On Thu, 22 Feb 2001, Peter Eisentraut wrote:

Vince Vielhaber writes:

http://hub.org/~vev/regress.php

What other info is needed to distinguish these systems?

The operating systems should be ordered by some key other than maybe
author's preference. ;-)

Actually it's more random than by preference. FreeBSD came first 'cuze
I run it and I always list it first (and alphabetically it comes before
Linux). I then kept the bsds together, but those were actually added
last. Some of the others came from looking at the directory where the
FAQs reside and going in that order.

Linux needs to be split into one for each distribution.

I need a list of them since the only ones I can think of are redhat, suse
and slackware (does slackware even still exist?).

'Sun' should probably be SunOS.

Ok.

Also of interest:

- config.guess output

comes later. This is mainly for machine identification. But it is noted
since I didn't think of it.

- Linker version

- GNU make version

- configure command line (`pg_config --configure`)

Comes later.

Bison version is probably not interesting, since anything but 1.28 is not
to be considered serious.

'Platform' could be better named 'CPU type'. 'CPU speed' and 'Total RAM'
are probably not interesting for anything but statistics.

Changed platform.

'libc' version is probably not interesting for anything but Linux? If
so, it is already implied if you name the distributor.

And if someone upgrades libc? I add that 'cuze when a friend of mine was
using redhat for his isp (quite a while ago) someone upgraded his libc for
him - what a mess that made!

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

On Thu, 22 Feb 2001, Thomas Lockhart wrote:

Got this and Justin's changes along with compiler version. Anyone think
of anything else?

Hmm. Any suggestions on how we collate the test results for our release
docs? And how we solicit tests for remaining platforms?

In previous releases (and until now), I have kept track of results
posted on the -hackers mailing list, and then when the beta cycle winds
down would send out a list containing those platforms which have not yet
been tested.

Can you provide me with a list of platforms it should be tested on?

It was easy for me to do, and it gave visibility on the developers' list
for the current status of testing.

Should the procedure now change? And if so, have we just signed me up
for more work rummaging around a web page to transcribe results? :/

No, I wouldn't do that to you. You tell me how you want the results
to look and I'll give you copy-n-paste. All of this info will be stored
in a table so the output is however it's wanted.

Could we perhaps have a reference on that page to the current
developer's doc page of "supported platforms"? That would help tie the
current state of the docs to the current state of the web site report
form, and it would let people know that they might also post their
results to the -hackers list to make sure that their results are known
to others. If we are storing this stuff in a database, then perhaps it
would be easy to dump those results in a form which maps into the docs?

No problem.

<philosophy style=randomthought mode=aside>
I *know* that having web pages for data entry, etc etc are good things.
But at some point, the fun of working on PG is (at least for me)
interacting with *people*, not web sites, and I'd like to avoid building
in procedures which inadvertently discourage that interaction.
</philosophy>

Suggestions?

If anything this will make it easier for you and give you more time to
interact and less time to have to dig for results which may not be as
complete as you'd like.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

I think UP or SMP should be an option to check, perhaps just a box for the
number of processors. Also something to capture the compile flags. I have
a dual Ppro, and it compiles fine unless I use the -j3 or -j4 commands,
then I get an error.

Matt

Matthew writes:

I think UP or SMP should be an option to check, perhaps just a box for the
number of processors. Also something to capture the compile flags. I have
a dual Ppro, and it compiles fine unless I use the -j3 or -j4 commands,
then I get an error.

Which error?

Parallel make doesn't work when you build from a CVS tree, but it should
work with a distribution tarball.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Hi Vince,

Here's the next thing... how do you want to distinguish between Solaris
SPARC, Solaris INTEL (and maybe even Solaris MAC even though it isn't
sold any longer)? Each of these has a 32 and 64 bit mode also.

I thought that might be what "Platform" could be used for, but
"Architecture" sounds right.

Regards and best wishes,

Justin Clift
Database Administrator

Vince Vielhaber wrote:

<snip>

Can you provide me with a list of platforms it should be tested on?

The current list is at

http://www.postgresql.org/devel-corner/docs/admin/supported-platforms.html

No, I wouldn't do that to you. You tell me how you want the results
to look and I'll give you copy-n-paste. All of this info will be stored
in a table so the output is however it's wanted.

OK, if we entered in the current list of supported platforms, or even if
not, that could form the basis for the "solicitation email" to get the
rest of the platforms tested. Look at what I collate in the docs, but if
you give me more that won't be a problem.

btw, for docs I'm not sure how to include much more information, since
it has to fit on a page (in tabular form, presumably). Suggestions?

Could we perhaps have a reference on that page to the current
developer's doc page of "supported platforms"? <blah blah blah>

No problem.

Ok, the URL would be the same as above, for *development*. Not sure how
we will do the same info on the "released side" of the web site?

If anything this will make it easier for you and give you more time to
interact and less time to have to dig for results which may not be as
complete as you'd like.

Yup, you are right. Thanks.

Hmm, would generating an email to the -hackers list when something gets
updated be useful? istm it would not end up being spam, but what do
y'all think?

- Thomas