Postgres recovery_prefetch can cause outages

Investigation shows that Postgres's recovery_prefetch feature can trigger production outages by converting large sequential I/O on the primary into many small random reads on standbys. With full-page writes (FPW/FPIs) common and synchronous replication increasingly used, recovery_prefetch can amplify read IOPS (up to ~16x for the same bytes read), saturating replica disks. When a standby falls behind during a write burst and enters WAL-restore mode it may not resume streaming until it catches up, and synchronous replication prevents the primary from accepting commits without a healthy standby - so a brief network glitch plus a burst of writes (or VACUUM) can produce multi-minute to multi-hour global write stalls.

The issue is reproducible: on a modest VM with limited IOPS, run pgbench with a 5% update workload, create a write burst, then kill the walreceiver; with recovery_prefetch enabled TPS drops to zero for tens of minutes while replicas hit disk limits. Turning off recovery_prefetch eliminates the read-IOPS spike and keeps standbys reasonably caught up (apply finishes much faster). The findings suggest disabling recovery_prefetch on production replicas or using multiple standbys with quorum commit to avoid single-standby blocking, since the feature’s benefits are dubious when FPWs are enabled by default.