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

From Alfred Perlstein
Subject Re: Need help with phys backed shm segments (Postgresql+FreeBSD).
Date
Msg-id 20001205130445.E8051@fw.wintelcom.net
Whole thread Raw
In response to Re: 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).
Re: Need help with phys backed shm segments (Postgresql+FreeBSD).
List pgsql-hackers
* Alfred Perlstein <bright@wintelcom.net> [001205 12:30] wrote:
> * Tom Lane <tgl@sss.pgh.pa.us> [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 in FreeBSD's handling of tiny shm
> > segments?
> 
> Good call, i think I found it! :)

Here's the patch I'm using on FreeBSD, it seems to work, if any
other FreeBSD'ers want to try it out, just apply the patch:
cd /usr/src/sys/vm ; patch < patchfile

and recompile and boot with a new kernel, then do this:

sysctl -w kern.ipc.shm_use_phys=1

or add:
kern.ipc.shm_use_phys=1 
to /etc/sysctl.conf

Let me know if it works.

thanks,
-Alfred

Index: phys_pager.c
===================================================================
RCS file: /home/ncvs/src/sys/vm/phys_pager.c,v
retrieving revision 1.3.2.1
diff -u -u -r1.3.2.1 phys_pager.c
--- phys_pager.c    2000/08/04 22:31:11    1.3.2.1
+++ phys_pager.c    2000/12/05 20:13:25
@@ -83,7 +83,7 @@         * Allocate object and associate it with the pager.         */        object =
vm_object_allocate(OBJT_PHYS,
-            OFF_TO_IDX(foff + size));
+            OFF_TO_IDX(foff + PAGE_MASK + size));        object->handle = handle;
TAILQ_INSERT_TAIL(&phys_pager_object_list,object,            pager_object_list);
 


pgsql-hackers by date:

Previous
From: Camm Maguire
Date:
Subject: Foreign key references to non-primary key columns
Next
From: "Mikheev, Vadim"
Date:
Subject: RE: [BUGS] foreign key check makes a big LOCK