PostgreSQL

Long-running queries on read replica with hot_standby_feedback cause periodic CPU spikes on primary

warning
ReplicationUpdated Mar 4, 2026
Technologies:
How to detect:

When hot_standby_feedback is enabled and long-running queries execute on a read replica (30+ minutes), the primary database experiences periodic CPU spikes and LWLock:BufferContent contention. Spikes occur at consistent intervals matching the replica query schedule. Affects busy tables with frequent updates, even when autovacuum runs frequently.

Recommended action:

Add indexes to tables queried by long-running replica operations (e.g., ETL jobs) to reduce query duration on the replica. This prevents the replica from blocking VACUUM operations on the primary. Alternatively, disable hot_standby_feedback if replica query freshness is less critical than primary performance, accepting potential replication lag during long queries.