Asynchronous Notification

Postgres supports asynchronous notification via the LISTEN and NOTIFY commands. A backend registers its interest in a particular relation with the LISTEN command. All backends listening on a particular relation will be notified asynchronously when a NOTIFY of that relation name is executed by another backend. No additional information is passed from the notifier to the listener. Thus, typically, any actual data that needs to be communicated is transferred through the relation. libpq applications are notified whenever a connected backend has received an asynchronous notification. However, the communication from the backend to the frontend is not asynchronous. Notification comes piggy-backed on other query results. Thus, an application must submit queries, even empty ones, in order to receive notice of backend notification. In effect, the libpq application must poll the backend to see if there is any pending notification information. After the execution of a query, a frontend may call PQNotifies to see if any notification data is available from the backend.

• PQNotifies returns the notification from a list of unhandled notifications from the backend. Returns NULL if there are no pending notifications from the backend. PQNotifies behaves like the popping of a stack. Once a notification is returned from PQnotifies, it is considered handled and will be removed from the list of notifications.

  PGnotify* PQNotifies(PGconn *conn);

  The second sample program gives an example of the use of asynchronous notification.