Current CVS parallel test lock

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>

Running latest cvs on freebsd gives me errors in test strings and test
errors, and completely hangs at this point:

I got a similar problem and system hangs randomly(esp. in test strings) in
win32-mingw. The problem I found is in pgunlink(). There is a potential
deadloop in

while (unlink(path))
{
...
}

However, if we wait long enough( I waited for 20 mins or so), the system
finally go on. I guess that's because of the hot-long-discussed "win32's
inability of removing file-in-use" problem(though FILE_SHARE_DELETE flag is
added). Shall we add a time-limit or something to handle this situation?

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:

Running latest cvs on freebsd gives me errors in test strings and test
errors, and completely hangs at this point:

Time for a clean rebuild? I've not seen any failures, neither has
the build farm ...

regards, tom lane

Time for a clean rebuild? I've not seen any failures, neither has
the build farm ...

cvs up
gmake clean
./configure --prefix=/home/chriskl/local --enable-depend --enable-debug
--enable-cassert --with-perl --with-pam --with-openssl
gmake check

Still hangs. Gets new failure in create function and constraints.
Seems to be differences in how it's indicating syntax errors.

My src/bin/psql is in the 7_4_STABLE branch, but that shouldn't affect
anything.

Chris

On Wed, Mar 09, 2005 at 03:24:20PM +0800, Christopher Kings-Lynne wrote:

gmake clean

Have you tried "gmake distclean"?

I just built the latest HEAD on FreeBSD 4.11-STABLE and all tests
passed. Configure options were:

./configure --prefix=/usr/local/pgsql81 \
--with-pgport=5481 \
--with-openssl \
--with-perl \
--with-python \
--with-tcl \
--with-tclconfig=/usr/local/lib/tcl8.4 \
--enable-debug \
--enable-cassert

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

Have you tried "gmake distclean"?

I just built the latest HEAD on FreeBSD 4.11-STABLE and all tests
passed. Configure options were:

Hrm, I just did a gmake install; gmake installcheck - that worked fine.
Then I did gmake check again and now that works fine...

It must have been picking up something from my previously installed pgsql.

Chris

On Wed, Mar 09, 2005 at 03:43:38PM +0800, Christopher Kings-Lynne wrote:

Hrm, I just did a gmake install; gmake installcheck - that worked fine.
Then I did gmake check again and now that works fine...

It must have been picking up something from my previously installed pgsql.

Do you have a way to revert to the old installation to check whether
the checks fail again? It might be useful to track down exactly
what happened. It seems wrong that a currently-installed version
should have adverse effects on a just-built version's regression
tests.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

Do you have a way to revert to the old installation to check whether
the checks fail again? It might be useful to track down exactly
what happened. It seems wrong that a currently-installed version
should have adverse effects on a just-built version's regression
tests.

No :)

Michael Fuhr <mike@fuhr.org> writes:

Do you have a way to revert to the old installation to check whether
the checks fail again? It might be useful to track down exactly
what happened. It seems wrong that a currently-installed version
should have adverse effects on a just-built version's regression
tests.

We've seen that happen many times with shared library dependencies
... but libpq hasn't changed in the last few days AFAIR.

regards, tom lane

Do you have a way to revert to the old installation to check whether
the checks fail again? It might be useful to track down exactly
what happened. It seems wrong that a currently-installed version
should have adverse effects on a just-built version's regression
tests.

We've seen that happen many times with shared library dependencies
... but libpq hasn't changed in the last few days AFAIR.

I hadn't done a gmake install for months due to being overseas...

Chris