Thread

  1. Re: [HACKERS] Problem in S_LOCK?

    Thomas A. Szybist <szybist@boxhill.com> — 1999-05-26T00:37:58Z

    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]$                    
    > 
    >