Postgres supports
asynchronous notification via the LISTEN
and NOTIFY commands. A backend registers
its interest in a particular semaphore with the LISTEN command. All backends that are listening on
a particular named semaphore will be notified asynchronously when
a NOTIFY of that 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.

Note: In the past, the documentation has associated
the names used for asyncronous notification with relations or
classes. However, there is in fact no direct linkage of the
two concepts in the implementation, and the named semaphore
in fact does not need to have a corresponding relation
previously defined.

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. 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 PgDatabase::Notifies to see if any notification
data is currently available from the backend. PgDatabase::Notifies returns the notification
from a list of unhandled notifications from the backend. The
function eturns NULL if there is no pending notifications from
the backend. PgDatabase::Notifies
behaves like the popping of a stack. Once a notification is
returned from PgDatabase::Notifies, it
is considered handled and will be removed from the list of
notifications.

PgDatabase::Notifies retrieves
pending notifications from the server.

PGnotify* PgDatabase::Notifies()

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

Submit correction

If you see anything in the documentation that is not correct, does not match
your experience with the particular feature or requires further clarification,
please use
this form
to report a documentation issue.