Re: Need help with phys backed shm segments (Postgresql+FreeBSD). - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Need help with phys backed shm segments (Postgresql+FreeBSD).
Date
Msg-id 14549.976030990@sss.pgh.pa.us
Whole thread Raw
In response to Need help with phys backed shm segments (Postgresql+FreeBSD).  (Alfred Perlstein <bright@wintelcom.net>)
Responses Re: Need help with phys backed shm segments (Postgresql+FreeBSD).  (Alfred Perlstein <bright@wintelcom.net>)
List pgsql-hackers
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):

> 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?

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...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Guenter
Date:
Subject: Re: Using Threads?
Next
From: Alfred Perlstein
Date:
Subject: Re: Need help with phys backed shm segments (Postgresql+FreeBSD).