# max_notify_queue_pages

> max_notify_queue_pages — Sets the maximum number of allocated pages for NOTIFY / LISTEN queue. Observed in PG17–19 Beta 3; its last measured boot default is 1048576 in PG19 Beta 3, with postmaster context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.
---

> [!NOTE]
> **Fact — official short description:** “Sets the maximum number of allocated pages for NOTIFY / LISTEN queue.”

## Identity {#identity}

| Field | Value | Meaning |
| --- | --- | --- |
| Type | `integer` | Upstream pg_settings type |
| Context | `postmaster` | Requires a server restart |
| Unit | — | Raw unit |
| Range | `64` – `2147483647` | Raw limits in the last observed version |
| Enum values | — | — for non-enum types |
| Category | Resource Usage / Disk | Upstream classification |
| Latest boot value | `1048576` | 1048576 |
{.fields meta="-"}

## Lifecycle {#lifecycle}

| Fact | Value |
| --- | --- |
| First observed | PG17 |
| Present in | PG17–19 Beta 3 |
| Removed in | No |
| Introduction commit | [`2cdf131c46e6`](https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=2cdf131c46e631addfc386f6106e52a1b8cc3a70) — Use larger segment file names for pg_notify |
| Commit date | 2023-11-29 |
| Discussion | [thread 1](https://postgr.es/m/CACG%3DezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe%3DpyyjVWA%40mail.gmail.com) · [thread 2](https://postgr.es/m/CAJ7c6TPDOYBYrnCAeyndkBktO0WG2xSdYduTF0nxq%2BvfkmTF5Q%40mail.gmail.com) |

## Default history {#default-history}

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

## How it works {#mechanism}

max_notify_queue_pages caps the number of database pages that the disk-backed LISTEN/NOTIFY queue may allocate. At the usual 8kB BLCKSZ, the PG18 default permits up to 8GB.

Notifications remain queued until all listening sessions have consumed or no longer need them. A listener that stays inside a long transaction can prevent cleanup and let queue usage grow.

This is disk capacity, not notify_buffers memory and not a limit on one payload. When the queue is full, transactions attempting NOTIFY can fail at commit. Its postmaster context fixes the value at server start; changing it requires a restart.

## Tuning advice {#tuning-advice}

> [!TIP]
> **Advice.** These are workload-specific starting points and must be validated with measurements.

| Workload | Guidance |
| --- | --- |
| OLTP | Monitor pg_notification_queue_usage() and identify listeners that remain in long transactions before increasing capacity. Size the disk-backed queue from the maximum tolerated notification backlog and available database volume, not query scan throughput. |
| OLAP | An OLAP label does not justify a larger queue. Long analytical transactions in listening sessions can delay cleanup, so separate listeners from long transactions and measure notification production versus consumption. |
| Small nodes | Keep the default unless the application has a verified LISTEN/NOTIFY backlog requirement. More pages permit more disk consumption and postpone failure; they do not fix a stalled listener. |
{.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 | Unmodified | — | — |
| OLAP | Unmodified | — | — |
| CRIT | Unmodified | — | — |
| TINY | Unmodified | — | — |
{.full-width}

> [!CAUTION]
> **Advice — pending human review.** Fact from the current Pigsty template projection: OLTP: PG17–19 Beta 3 unmodified; OLAP: PG17–19 Beta 3 unmodified; CRIT: PG17–19 Beta 3 unmodified; TINY: PG17–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

## Common pitfalls {#common-pitfalls}

- Increasing queue capacity instead of fixing a listener that stays inside a long transaction.
- Confusing max_notify_queue_pages disk capacity with notify_buffers shared-memory cache.
- Forgetting that, with 8kB pages, the default 1048576 pages permits up to about 8GB.
- Assuming a larger queue changes an individual NOTIFY payload limit or delivery semantics.

## Related parameters {#related-parameters}

[`notify_buffers`](/parameters/notify-buffers/) · [`track_activities`](/parameters/track-activities/) · [`max_connections`](/parameters/max-connections/) · [`shared_buffers`](/parameters/shared-buffers/)

## References {#references}

- [PostgreSQL 19 Beta 3 — max_notify_queue_pages](https://www.postgresql.org/docs/19/runtime-config-resource.html#GUC-MAX-NOTIFY-QUEUE-PAGES)
- [PostgreSQL 19 release notes](https://www.postgresql.org/docs/19/release-19.html)
- [Machine-readable GUC export](/data/guc.jsonl)