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

Type , Valueinteger: Upstream pg_settings type
Context , Valuepostmaster: Requires a server restart
Unit , Value—: Raw unit
Range , Value64 – 2147483647: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueResource Usage / Disk: Upstream classification
Latest boot value , Value1048576: 1048576

Lifecycle

Fact	Value
First observed	PG17
Present in	PG17–19 Beta 3
Removed in	No
Introduction commit	`2cdf131c46e6` — Use larger segment file names for pg_notify
Commit date	2023-11-29
Discussion	thread 1 · thread 2

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG17–19 Beta 3	`1048576`	—	1048576

How it works

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

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.

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	—	—

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

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.

notify_buffers · track_activities · max_connections · shared_buffers