Re: Buffer Management - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Buffer Management
Date
Msg-id 200206251456.g5PEuwO15564@candle.pha.pa.us
Whole thread Raw
In response to Re: Buffer Management  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Buffer Management  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Curt Sampson <cjs@cynic.net> writes:
> > On Tue, 25 Jun 2002, Tom Lane wrote:
> >> 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.
> 
> Is it?  You have a mighty narrow conception of the range of
> implementations that's possible for mmap.
> 
> But the main problem is that mmap doesn't let us control when changes to
> the memory buffer will get reflected back to disk --- AFAICT, the OS is
> free to do the write-back at any instant after you dirty the page, and
> that completely breaks the WAL algorithm.  (WAL = write AHEAD log;
> the log entry describing a change must hit disk before the data page
> change itself does.)

Can we mmap WAL without problems?  Not sure if there is any gain to it
because we just write it and rarely read from it.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Buffer Management
Next
From: Thomas Lockhart
Date:
Subject: Re: SQL99, CREATE CAST, and initdb