2024 年 9 月 26 日: PostgreSQL 17 发布!
支持的版本:当前 (17) / 16 / 15 / 14 / 13 / 12
开发版本:devel
不支持的版本:11 / 10 / 9.6 / 9.5 / 9.4 / 9.3 / 9.2 / 9.1 / 9.0 / 8.4 / 8.3 / 8.2 / 8.1 / 8.0 / 7.4 / 7.3 / 7.2 / 7.1

LISTEN

LISTEN — 监听通知

概要

LISTEN channel

描述

LISTEN 将当前会话注册为名为 channel 的通知通道的监听器。如果当前会话已注册为该通知通道的监听器,则不会执行任何操作。

每当命令 NOTIFY channel 被调用时,无论是此会话还是连接到同一数据库的另一个会话,当前监听该通知通道的所有会话都会收到通知,并且每个会话都会依次通知其连接的客户端应用程序。

可以使用 UNLISTEN 命令注销给定通知通道的会话。会话的监听注册会在会话结束时自动清除。

客户端应用程序用于检测通知事件的方法取决于它使用的 PostgreSQL 应用程序编程接口。对于 libpq 库,应用程序将 LISTEN 作为普通 SQL 命令发出,然后必须定期调用函数 PQnotifies 以确定是否已收到任何通知事件。其他接口(如 libpgtcl)提供更高级的方法来处理通知事件;实际上,对于 libpgtcl,应用程序程序员甚至不应该直接发出 LISTENUNLISTEN。有关更多详细信息,请参阅您正在使用的接口的文档。

参数

channel

通知通道的名称(任何标识符)。

备注

LISTEN 在事务提交时生效。如果 LISTENUNLISTEN 在随后回滚的事务中执行,则正在监听的通知通道集将保持不变。

已执行 LISTEN 的事务无法为两阶段提交准备。

在首次设置监听会话时存在竞争条件:如果并发提交的事务正在发送通知事件,那么新监听的会话将接收哪些事件?答案是会话将接收在事务提交步骤期间某个时间点之后提交的所有事件。但这略晚于事务在查询中可能观察到的任何数据库状态。这导致了使用 LISTEN 的以下规则:首先执行(并提交!)该命令,然后在新事务中检查应用程序逻辑所需的数据库状态,然后依靠通知来了解随后对数据库状态的更改。前几个收到的通知可能指的是在初始数据库检查中已经观察到的更新,但这通常是无害的。

NOTIFY 包含对使用 LISTENNOTIFY 的更详细的讨论。

示例

psql 配置和执行监听/通知序列

LISTEN virtual;
NOTIFY virtual;
Asynchronous notification "virtual" received from server process with PID 8448.

兼容性

SQL 标准中没有 LISTEN 语句。

提交更正

如果您在文档中发现任何错误、与您对特定功能的体验不符或需要进一步澄清的内容,请使用 此表格 报告文档问题。