Re: [HACKERS] Problem in S_LOCK?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>
> Keith Parks <emkxp01(at)mtcc(dot)demon(dot)co(dot)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(at)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(at)sparclinux buffer]$