Skip site navigation (1) Skip section navigation (2)

Re: Buffer Management

From: Curt Sampson <cjs(at)cynic(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "J(dot) R(dot) Nield" <jrnield(at)usol(dot)com>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Buffer Management
Date: 2002-06-27 03:37:18
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, 26 Jun 2002, Tom Lane wrote:

> Curt Sampson <cjs(at)cynic(dot)net> writes:
> > Note that your proposal of using mmap to replace sysv shared memory
> > relies on the behaviour I've described too.
> True, but I was not envisioning mapping an actual file --- at least
> on HPUX, the only way to generate an arbitrary-sized shared memory
> region is to use MAP_ANONYMOUS and not have the mmap'd area connected
> to any file at all.  It's not farfetched to think that this aspect
> of mmap might work differently from mapping pieces of actual files.

I find it somewhat farfetched, for a couple of reasons:

    1. Memory mapped with the MAP_SHARED flag is shared memory,
    anonymous or not. POSIX is pretty explicit about how this works,
    and the "standard" for mmap that predates POSIX is the same.
    Anonymous memory does not behave differently.

    You could just as well say that some systems might exist such
    that one process can write() a block to a file, and then another
    might read() it afterwards but not see the changes. Postgres
    should not try to deal with hypothetical systems that are so
    completely broken.

    2. Mmap is implemented as part of a unified buffer cache system
    on all of today's operating systems that I know of. The memory
    is backed by swap space when anonymous, and by a specified file
    when not anonymous; but the way these two are handled is
    *exactly* the same internally.

    Even on older systems without unified buffer cache, the behaviour
    is the same between anonymous and file-backed mmap'd memory.
    And there would be no point in making it otherwise. Mmap is
    designed to let you share memory; why make a broken implementation
    under certain circumstances?

> In practice of course we'd have to restrict use of any such
> implementation to platforms where mmap behaves reasonably ... according
> to our definition of "reasonably".

Of course. As we do already with regular I/O.

Curt Sampson  <cjs(at)cynic(dot)net>   +81 90 7737 2974
    Don't you know, in this new Dark Age, we're all light.  --XTC

In response to

pgsql-hackers by date

Next:From: Christopher Kings-LynneDate: 2002-06-27 03:42:03
Subject: Re: User-friendliness for DROP RESTRICT/CASCADE
Previous:From: Christopher Kings-LynneDate: 2002-06-27 03:30:34
Subject: Re: Democracy and organisation : let's make a revolution

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group