Thread: regression test failure on initdb
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.
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