Skip site navigation (1) Skip section navigation (2)

stuck spinlock

From: Peter Schindler <pschindler(at)synchronicity(dot)com>
To: pg-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: stuck spinlock
Date: 2001-02-26 18:29:02
Message-ID: B0021233681@tellurian.net (view raw or flat)
Thread:
Lists: pgsql-hackers
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(at)synchronicity(dot)com
   http://www.synchronicity.com  |  +49 89 89 66 99 42 (Germany)

Responses

pgsql-hackers by date

Next:From: Emmanuel CharpentierDate: 2001-02-26 19:24:01
Subject: Re: Release in 2 weeks ...
Previous:From: Zeugswetter Andreas SBDate: 2001-02-26 17:50:09
Subject: AW: CommitDelay performance improvement

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group