You've been lucky - and I'm glad you have, of course...
Actually, hosing isn't 100% guaranteed. When the operating system does the synch at its leisure (the 30 second standard linux interval), it writes blocks out in any order it wants to (hopefully optimizing disk access!).
If it writes out the transaction log before the datafiles during this process then you'll have transactions logged as complete without the data really being there. Not a good time to crash.
I'm sure there are plenty of other ordering issues that come up.
The key is that PG uses fsynch to ensure that datafiles are synch'd before the transaction log.
Of course, if you're minimizing your risks by using a UPS that can tell Linux when to shut down, and are running RAID 1, your odds of not experiencing a hosed database go up a lot.
And, of course, if you're willing to lose a day's data (going back to your most recent backup), -F might well be worth it.
It just makes me cringe a bit :)
Now, until 6.5 came out, even read-only selects fsynch'd causing the transaction log to needlessly by synch'd, causing one's disk drive to go absolutely nuts under load. I pointed that out, and it got fixed for that version. Seems that none of the developers ever used it in our favorite way (i.e. backing a website) and hadn't noticed ... -F REALLY improved performance for ACS-like scenarios back then!
