On Monday 08 November 2010 00:35:29 Greg Smith wrote:
> Marti Raudsepp wrote:
> > I will grant you that the details were wrong, but I stand by the
> > conclusion. I can state for a fact that PostgreSQL's default
> > wal_sync_method varies depending on the <fcntl.h> header.
>
> Yes; it's supposed to, and that logic works fine on some other
> platforms. The question is exactly what the new Linux O_DSYNC behavior
> is doing, in regards to whether it flushes drive caches out or not.
> Until you've quantified which of the cases do that--which is required
> for reliable operation of PostgreSQL--and which don't, you don't have
> any data that can be used to draw a conclusion from. If some setups are
> faster because they write less reliably, that doesn't automatically make
> them the better choice.
I think thats FUD. Sorry.
Can you explain to me why fsync() may/should/could be *any* less reliable than
O_DSYNC? On *any* platform. Or fdatasync() in the special way its used with
pg, namely completely preallocated files.
I think the reasons why O_DSYNC is, especially, but not only, in combination
with a small wal_buffers setting, slow in most circumstances are pretty clear.
Making a setting which is only supported on a small range of systems highest
in the preferences list is even more doubtfull than the already strange choice
of making O_DSYNC the default given the way it works (i.e. no reordering,
synchronous writes in the bgwriter, synchronous writes on wal_buffers pressure
etc).
Greetings,
Andres