CONFIGURATION PARAMETER资源消耗 / 磁盘
max_notify_queue_pages
设置 LISTEN/NOTIFY 队列最多分配的页面数。
Sets the maximum number of allocated pages for NOTIFY / LISTEN queue.
整数 重启生效 引入 17 现存至 20 devel 0 次默认值变更
版本轨迹
相对 PostgreSQL 17 无变化。
默认值变迁
已记录的默认值在 PostgreSQL 17–20 之间未变。带单位的取值换算成了可读形式，原始的 boot_val 与单位写在悬浮提示里。
手册说明
机制详解
max_notify_queue_pages 限制磁盘后端 LISTEN/NOTIFY 队列最多分配的数据库页面数。按常见 8kB BLCKSZ，PG18 默认允许最多 8GB。
通知会保留到所有监听会话都已消费或不再需要。监听者长期停留在事务中会阻止清理并让队列增长。
它限制磁盘容量，不是 notify_buffers 内存，也不是单个 payload 上限。队列写满时，尝试 NOTIFY 的事务可能在提交阶段失败。其 postmaster 上下文在服务器启动时固定取值，修改后必须重启。
调优建议
按典型负载给出的取值思路，不是放之四海皆准的配方：实际取值要看数据量、并发度与硬件。
-
OLTP在线事务处理
提高容量前先监控 pg_notification_queue_usage()，并找出长期停留在事务中的 listener。应按可容忍通知积压与数据库卷可用空间规划磁盘队列，而不是按查询扫描吞吐。
-
OLAP分析与批处理
OLAP 标签不能成为扩大队列的理由。监听会话中的长分析事务会延迟清理，因此应把 listener 与长事务分离，并测通知生产与消费速率。
-
小规格低配实例与开发机
除非应用有已验证的 LISTEN/NOTIFY 积压需求，否则保留默认。更多页面只会允许更多磁盘消耗并推迟失败，不能修复卡住的 listener。
常见问题
- 通过扩大队列代替修复长期停留在事务中的 listener。
- 把 max_notify_queue_pages 磁盘容量与 notify_buffers 共享内存缓存混淆。
- 忘记按 8kB 页面计算时，默认 1048576 页允许约 8GB。
- 认为更大队列会改变单个 NOTIFY payload 上限或投递语义。
演化历史
相邻两个大版本之间的差异，新的在前。版本号链到该版的快照。
-
PostgreSQL 20 ← 19 沿用 19
事实沿用 19
-
PostgreSQL 17 ← 16 新增此参数
PostgreSQL 17 起可用
逐版本快照
每个收录版本里的 7 项事实，与上一个存在的版本不同的格子带底色。版本号链到该版。
参考资料
同类参数
| 参数 | 类型 | 上下文 | 默认值 | 版本变动 | 最近变更 |
|---|---|---|---|---|---|
| 磁盘 4 | |||||
file_copy_method |
枚举 | 会话 | copy |
— | |
| 选择数据库文件的复制方法。 | 现存 | ||||
file_extend_method |
枚举 | 重载生效 | posix_fallocate |
— | |
| 选择扩展数据文件的方法。 | 现存 | ||||
max_notify_queue_pages |
整数 | 重启生效 | 1048576 |
— | |
| 设置 LISTEN/NOTIFY 队列最多分配的页面数。 | 现存 | ||||
temp_file_limit |
整数 | 会话（超级用户） | -1 kB |
— | |
| 限制每个 PostgreSQL 进程使用的全部临时文件总大小。 | 现存 | ||||