To follow up on Patrick's comments, the quote from the FAQ is out of date. The "we are working to provide an intermediate mode" is exactly how 7.1 works now, and is how most commercial DB's work:
1. The system writes information about changed tuples (rows) to the WAL (write-ahead log, functionally equivalent to Oracle's REDO log) when it processes UPDATE/INSERT/CREATE commands. The WAL is fsynch'd at the end of every transaction.
Every 30 seconds (a configurable number, BTW) the dirty pages in the shared memory buffer are flushed to disk and data files are fsynch'd. This is done to prevent the need for an unbounded WAL (WAL segments can be reused once the data being tracked has been safely fsynch'd on the disk).
This increases the speed of inserts and updates by roughly an order of magnitude when the DB's subjected to typical ones which change relatively short rows. Inserting big chunks into large objects won't perform so well, but no one expects this to run fast anyway.
I've heard mixed results of PG on a ReiserFS partition (it only journals metadata, BTW, so won't prevent data loss on a crash).
Personally my bet's riding on RAID 1, a good UPS and a non-journaling file system ...
