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

* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [001205 07:43] wrote:
> Alfred Perlstein <bright(at)wintelcom(dot)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(at)wintelcom(dot)net|alfred(at)freebsd(dot)org]
"I have the heart of a child; I keep it in a jar on my desk."