Postgresql 中文操作指南
Description
LISTEN 将当前会话注册为名为 channel 的通知通道上的侦听器。如果当前会话已作为该通知通道的侦听器注册，则不会执行任何操作。
LISTEN registers the current session as a listener on the notification channel named channel. If the current session is already registered as a listener for this notification channel, nothing is done.
每当通过本会话或连接到同一数据库的另一个会话调用命令 NOTIFY _channel_ 时，当前在该通知通道上侦听的所有会话都会收到通知，并且每个会话都会依次通知其连接的客户端应用程序。
Whenever the command NOTIFY _channel_ is invoked, either by this session or another one connected to the same database, all the sessions currently listening on that notification channel are notified, and each will in turn notify its connected client application.
可以使用 UNLISTEN 命令取消注册会话对给定通知通道的注册。当会话结束时，将自动清除会话的侦听注册。
A session can be unregistered for a given notification channel with the UNLISTEN command. A session’s listen registrations are automatically cleared when the session ends.
客户端应用程序必须使用的方法来检测通知事件取决于它使用哪个 PostgreSQL 应用程序编程接口。使用 libpq 库时，应用程序会将 LISTEN 作为普通 SQL 命令发出，然后必须定期调用函数 PQnotifies 以找出是否收到了任何通知事件。libpgtcl 等其他界面为处理通知事件提供了更高级别的方法；实际上，使用 libpgtcl 时，应用程序员甚至不应该直接发出 LISTEN 或 UNLISTEN 。有关更多详细信息，请参阅您正在使用的界面的文档。
The method a client application must use to detect notification events depends on which PostgreSQL application programming interface it uses. With the libpq library, the application issues LISTEN as an ordinary SQL command, and then must periodically call the function PQnotifies to find out whether any notification events have been received. Other interfaces such as libpgtcl provide higher-level methods for handling notify events; indeed, with libpgtcl the application programmer should not even issue LISTEN or UNLISTEN directly. See the documentation for the interface you are using for more details.
Notes
LISTEN 在事务提交时生效。如果在稍后回滚的事务中执行 LISTEN 或 UNLISTEN ，正在侦听的通知通道集合将保持不变。
LISTEN takes effect at transaction commit. If LISTEN or UNLISTEN is executed within a transaction that later rolls back, the set of notification channels being listened to is unchanged.
已执行 LISTEN 的事务无法准备进行两阶段提交。
A transaction that has executed LISTEN cannot be prepared for two-phase commit.
在第一次设置侦听会话时会出现一个竞争条件：如果并发提交事务正在发送通知事件，新侦听会话将精确接收到哪些事件？答案是会话将接收在事务提交步骤期间某个瞬间之后提交的所有事件。但它稍晚于事务在查询中可以观察到的数据库状态。这导致了使用 LISTEN 的以下规则：首先执行（并提交！）该命令，然后在新事务中根据应用程序逻辑检查数据库状态，然后依靠通知来了解后续的数据库状态更改。最早收到的几个通知可能指的是在初始数据库检查中已经观察到的更新，但这通常是无害的。
There is a race condition when first setting up a listening session: if concurrently-committing transactions are sending notify events, exactly which of those will the newly listening session receive? The answer is that the session will receive all events committed after an instant during the transaction’s commit step. But that is slightly later than any database state that the transaction could have observed in queries. This leads to the following rule for using LISTEN: first execute (and commit!) that command, then in a new transaction inspect the database state as needed by the application logic, then rely on notifications to find out about subsequent changes to the database state. The first few received notifications might refer to updates already observed in the initial database inspection, but this is usually harmless.
NOTIFY 对使用 LISTEN 和 NOTIFY 做了更广泛的讨论。
NOTIFY contains a more extensive discussion of the use of LISTEN and NOTIFY.