Re: Buffer Management - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Buffer Management
Date
Msg-id 7298.1025014142@sss.pgh.pa.us
Whole thread Raw
In response to Re: Buffer Management  (Curt Sampson <cjs@cynic.net>)
Responses Re: Buffer Management  (Larry Rosenman <ler@lerctr.org>)
Re: Buffer Management  (Curt Sampson <cjs@cynic.net>)
Re: Buffer Management  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Buffer Management  (Lee Kindness <lkindness@csl.co.uk>)
List pgsql-hackers
Curt Sampson <cjs@cynic.net> writes:
> So, while we're at it, what's the current state of people's thinking
> on using mmap rather than shared memory for data file buffers?

There seem to be a couple of different threads in doc/TODO.detail/mmap.

One envisions mmap as a one-for-one replacement for our current use of
SysV shared memory, the main selling point being to get out from under
kernels that don't have SysV support or have it configured too small.
This might be worth doing, and I think it'd be relatively easy to do
now that the shared memory support is isolated in one file and there's
provisions for selecting a shmem implementation at configure time.
The only thing you'd really have to think about is how to replace the
current behavior that uses shmem attach counts to discover whether any
old backends are left over from a previous crashed postmaster.  I dunno
if mmap offers any comparable facility.

The other discussion seemed to be considering how to mmap individual
data files right into backends' address space.  I do not believe this
can possibly work, because of loss of control over visibility of data
changes to other backends, timing of write-backs, etc.

But as long as you stay away from interpretation #2 and go with
mmap-as-a-shmget-substitute, it might be worthwhile.

(Hey Marc, can one do mmap in a BSD jail?)
        regards, tom lane




pgsql-hackers by date:

Previous
From: Curt Sampson
Date:
Subject: Re: Buffer Management
Next
From: Larry Rosenman
Date:
Subject: Re: Buffer Management