> From: Alfred Perlstein <[EMAIL PROTECTED]>
> > To: Tom Lane <[EMAIL PROTECTED]>
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: [HACKERS] Need help with phys backed shm segments
>(Postgresql+FreeBSD).
> >
> > Here's the patch I'm using on FreeBSD
Just as interesting
On Tue, 5 Dec 2000, Alfred Perlstein wrote:
> * Alfred Perlstein <[EMAIL PROTECTED]> [001205 12:30] wrote:
> > * Tom Lane <[EMAIL PROTECTED]> [001205 08:37] wrote:
> > > BTW, I just remembered that in 7.0.*, the SLocks that are managed by
> > > SpinAcquire() all live in their
L PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Need help with phys backed shm segments (Postgresql+FreeBSD).
>
> * Alfred Perlstein <[EMAIL PROTECTED]> [001205 12:30] wrote:
> > * Tom Lane <[EMAIL PROTECTED]> [001205 08:37] wrote:
> > > BTW,
* Alfred Perlstein <[EMAIL PROTECTED]> [001205 12:30] wrote:
> * Tom Lane <[EMAIL PROTECTED]> [001205 08:37] wrote:
> > BTW, I just remembered that in 7.0.*, the SLocks that are managed by
> > SpinAcquire() all live in their own little shm segment. On a machine
> > where slock_t is char, it'd lik
* Tom Lane <[EMAIL PROTECTED]> [001205 08:37] wrote:
> BTW, I just remembered that in 7.0.*, the SLocks that are managed by
> SpinAcquire() all live in their own little shm segment. On a machine
> where slock_t is char, it'd likely only amount to 128 bytes or so.
> Maybe you are seeing some bug i
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> 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
BTW, I just remembered that in 7.0.*, the SLocks that are managed by
SpinAcquire() all live in their own little shm segment. On a machine
where slock_t is char, it'd likely only amount to 128 bytes or so.
Maybe you are seeing some bug in FreeBSD's handling of tiny shm
segments?
* Tom Lane <[EMAIL PROTECTED]> [001205 07:43] wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> 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
Alfred Perlstein <[EMAIL PROTECTED]> 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/bac
On FreeBSD 4.1.1 and above there's a sysctl tunable called
kern.ipc.shm_use_phys, when set to 1 it's supposed to
make the kernel's handling of shared memory much more
effecient at the expense or making the shm segment unpageable.
I tried to use this option with 7.0.3 and FreeBSD 4.2 but
for some
10 matches
Mail list logo
