Postgres recovery_prefetch can cause outages

Why are all the comments getting downvoted? Maybe this one will too? The other replies _look_ like they have substance, so some refutation would be helpful.

Worth noting the default is recovery_prefetch = try (since PG15 when it was added), so anyone on 15+ is running this without having chosen it.

The part that makes this nasty on cloud disks is that it's latent. On a burstable volume the standby has headroom most of the time, so the amplified reads are invisible until the one day a write burst lines up with a network blip and the volume is already at its IOPS ceiling. Nothing in normal monitoring looks wrong beforehand.

Things I'd check if you can't flip it off immediately: - pg_stat_recovery_prefetch on the standby to see how much prefetching is actually happening vs being skipped - replay_lag in pg_stat_replication, alerted on, not just graphed - standby read IOPS against the provisioned limit during your biggest batch jobs - if you have a single synchronous standby, that's the real outage multiplier here; ANY 1 across two standbys (as the author suggests) or accepting async for that tier changes "slow replica" back into "slow replica" instead of "primary stops taking writes"

The 16x IOPS amplification is the part that clicked. Prefetch turns the primary sequential writes into 8k random reads on the standby, so a cheap cloud disk hits its IOPS cap even when bytes-read looks fine. Combined with the standby state machine that will not go back to streaming until local WAL is fully replayed, a brief walreceiver blip during a bulk update becomes a half-hour write freeze on the primary. I would turn recovery_prefetch off on any sync replica sitting on provisioned IOPS, and keep a second standby with ANY 1 so one lagging node cannot stall commits.