Date: Fri, 20 Mar 1998 16:29:34 -0500 (EST) From: "David E. Cross" <dec@phoenix.its.rpi.edu> To: Eivind Eklund <eivind@yes.no> Cc: shimon@simon-shapiro.org, "Kent S. Gordon" <kgor@inetspace.com>, roberto@keltia.freenix.fr, freebsd-hackers@FreeBSD.ORG Subject: Re: How do you increase available SYSV shared memory? Message-ID: <Pine.BSF.3.96.980320162848.12108B-100000@phoenix.its.rpi.edu> In-Reply-To: <19980320221931.51710@follo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 Mar 1998, Eivind Eklund wrote: > On Fri, Mar 20, 1998 at 12:32:19PM -0800, Simon Shapiro wrote: > > > > On 18-Mar-98 Kent S. Gordon wrote: > > > > > >>>>>> "shimon" == Simon Shapiro <shimon@simon-shapiro.org> writes: > > > I have been thinking of changing Postgres to use mmapped files instead > > > of SYSV shared memory. I think this should allow for larger postgres > > > > This will be a disaster. It assumes that PostgreSQL uses files for data > > storage. While this is the default mode, it is NOT the only storage > > meanager. In PostgreSQL, like most true RDBMS, the storage of data is > > decoupled from the logic of the relational model, etc. I am building a > > storage manager that uses a totally different (distributed) storage model > > than Unix files. A memory based storage manager already exists in > > PostgreSQL. Please do not break these. > > I don't think you're quite getting him (or I'm not getting you at all). > mmap()ing /dev/zero is a common way of getting hold of shared memory, > instead of using the SYSV SHMEM extension. mmap'ing usually works better. > > This is just replacing one technique for getting hold of shared memory with > another; it does nothing to the storage manager. This is very common indeed, it is how the dynamic linker on solaris works. -- David Cross UNIX Systems Administrator GE Corporate R&D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980320162848.12108B-100000>