Re: [HACKERS] Problem in S_LOCK?
От | Keith Parks |
---|---|
Тема | Re: [HACKERS] Problem in S_LOCK? |
Дата | |
Msg-id | 199905262100.WAA03050@mtcc.demon.co.uk обсуждение исходный текст |
Ответы |
Re: [HACKERS] Problem in S_LOCK?
("Thomas A. Szybist" <szybist@boxhill.com>)
|
Список | pgsql-hackers |
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]$ > > > >
В списке pgsql-hackers по дате отправления: