* Tom Lane (tgl@sss.pgh.pa.us) [020625 11:00]:
>
> 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.
>
> 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.
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.
(This is half baked, just thought I'd see if it stirred further thought).
As another approach, how expensive is re-MMAPing portions of the files
compared to the copies.
-Brad
>
> regards, tom lane
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>