Re: [HACKERS] Problem in S_LOCK? - Mailing list pgsql-hackers

From Thomas A. Szybist
Subject Re: [HACKERS] Problem in S_LOCK?
Date
Msg-id 199905260037.UAA08256@carmina.boxhill
Whole thread Raw
In response to Re: [HACKERS] Problem in S_LOCK?  (Keith Parks <emkxp01@mtcc.demon.co.uk>)
List pgsql-hackers
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]$                    
> 
> 


pgsql-hackers by date:

Previous
From: "Oliver Elphick"
Date:
Subject: Re: [HACKERS] Call for updates!
Next
From: Tatsuo Ishii
Date:
Subject: Re: [HACKERS] I can't compile cvs snapshot ...