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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
