If you read between the lines, this says that EBS lies about the result of fsync(), which is horrifying.
It's generally possible to fsync, then cut the power before the data is physically on the disk.
There's also a Postgres contrib module called pg_test_fsync that tests various fsync modes on your hard drive, and if you get too high results, you can strongly suspect that the dist is lying.
On bigger hardware, like SAN storage arrays, the (redundant) batteries keep the whole thing running for a while after the loss of power.
My personal opinion is that raid controllers are of little value without battery backed cache.
I just use MD in front of 'enterprise sata' drives, as without doubling my total cost for storage, I can't get a raid card, as far as I can tell, which is better than MD, and really, if I was to double my storage cost, simply buying twice as many spindles would get me better bang for my buck, I think, than a hardware raid card that cost that much.
Of course that completely shafts your performance, but hopefully you were expecting that.
More recently we also discovered that these disks [EBS volumes experiencing performance degradation] will also frequently report that a disk transaction has been committed to hardware but are flat-out lying.
There's not enough information to know if that's even possible or not, or how it might be possible, but as far as I know there aren't any known postgres issues that would cause that.
I would be extremely reluctant to store data on a network that sometimes didn't actually store the data without raising an error anywhere.
Jump to conclusions much?
Do you know if reddit had fsync enabled in first place?
It's very common to turn off fsync on a database for performance reasons. It's far less common to have a network block device driver (which tend to be designed with intermittent outages in mind) lie about fsync.