From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mario Weilguni" <mario(dot)weilguni(at)icomedias(dot)com> |
Cc: | "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 14:52:52 |
Message-ID: | 7703.1025016772@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Mario Weilguni" <mario(dot)weilguni(at)icomedias(dot)com> writes:
> Isn't that what msync() is for? Or is this not portable?
msync can force not-yet-written changes down to disk. It does not
prevent the OS from choosing to write changes *before* you invoke msync.
For example, the HPUX man page for msync says:
Normal system activity can cause pages to be written to disk.
Therefore, there are no guarantees that msync() is the only control
over when pages are or are not written to disk.
Our problem is that we want to enforce the write ordering "WAL before
data file". To do that, we write and fsync (or DSYNC, or something)
a WAL entry before we issue the write() against the data file. We
don't really care if the kernel delays the data file write beyond that
point, but we can be certain that the data file write did not occur
too early.
msync is designed to ensure exactly the opposite constraint: it can
guarantee that no changes remain unwritten after time T, but it can't
guarantee that changes aren't written before time T.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-06-25 14:55:54 | Re: Buffer Management |
Previous Message | Mario Weilguni | 2002-06-25 14:45:54 | Re: Buffer Management |