Re: Buffer Management - Mailing list pgsql-hackers

From Mario Weilguni
Subject Re: Buffer Management
Date
Msg-id 4D618F6493CE064A844A5D496733D667038E68@freedom.icomedias.com
Whole thread Raw
In response to Buffer Management  (Curt Sampson <cjs@cynic.net>)
Responses Re: Buffer Management  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Isn't that what msync() is for? Or is this not portable?

-----Ursprüngliche Nachricht-----
Von: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Gesendet: Dienstag, 25. Juni 2002 16:30
An: Curt Sampson
Cc: J. R. Nield; Bruce Momjian; PostgreSQL Hacker
Betreff: Re: [HACKERS] Buffer Management


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.)
        regards, tom lane



---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org






pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Buffer Management
Next
From: Tom Lane
Date:
Subject: Re: Buffer Management