On Fri, 29 Feb 2008, Mark Wong wrote:
Basically posix_fadvise() is being called right before the WAL segment
file is closed, which effectively doesn't do anything as opposed to when
the file is opened. This proposed correction calls posix_fadvise() in
Actually, posix_fadvise is called nowhere; the one place it's referenced
at is #ifdef'd out. There's a comment in the code just above there as to
why: posix_fadvise only works on a limited number of platforms and as far
as I know nobody has ever put the time into figuring out where it's safe
or not safe so that configure can be taught that. I think this may be a
dead item because most places where posix_fadvise works correctly, you can
use O_SYNC and get O_DIRECT right now to do the same thing.
If memory serves, one of the wins here is suppose to be that in a
scenario where we are not expecting to re-read writes to the WAL we also
do not want the writes to disk to flush out other data from the
operating system disk cache.
Right, but you can get that already with O_SYNC on platforms where
O_DIRECT is supported.
There's a related TODO here which is to use directio(3C) on Solaris, which
Jignesh reports is needed instead of O_DIRECT to get the same behavior on
I am guessing that SATA drives have write cache enabled by default so it
seems to make sense that using POSIX_FADV_DONTNEED will cause writes to
be slower by writing through the disk cache.
I've never heard of a SATA drive that had its write cache disabled by
default. They're always on unless you force them off, and even then they
can turn themselves back on again if there's a device reset and you didn't
change the drive's default using the manufacturer's adjustment utility.
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly