From owner-freebsd-hackers Fri Mar 20 13:32:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA00472 for freebsd-hackers-outgoing; Fri, 20 Mar 1998 13:32:52 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from phoenix.its.rpi.edu (dec@phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA00351 for ; Fri, 20 Mar 1998 13:32:24 -0800 (PST) (envelope-from dec@phoenix.its.rpi.edu) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.8/8.8.7) with SMTP id QAA13031; Fri, 20 Mar 1998 16:29:34 -0500 (EST) (envelope-from dec@phoenix.its.rpi.edu) Date: Fri, 20 Mar 1998 16:29:34 -0500 (EST) From: "David E. Cross" To: Eivind Eklund cc: shimon@simon-shapiro.org, "Kent S. Gordon" , roberto@keltia.freenix.fr, freebsd-hackers@FreeBSD.ORG Subject: Re: How do you increase available SYSV shared memory? In-Reply-To: <19980320221931.51710@follo.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 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