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