Gaetano Mendola <[EMAIL PROTECTED]> writes: > Now that the argument is already open, why postgres choose > on linux fdatasync? I'm understanding from other posts that > on this platform open_sync is better than fdatasync.
AFAIR, we've seen *one* test from *one* person alleging that. And it was definitely not that way when we tested the behavior originally, several releases back. I'd like to see more evidence, or better some indication that the Linux kernel changed algorithms, before changing the default. The tests that started this thread are pretty unconvincing in my eyes, because they are comparing open_sync against code that fsyncs after each one-block write. Under those circumstances, *of course* fsync will lose (or at least do no better), because it's forcing the same number of writes through a same-or-less-efficient API. The reason that this isn't a trivial choice is that Postgres doesn't necessarily need to fsync after every block of WAL. In particular, when doing large transactions there could be many blocks written between fsyncs, and in that case you could come out ahead with fsync because the kernel would have more freedom to schedule disk writes. So, the only test I put a whole lot of faith in is testing your own workload on your own Postgres server. But if we want to set up a toy test program to test this stuff, it's at least got to have an easily adjustable (and preferably randomizable) distance between fsyncs. Also, tests on IDE drives have zero credibility to start with, unless you can convince me you know how to turn off write buffering on the drive... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]