Can anyone tell me what is going on, when I get a stuck spinlock?
Is there a data corruption or anything else to worry about ?
I've found some references about spinlocks in the -hackers list,
so is that fixed with a later version than beta4 already?

Actually I was running a stack of pgbench jobs with varying commit_delay
parameter and # of clients, but it doesn't look deterministic on any of their
values. 
I've got those fatal errors, with exactly the same data several times now. 
I've restarted the postmaster as well as I've dropped the bench database and 
recreated it, but it didn't really help. That error is still coming
*sometimes*.
BTW, I think I didn't see this before, when I was running pgbench only
once from the command line, but since I use the script with the for
loop.


Some environment info:

bench=# select version();
                               version                               
---------------------------------------------------------------------
 PostgreSQL 7.1beta4 on sparc-sun-solaris2.7, compiled by GCC 2.95.1

checkpoint_timeout = 1800 # range 30-1800
commit_delay = 0 # range 0-1000
debug_level = 0 # range 0-16
fsync = false
max_connections = 100 # 1-1024
shared_buffers = 4096
sort_mem = 4096
tcpip_socket = true
wal_buffers = 128 # min 4
wal_debug = 0 # range 0-16
wal_files = 10 # range 0-64


pgbench -i -s 10 bench
...
PGOPTIONS="-c commit_delay=$del " \
        pgbench -c $cli -t 100 -n bench

Thanks,
Peter

=========

FATAL: s_lock(fcc01067) at xlog.c:2088, stuck spinlock. Aborting.

FATAL: s_lock(fcc01067) at xlog.c:2088, stuck spinlock. Aborting.
Server process (pid 7889) exited with status 6 at Mon Feb 26 09:17:36 2001
Terminating any active server processes...
NOTICE:  Message from PostgreSQL backend:
        The Postmaster has informed me that some other backend  died abnormally and possibly corr
upted shared memory.
        I have rolled back the current transaction and am       going to terminate your database 
system connection and exit.
        Please reconnect to the database system and repeat your query.
The Data Base System is in recovery mode
Server processes were terminated at Mon Feb 26 09:17:36 2001
Reinitializing shared memory and semaphores
DEBUG:  starting up
DEBUG:  database system was interrupted at 2001-02-26 09:17:33
DEBUG:  CheckPoint record at (0, 3648965776)
DEBUG:  Redo record at (0, 3648965776); Undo record at (0, 0); Shutdown FALSE
DEBUG:  NextTransactionId: 1362378; NextOid: 2362993
DEBUG:  database system was not properly shut down; automatic recovery in progress...
DEBUG:  redo starts at (0, 3648965840)
DEBUG:  ReadRecord: record with zero len at (0, 3663163376)
DEBUG:  Formatting logfile 0 seg 218 block 699 at offset 4080
DEBUG:  The last logId/logSeg is (0, 218)
DEBUG:  redo done at (0, 3663163336)

-- 
Best regards,
Peter Schindler	
   Synchronicity Inc.            |  pschindler@synchronicity.com
   http://www.synchronicity.com  |  +49 89 89 66 99 42 (Germany)

Mon, 26 Feb 2001 19:29:02 +0100
Peter Schindler <pschindler@synchronicity.com>
stuck spinlock
Peter Schindler <pschindler@synchronicity.com> writes:
> FATAL: s_lock(fcc01067) at xlog.c:2088, stuck spinlock. Aborting.

Judging from the line number, this is in CreateCheckPoint.  I'm
betting that your platform (Solaris 2.7, you said?) has the same odd
behavior that I discovered a couple days ago on HPUX: a select with
a delay of tv_sec = 0, tv_usec = 1000000 doesn't delay 1 second like
a reasonable person would expect, but fails instantly with EINVAL.
This causes the spinlock timeout in CreateCheckPoint to effectively
be only a few microseconds rather than the intended ten minutes.
So, if the postmaster happens to fire off a checkpoint process while
some regular backend is doing something with the WAL log, kaboom.

In short: please try the latest nightly snapshot (this fix is since
beta5, unfortunately) and let me know if you still see a problem.

			regards, tom lane

Mon, 26 Feb 2001 21:31:07 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: stuck spinlock 
Tom Lane wrote:
> Judging from the line number, this is in CreateCheckPoint.  I'm
> betting that your platform (Solaris 2.7, you said?) has the same odd
> behavior that I discovered a couple days ago on HPUX: a select with
> a delay of tv_sec = 0, tv_usec = 1000000 doesn't delay 1 second like
> a reasonable person would expect, but fails instantly with EINVAL.
After I finally understood what you meant, this behavior looks somehow
reasonable to me as its a struct, but I must admit, that I don't have 
to much knowledge in this area.

Anyway, after further thoughts I was curious about this odd behavior on
the different platforms and I used your previously posted program, extended
it a little bit and run it on all platforms I could get a hold of.
Please have a look at the extracted log and comments below about the different 
platforms. It seems, that this functions a "good" example of a really 
incompatible implementation across platforms, even within the same 
across different versions of the OSs.
Happy wondering ;-)


> In short: please try the latest nightly snapshot (this fix is since
> beta5, unfortunately) and let me know if you still see a problem.
I did and I didn't get the error yet, but didn't run as many jobs either.
If I get the error again, I'll post it.

Thanks for your help,
Peter

=====
Wed, 28 Feb 2001 12:05:04 +0100
Peter Schindler <pschindler@synchronicity.com>
Re: stuck spinlock
Interesting numbers --- thanks for sending them along.

Looks like I was mistaken to think that most platforms would allow
tv_usec >= 1 sec.  Ah well, another day, another bug...

			regards, tom lane

Wed, 28 Feb 2001 10:08:47 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: stuck spinlock 