# max_standby_streaming_delay

> max_standby_streaming_delay — Sets the maximum delay before canceling queries when a hot standby server is processing streamed WAL data. Observed in PG9.0–19 Beta 3; its last measured boot default is 30 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 delay before canceling queries when a hot standby server is processing streamed WAL data.”

## Identity {#identity}

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

## Lifecycle {#lifecycle}

| Fact | Value |
| --- | --- |
| First observed | PG9.0 (research boundary) |
| Present in | PG9.0–19 Beta 3 |
| Removed in | No |
| Introduction commit | Not asserted: predates the PG9.0 research boundary |
| Commit date | — |
| Discussion | — |

## Default history {#default-history}

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

## How it works {#mechanism}

Sets the maximum delay before canceling queries when a hot standby server is processing streamed WAL data. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

While replaying streamed WAL, recovery may wait up to this accumulated delay for conflicting queries before cancellation. Larger values favor read continuity but raise replication lag and recovery-point exposure; hot_standby_feedback addresses some snapshot conflicts with primary-side bloat risk.

Monitor and change max_standby_streaming_delay together with max_standby_archive_delay, hot_standby, hot_standby_feedback. 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 max_standby_streaming_delay 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 | `3min` | different | `3min` |
| OLAP | `3min` | different | `3min` |
| CRIT | `3min` | different | `3min` |
| TINY | `3min` | different | `3min` |
{.full-width}

> [!CAUTION]
> **Advice — pending human review.** Fact from the current Pigsty template projection: OLTP: PG9.0–19 Beta 3 = 3min (dcs); OLAP: PG9.0–19 Beta 3 = 3min (dcs); CRIT: PG9.0–19 Beta 3 = 3min (dcs); TINY: PG9.0–19 Beta 3 = 3min (dcs). Advice, pending human review — Editorial interpretation, pending human maintainer review: the override appears intended to allow short analytical reads on a streaming standby without permitting unbounded replay lag; 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}

[`max_standby_archive_delay`](/parameters/max-standby-archive-delay/) · [`hot_standby`](/parameters/hot-standby/) · [`hot_standby_feedback`](/parameters/hot-standby-feedback/) · [`recovery_min_apply_delay`](/parameters/recovery-min-apply-delay/) · [`in_hot_standby`](/parameters/in-hot-standby/) · [`primary_conninfo`](/parameters/primary-conninfo/)

## References {#references}

- [PostgreSQL 19 Beta 3 — max_standby_streaming_delay](https://www.postgresql.org/docs/19/runtime-config-replication.html#GUC-MAX-STANDBY-STREAMING-DELAY)
- [PostgreSQL 19 release notes](https://www.postgresql.org/docs/19/release-19.html)
- [Machine-readable GUC export](/data/guc.jsonl)