# PostgreSQL recovery_prefetch can cause synchronous replication outages

> **Key takeaway:** PostgreSQL's recovery_prefetch feature converts sequential I/O into 8k random reads that can amplify replica IOPS by up to 16x, causing standby lag that combines with synchronous replication requirements to halt primary writes for hours.

**Published:** 2026-10-21T06:59:12+00:00 
**Source:** Planet PostgreSQL 
**Category:** databases-storage 
**Canonical URL:** https://fosswire.org/news/postgresql-recoveryprefetch-can-cause-synchronous-replicatio.html 

## Summary
Database operations consultant Jeremy Schneider has published a detailed analysis showing that PostgreSQL's recovery_prefetch feature, enabled by default, can cause production outages. The issue occurs when recovery_prefetch converts large sequential I/O operations on the primary into numerous small random reads on replicas, amplifying IOPS by up to 16x. When combined with synchronous replication—where the primary requires at least one healthy standby to accept writes—this IOPS exhaustion can cause replicas to lag hours behind, freezing all writes on the primary. The problem was flagged during development in February 2021 and reported in the field in March 2025, but the full mechanism was not understood until now. Schneider has published a reproducible test case and is recommending disabling recovery_prefetch.

## How recovery_prefetch triggers outages
- **recovery_prefetch** issues `fadvise` calls to prefetch WAL blocks during recovery, but does not check whether blocks are already loaded from WAL Full Page Images (FPI/FPW)
- When FPW is enabled—as it is in most production installations—prefetched blocks may already be in shared buffers from WAL, making the prefetch unnecessary
- More critically, large sequential I/O on the primary becomes **8k random reads on replicas**, amplifying IOPS by up to **16x for the same byte volume**
- With **synchronous replication**, the primary blocks writes until at least one standby confirms receipt; if all replicas are IOPS-starved and lagging, writes halt
- The standby state machine in `xlogrecovery.c` enters WAL-restore mode when streaming breaks and **will not return to streaming until caught up**—which can take hours under IOPS pressure
- Schneider reproduced the outage consistently on a small cloud instance (500 IOPS, 2 CPU, 8 GB RAM) with pgbench; killing `walreceiver` during write bursts caused **30+ minute write freezes**
- Disabling `recovery_prefetch` eliminated the post-update IOPS burst and kept standbys caught up

## Why it matters
The finding affects a large swath of PostgreSQL deployments: FPW is ubiquitous in production, synchronous replication is the standard durability mechanism on Kubernetes with commodity hardware, and recovery_prefetch is enabled by default. Operators running cloud instances with IOPS limits are especially vulnerable. Schneider's reproducible test case and explicit recommendation to disable the feature will likely drive discussion on the hackers list and may lead to a default change or code fix in a future release.