After a few tough lessons like that we've put monitoring in place for ensuring that the standby and/or PITR servers have testing in place e.g. PITR servers must have uninterrupted WAL sequences.
Most Postgres corruption (on a master) actually happens due to dodgy hardware, but we don't really use bad hardware. In cases where we used VM's we've suspected something fishy in VMWare itself. In one case we suspected the SAN that the VMWare host was using.
So mostly not Postgres' fault. There were however some known replication bugs in the 9.x versions that were quite nasty. I think those bugs have now all or mostly been fixed, so 9.6 and 10 (beta) onwards are extremely stable.
But the risk of HW issues still remain as the biggest reason for postgres corruption.
I cannot emphasize enough how important backups are (both standby servers and PITR) and also to verify that these are indeed valid for that day when you're going to need to use them.
You'd be broke. :)
- PG only added checksums in 9.3
- his disks or RAID controller could be shit or he could be using some 'very cool' filesystem
- Some people turn off PG settings for performance that really shouldn't be turned off
- Some people think ECC ram isn't worth the money
- or overclock their CPU on anything other than a gaming machine
Usually it's shit hardware
Although if I had a $100 for every time I've had DB corruption in Postgres over the years...
That being said, since 9.4 (or maybe 9.5) these incidents have mostly stopped happening and it's been remarkably stable.