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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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