Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Mar 1998 22:19:31 +0100
From:      Eivind Eklund <eivind@yes.no>
To:        shimon@simon-shapiro.org, "Kent S. Gordon" <kgor@inetspace.com>
Cc:        roberto@keltia.freenix.fr, freebsd-hackers@FreeBSD.ORG
Subject:   Re: How do you increase available SYSV shared memory?
Message-ID:  <19980320221931.51710@follo.net>
In-Reply-To: <XFMail.980320123219.shimon@simon-shapiro.org>; from Simon Shapiro on Fri, Mar 20, 1998 at 12:32:19PM -0800
References:  <199803181718.LAA08905@soccer.inetspace.com> <XFMail.980320123219.shimon@simon-shapiro.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

Eivind.


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