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