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

Re: Buffer Management

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bradley McLean <brad(at)bradm(dot)net>
Cc: Mario Weilguni <mario(dot)weilguni(at)icomedias(dot)com>,Curt Sampson <cjs(at)cynic(dot)net>, "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 16:42:51
Message-ID: 8765.1025023371@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Bradley McLean <brad(at)bradm(dot)net> writes:
> Okay, so instead of looking for constraints from the OS on the data file,
> use the constraints on the WAL file.  It would work at the cost of a buffer
> copy?  Er, maybe two:

> mmap the data file and WAL separately.
> Copy the data file page to the WAL mmap area.
> Modify the page.
> msync() the WAL.
> Copy the page to the data file mmap area.
> msync() or not the data file.

Huh?  The primary argument in favor of mmap is to avoid buffer copies;
seems like you are paying that price anyway.  Also, we do not want to
msync WAL for every single WAL record, but I think you'd have to with
the above scheme.  (Assuming you have adequate shared buffer space,
the present scheme only has to fsync WAL at transaction commit and
checkpoints, because it won't actually push out data pages except at
checkpoint time.)

			regards, tom lane



In response to

pgsql-hackers by date

Next:From: James HubbardDate: 2002-06-25 16:47:45
Subject: Re: Democracy and organisation : let's make a revolution
Previous:From: Jeff MacDonaldDate: 2002-06-25 16:42:05
Subject: Re: Democracy and organisation : let's make a revolution

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