LISTEN — 监听通知
LISTEN channel
LISTEN 将当前会话注册为名为 channel 的通知通道上的监听器。如果当前会话已注册为该通知通道的监听器，则不执行任何操作。
每当命令 NOTIFY 被调用时，无论是由该会话还是连接到同一数据库的另一个会话调用的，当前正在该通知通道上监听的所有会话都会收到通知，并且每个会话都会依次通知其连接的客户端应用程序。channel
可以使用 UNLISTEN 命令取消会话对给定通知通道的注册。会话结束时，其监听注册会自动清除。
客户端应用程序必须使用的方法来检测通知事件取决于它使用的 PostgreSQL 应用程序编程接口。使用 libpq 库时，应用程序会将 LISTEN 作为普通 SQL 命令发出，然后必须定期调用函数 PQnotifies 以找出是否已收到任何通知事件。其他接口（如 libpgtcl）提供了处理通知事件的高级方法；事实上，使用 libpgtcl 时，应用程序程序员甚至不应该直接发出 LISTEN 或 UNLISTEN。有关更多详细信息，请参阅您正在使用的接口的文档。
channel通知通道的名称（任意标识符）。
LISTEN 在事务提交时生效。如果在稍后回滚的事务中执行 LISTEN 或 UNLISTEN，则正在监听的通知通道集将保持不变。
已执行 LISTEN 的事务无法准备用于两阶段提交。
在首次设置监听会话时存在竞争条件：如果并发提交的事务正在发送通知事件，那么新监听会话将收到其中的哪一个？答案是，该会话将收到在事务提交步骤期间某个时刻之后提交的所有事件。但这稍晚于事务在查询中可能观察到的任何数据库状态。这导致了使用 LISTEN 的以下规则：首先执行（并提交！）该命令，然后在新事务中根据应用程序逻辑需要检查数据库状态，然后依靠通知来了解数据库状态的后续更改。收到的前几个通知可能引用在初始数据库检查中已观察到的更新，但这通常是无害的。
NOTIFY 包含对 LISTEN 和 NOTIFY 使用的更广泛讨论。
从 psql 配置并执行监听/通知序列
LISTEN virtual; NOTIFY virtual; Asynchronous notification "virtual" received from server process with PID 8448.
SQL 标准中没有 LISTEN 语句。