Howdy,

I am having a little trouble with the runcheck regression testing of the compilation that I just performed.  I am running a Linux Red-Hat 6.2 OS on an Alpha box and currently have Postgres 6.5.3 running in non-default directories and on a non-default port.  I wanted to install Postgres 7.0.2 in the default areas and convert over.  I configured the default area and compiled the new version.  Then I go to perform the runcheck regression test and it fails on the initdb step.  In the initdb.log the error that is provided is: 

FATAL: s_lock(20306f80) at spinc:116, stuck spinlock. Aborting 

This seems serious, but I have no idea where to start to fix this.  I posted the question on general and was pointed to the archives of general and hackers.  I found some references to spinlocks in hackers, regarding too many backend processes running at once and running out of kernel space...but I don't think that this is what is happening here.  When I was performing the regression test, there was only one process running to the 6.5.3 installation, and just the runcheck on the 7.0.2.  The 6.5.3 is configured to handle 34 backends and the 7.0.2 is configured to handle 64.  The box has a max of 4 MB of shared memory, which should be plenty to handle this.
 
Please point me in the right direction if you can.
 
 
Thanks!
Darrin







Howdy,I am having a little trouble with the runcheck regression 
testing of the compilation that I just performed.  I am running a Linux 
Red-Hat 6.2 OS on an Alpha box and currently have Postgres 6.5.3 running in 
non-default directories and on a non-default port.  I wanted to install 
Postgres 7.0.2 in the default areas and convert over.  I configured the 
default area and compiled the new version.  Then I go to perform the 
runcheck regression test and it fails on the initdb step.  In the 
initdb.log the error that is provided is: FATAL: s_lock(20306f80) at 
spinc:116, stuck spinlock. Aborting This seems serious, but I have no 
idea where to start to fix this.  I posted the question on general and was 
pointed to the archives of general and hackers.  I found some references to 
spinlocks in hackers, regarding too many backend processes running at once and 
running out of kernel space...but I don't think that this is what is happening 
here.  When I was performing the regression test, there was only one 
process running to the 6.5.3 installation, and just the runcheck on the 
7.0.2.  The 6.5.3 is configured to handle 34 backends and the 7.0.2 is 
configured to handle 64.  The box has a max of 4 MB of shared memory, which 
should be plenty to handle this.
 
Please point me in the right direction if you 
can.
 
 
Thanks!
Darrin
Wed, 16 Aug 2000 15:56:06 -0500
"Darrin Ladd" <dladd@newfoundcomm.net>
regression test failure on initdb
We just got a report of a successful installation on Linux/Alpha from
the current development tree. Earlier versions, including 7.0.2,
required patching. The easiest course for you to take is to install from
src or binary RPMs, which already contain the patches for Alpha boxes.
The RPMs are available on the Postgres ftp site, and Lamar Owens is just
about ready to release an update, though I'll guess that the current RPM
will work just fine for you.

7.1 should run out of the box for you, since it has a new "64-bit
friendly" function manager interface.

                  - Thomas

Thu, 17 Aug 2000 06:18:01 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: regression test failure on initdb