wal_receiver_status_interval
Fact — official short description: “Sets the maximum interval between WAL receiver status reports to the sending server.”
Identity
Lifecycle
| Fact | Value |
|---|---|
| First observed | PG9.1 |
| Present in | PG9.1–19 Beta 3 |
| Removed in | No |
| Introduction commit | b186523fd97c — Send status updates back from standby server to master, indicating how far the standby has written, flushed, and applied the WAL. At the moment, this is for informational purposes only, the values are only shown in pg_stat_replication system view, but in the future they will also be needed for synchronous replication. |
| Commit date | 2011-02-10 |
| Discussion | — |
Default history
| Versions | Raw boot_val |
Unit | Human value |
|---|---|---|---|
| PG9.1–19 Beta 3 | 10 |
s |
10 s |
How it works
Sets the maximum interval between WAL receiver status reports to the sending server. A configuration reload applies a new value; existing work already in flight is not retroactively changed.
The receiver sends write, flush, and replay positions upstream at most this far apart, with additional replies when requested. Lower values improve monitoring and feedback freshness but do not make WAL replay itself faster.
Monitor and change wal_receiver_status_interval together with wal_receiver_timeout, wal_sender_timeout, primary_conninfo. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.
Tuning advice
Advice. These are workload-specific starting points and must be validated with measurements.
| Workload | Guidance |
|---|---|
| OLTP | Size wal_receiver_status_interval from topology, failover roles, slot/subscription count, and reconnect headroom. Test worst-case primary latency, standby replay, and disk retention before production. |
| 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. |
| Small nodes | Configure only replication capacity that is actually used. Even a small topology needs bounded timeouts and slot lifecycle; unlimited retention is not reliability. |
Pigsty
Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.
| Template | Effective value | Versus upstream boot | Source expression |
|---|---|---|---|
| OLTP | 1s |
different | 1s |
| OLAP | 1s |
different | 1s |
| CRIT | 1s |
different | 1s |
| TINY | 1s |
different | 1s |
Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG9.1–19 Beta 3 = 1s (dcs); OLAP: PG9.1–19 Beta 3 = 1s (dcs); CRIT: PG9.1–19 Beta 3 = 1s (dcs); TINY: PG9.1–19 Beta 3 = 1s (dcs). Advice, pending human review — Editorial interpretation, pending human maintainer review: the override appears intended to provide fresher replay/flush feedback to senders and monitoring; confirm it against the current Pigsty templates, hardware fixture, and operational guarantees before publication.
Common pitfalls
- 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.
Related parameters
wal_receiver_timeout · wal_sender_timeout · primary_conninfo · hot_standby_feedback · hot_standby · max_standby_archive_delay
References
- PostgreSQL 19 Beta 3 — wal_receiver_status_interval
- PostgreSQL 19 release notes
- Machine-readable GUC export