Jonah H. Harris wrote: > As long as it's optional, I guess it's OK to let the administrator > deal with recovery. Of course, in addition to no-fsync, we'll have > another *possibly* dangerous option. BTW, I've seen no-fsync used far > too many times because people think they're hardware is invincible.
Use cases differ. I have used postgres in a system where without the no-fsync option the project would have been forced to use a different storage system. (Berkeley-DB was being considered for the alternative.) We cared much more about throughput than corruption, so long as we would *know* when corruption occurred. The cost of occasionally reprocessing data after a corruption was much lower than the cost of always fsyncing to avoid it. As I recall, during that project, we wanted some way to make the indexes run faster, even at the expense of occasional corruption. If Martin's idea has any noticeable performance improvement, I'm sure it would be welcomed by some. mark ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org