# wal_receiver_status_interval

> wal_receiver_status_interval — Sets the maximum interval between WAL receiver status reports to the sending server. Observed in PG9.1–19 Beta 3; its last measured boot default is 10 s in PG19 Beta 3, with sighup context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.
---

> [!NOTE]
> **Fact — official short description:** “Sets the maximum interval between WAL receiver status reports to the sending server.”

## Identity {#identity}

| Field | Value | Meaning |
| --- | --- | --- |
| Type | `integer` | Upstream pg_settings type |
| Context | `sighup` | Takes effect after configuration reload |
| Unit | `s` | Raw unit |
| Range | `0` – `2147483` | Raw limits in the last observed version |
| Enum values | — | — for non-enum types |
| Category | Replication / Standby Servers | Upstream classification |
| Latest boot value | `10` | 10 s |
{.fields meta="-"}

## Lifecycle {#lifecycle}

| Fact | Value |
| --- | --- |
| First observed | PG9.1 |
| Present in | PG9.1–19 Beta 3 |
| Removed in | No |
| Introduction commit | [`b186523fd97c`](https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=b186523fd97ce02ffbb7e21d5385a047deeef4f6) — 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 {#default-history}

| Versions | Raw `boot_val` | Unit | Human value |
| --- | --- | --- | --- |
| PG9.1–19 Beta 3 | `10` | `s` | 10 s |
{.full-width caption="Measured PG9.0–19 Beta 3 boot defaults"}

## How it works {#mechanism}

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 {#tuning-advice}

> [!TIP]
> **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. |
{.full-width}

## Pigsty {#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` |
{.full-width}

> [!CAUTION]
> **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 {#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 {#related-parameters}

[`wal_receiver_timeout`](/parameters/wal-receiver-timeout/) · [`wal_sender_timeout`](/parameters/wal-sender-timeout/) · [`primary_conninfo`](/parameters/primary-conninfo/) · [`hot_standby_feedback`](/parameters/hot-standby-feedback/) · [`hot_standby`](/parameters/hot-standby/) · [`max_standby_archive_delay`](/parameters/max-standby-archive-delay/)

## References {#references}

- [PostgreSQL 19 Beta 3 — wal_receiver_status_interval](https://www.postgresql.org/docs/19/runtime-config-replication.html#GUC-WAL-RECEIVER-STATUS-INTERVAL)
- [PostgreSQL 19 release notes](https://www.postgresql.org/docs/19/release-19.html)
- [Machine-readable GUC export](/data/guc.jsonl)