Re: Need help with phys backed shm segments (Postgresql+FreeBSD).

* Tom Lane <tgl@sss.pgh.pa.us> [001205 07:43] wrote:
> Alfred Perlstein <bright@wintelcom.net> writes:
> > Here's the log, the number in parens is the address of the lock,
> > on tas() the value printed to the right is the value in _ret,
> > for the others, it's the value before the lock count is set.
> 
> This looks to be the trace of a SpinAcquire()
> (see src/backend/storage/ipc/spin.c):

Yes, those are my debug printfs :).

> > tas (0x30048048) -> 0
> > tas (0x3004804d) -> 0
> > tas (0x3004804c) -> 0
> > S_UNLOCK: (0x30048048) -> 1
> 
> followed by SpinRelease():
> 
> > tas (0x30048048) -> 0
> > S_UNLOCK: (0x3004804c) -> 1
> > S_UNLOCK: (0x3004804d) -> 1
> > S_UNLOCK: (0x30048048) -> 1
> 
> followed by a failed attempt to reacquire the same SLock:
> 
> > tas (0x30048048) -> 0
> > tas (0x3004804d) -> 4
> > tas (0x3004804d) -> 1
> > tas (0x3004804d) -> 1
> > tas (0x3004804d) -> 1
> > tas (0x3004804d) -> 1
> 
> And that looks completely broken :-( ... something's clobbered the
> exlock field of the SLock struct, apparently.  Are you sure this
> kernel feature you're trying to use actually works?

No I'm not sure actually. :)  I'll look into it further, but I
was wondering if there was something I could do to debug the
locks better.  I think I'll add some S_MAGIC or something in
the struct to see if the whole thing is getting clobbered or
what...  If you have any suggestions let me know.

> BTW, if you're wondering why an SLock needs to contain *three*
> hardware spinlocks, the answer is that it doesn't.  This code has
> been greatly simplified in current sources...

It did look a bit strange...

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."