hot_standby

Definition PG 18 manual

Specifies whether or not you can connect and run queries during recovery, as described in Section 26.4. The default value is on. This parameter can only be set at server start. It only has effect during archive recovery or in standby mode.

How it works

Allows connections and queries during recovery. The value is fixed when the server starts, so changing it requires a restart.

When recovery has reached a consistent state, this permits read-only connections and queries. Replay still has priority: WAL records that conflict with snapshots or locks can cancel queries according to the standby-delay settings.

Monitor and change hot_standby together with primary_conninfo, primary_slot_name, restore_command. Validate on the relevant server role and real workload, then use its postmaster context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Operational considerations

Changing it on the wrong primary, standby, sender, or subscriber role.

Watching only configured bytes/time instead of actual lag, slot position, and worker state.

Failing over to a node that lacks the old primary's capacity or prerequisites.

Using infinite waits or WAL retention to hide a failed consumer.

Workload guidance

OLAP: Read standbys and logical subscribers often see long queries or large transactions. Put explicit bounds on replay/apply and monitor lag, worker saturation, slot restart_lsn, and conflict cancellations.

OLTP: Size hot_standby from topology, failover roles, slot/subscription count, and reconnect headroom. Test worst-case primary latency, standby replay, and disk retention before production.

SMALL: Configure only replication capacity that is actually used. Even a small topology needs bounded timeouts and slot lifecycle; unlimited retention is not reliability.