> - the way PostgreSQL expects data to be written to disk without the
> fsync calls for things not to get corrupted in the event of a crash,
> and
If you want the filesystem to deal with this, I believe it is necessary
for it to write the data out in the same order the write requests are
supplied in between ALL PostgreSQL processes. If you can accomplish
this, you do not need WAL.
There are shortcuts which can be taken in the above, which is where WAL
comes in. WAL writes are ordered between processes and WAL of a single
process always hits disk prior to commit -- fsync forces both of these.
Due to WAL being in place, data can be written at almost any time. The
benefit to WAL is a single file fsync rather than the entire database
requiring one (PostgreSQL pre-7.1 method).
> I know that at the end of the day, if I value my data, I must (1) back
> it up regularly, and (2) keep fsync enabled in PostgreSQL. However given
> the significance performance hit (at least as far as massive INSERT or
If you want good performance, invest in a SCSI controller that has
battery backed write cache. A few megs will do it. You will find
performance similar to fsync being off (you don't wait for disk
rotation) but without the whole dataloss issue. Another alternative is
to buy a small 15krpm disk dedicated for WAL. In theory you can achieve
one commit per rotation.
I assume your inserts are not supplied in Bulk. The fsync overhead is
per transaction, not per insert.