NOTIFY notifyname |
The NOTIFY command sends a notify event to each frontend application that has previously executed LISTEN notifyname for the specified notify condition in the current database.
The information passed to the frontend for a notify event includes the notify condition name and the notifying backend process's PID. It is up to the database designer to define the condition names that will be used in a given database and what each one means.
Commonly, the notify condition name is the same as the name of a table in the database, and the notify event alerts all frontends and backends that the table has been modified. No such association is enforced by the NOTIFY and LISTEN commands. For example, a database designer could use several different condition names to signal different sorts of changes to a single table.
NOTIFY provides a simple form of signal or interprocess communication (IPC) mechanism for a collection of processes accessing the same PostgreSQL database. Higher-level mechanisms can be built by using tables in the database to pass additional data (beyond a mere condition name) from notifier to listener(s).
If you use NOTIFY to signal the occurrence of changes to a particular table, you can use NOTIFY in a rule that is triggered by table updates. As a result, notification will happen automatically whenever the table is changed.
NOTIFY interacts with SQL transactions in some important ways. If a NOTIFY is executed inside a transaction, the notify events are not delivered until the transaction is committed. If the transaction is aborted, the commands within it to have had no effect, including NOTIFY. This can be disconcerting if you are expecting the notify events to be delivered immediately.
If a listening backend receives a notify signal while it is within a transaction, the notify event will not be delivered to its connected frontend until just after the transaction is completed (either committed or aborted). Again, the reasoning is that if a notify were delivered within a transaction that was later aborted, you would want the notification to be undone somehow — but the backend cannot "take back" a notify once it has sent it to the frontend. Notify events are only delivered between transactions. As a result, applications using NOTIFY for real-time signaling should have brief transactions.
NOTIFY behaves like UNIX signals in one important respect: if the same condition name is signaled multiple times in quick succession, recipients may get only one notify event for several executions of NOTIFY. So it is a bad idea to depend on the number of notifies received. Instead, use NOTIFY to wake up applications that need to pay attention to something, and use a database object (such as a sequence) to keep track of what happened or how many times it happened.
name can be any string valid as a name; it need not correspond to the name of any actual table. If name is enclosed in double-quotes, it need not even be a syntactically valid name, but can be any string up to 31 characters long.