Thread: Re: [HACKERS] Problem in S_LOCK?

Re: [HACKERS] Problem in S_LOCK?

From
Keith Parks
Date:
Thanks Tom,

I'll try that next time I do a build.

I may also try building with some of the lock debug
stuff defined.

Keith.

"Thomas A. Szybist" <szybist@boxhill.com>
> 
> I don't know if I can help, but I'm downloading the
> latest snapshot now. I'll see if I can reproduce it.
> 
> You might want to try recompiling the spin lock file
> without optimization.  
> 
> Tom Szybist
> szybist@boxhill.com
> 
> In message <199905252124.WAA15632@mtcc.demon.co.uk>, Keith Parks writes:
> > From: Tom Lane <tgl@sss.pgh.pa.us>
> > > 
> > > Keith Parks <emkxp01@mtcc.demon.co.uk> writes:
> > > > Platform SPARC Linux 2.0.36, latest CVS.
> > > 
> > > SPARC Linux?  Didn't know there was such a thing.  You should look at
> > 
> > It's been around for a while and is very good.
> > 
> > > the machine-dependent assembly coding in s_lock.h and s_lock.c.  Perhaps
> > > the #ifdefs are messed up such that the wrong bit of code is being
> > > selected for your platform.  (We do have spinlock code for SPARC, IIRC,
> > > but I wonder whether it gets selected if the platform name is linux ...)
> > 
> > We appear to have spinlock on this platform and it looks like it works,
> > see below.
> > 
> > > 
> > > If the failure just started appearing recently then this probably ain't
> > > the answer :-(
> > 
> > It's the 1st time I've had a play with the "bench" code so I can't
> > say if it has ever worked.
> > 
> > The odd thing is that there was nothing else running, no postmaster,
> > no backends, nothing. It would seem like it's locking itself!!
> > 
> > It's not a major problem to me as everything else works OK, even the
> > regression tests are 100% excepting error message and precision
> > differences.
> > 
> > Keith.
> > 
> > > 
> > >             regards, tom lane
> > 
> > 
> > [postgres@sparclinux buffer]$ make s_lock_test
> > gcc -I../../../include -I../../../backend   -O2 -Wall -Wmissing-prototypes -I../.. -DS_LOCK_TEST=1 s_lock.c -o
s_lock_
> > test
> > ./s_lock_test
> > S_LOCK_TEST: this will hang for a few minutes and then abort
> >              with a 'stuck spinlock' message if S_LOCK()
> >              and TAS() are working.
> > 
> > FATAL: s_lock(00020bf0) at s_lock.c:271, stuck spinlock. Aborting.
> > 
> > FATAL: s_lock(00020bf0) at s_lock.c:271, stuck spinlock. Aborting.
> > make: *** [s_lock_test] IOT trap/Abort (core dumped)
> > make: *** Deleting file `s_lock_test'
> > [postgres@sparclinux buffer]$                    
> > 
> > 



Re: [HACKERS] Problem in S_LOCK?

From
"Thomas A. Szybist"
Date:
Well, good news and bad news. It seems to work for me. Sorry.
This is a sparc10 running 2.0.30.  Yes, very old.  Soon I can
give Red hat 6.0 a try on an Ultra10.

[szybist@anka post]$ initdb

We are initializing the database system with username szybist (uid=501).
This user will own all the files and must also own the server process.

Creating Postgres database system directory /home/szybist/post/data/base

Creating template database in /home/szybist/post/data/base/template1

Creating global classes in /home/szybist/post/data/base

Adding template1 database to pg_database...

Vacuuming template1
Creating public pg_user view
Creating view pg_rules
Creating view pg_views
Creating view pg_tables
Creating view pg_indexes
Loading pg_description
[szybist@anka post]$ postgres template1

POSTGRES backend interactive interface 
$Revision: 1.115 $ $Date: 1999/05/22 17:47:49 $

backend> create database bench
blank        1: datname     (typeid = 19, len = 32, typmod = -1, byval = f)        2: datdba      (typeid = 23, len =
4,typmod = -1, byval = t)        3: encoding    (typeid = 23, len = 4, typmod = -1, byval = t)        4: datpath
(typeid= 25, len = -1, typmod = -1, byval = f)       ----
 
backend>