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-25 14:20:15
Message-ID: Pine.NEB.4.43.0206252318020.670-100000@angelic.cynic.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 25 Jun 2002, Tom Lane wrote:

> 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.

Sure. Just mmap a file, and it will be persistent.

> 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.

I don't understand why there would be any loss of visibility of changes.
If two backends mmap the same block of a file, and it's shared, that's
the same block of physical memory that they're accessing. Changes don't
even need to "propagate," because the memory is truly shared. You'd keep
your locks in the page itself as well, of course.

Can you describe the problem in more detail?

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

It's #2 that I was really looking at. :-)

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-06-25 14:20:29 Re: Buffer Management
Previous Message Larry Rosenman 2002-06-25 14:17:30 Re: Buffer Management