LISTEN

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

每当命令 NOTIFY channel 被执行时，无论是由当前会话还是由另一个连接到同一数据库的会话执行，所有当前正在监听该通知通道的会话都会收到通知，而每个会话随后都会通知其所连接的客户端应用。

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

客户端应用必须采用何种方法来检测通知事件，取决于它所使用的 PostgreSQL 应用程序编程接口。使用 libpq 库时，应用程序将 LISTEN 作为普通 SQL 命令发出，然后必须定期调用 PQnotifies 函数，以判断是否已经收到任何通知事件。其他接口，例如 libpgtcl，则提供了处理通知事件的更高层方法；事实上，在 libpgtcl 中，应用程序员甚至不应直接发出 LISTEN 或 UNLISTEN。详见所使用接口的相关文档。

LISTEN 会在事务提交时生效。如果在随后被回滚的事务中执行了 LISTEN 或 UNLISTEN，则被监听的通知通道集合不会发生变化。

执行过 LISTEN 的事务不能进入两阶段提交的预备状态。

第一次建立监听会话时存在一个竞争条件：如果并发提交的事务正在发送通知事件，那么新开始监听的会话究竟会收到其中哪些事件？答案是，该会话会收到那些在其事务提交步骤中的某个时刻之后提交的所有事件。但这个时刻会略晚于该事务通过查询所能观察到的任何数据库状态。因此，使用 LISTEN 时应遵循如下规则：先执行该命令并提交，然后在一个新事务中按照应用逻辑的需要检查数据库状态，之后再依靠通知来获知数据库状态的后续变化。最初收到的几个通知，可能对应于初次检查数据库时已经观察到的更新，但这通常无害。

NOTIFY 中对 LISTEN 和 NOTIFY 的使用有更详细的讨论。

在 psql 中配置并执行一组 listen/notify 操作：

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

SQL 标准中没有 LISTEN 语句。