Postgres は LISTEN と NOTIFY コマンドによる非同期通知機能をサポートしています． バックエンドは LISTEN コマンドを受け取ると， 特定の通知条件に関心を持ったことを登録します． （これを止めるには UNLISTEN コマンドを使います） 特定の条件を待っているすべてのバックエンドは， 同じ条件名の NOTIFY コマンドが任意のバックエンドによって実行された時点で 非同期的に通知を受けます． ただし通知の発行側から受信側へ渡される付加的な情報はありません． したがって，典型的には両者の間で受け渡す必要のある実際のデータは， データベースリレーションを通じて転送することになります． 一般的に，条件名は関連するリレーション名と同じものですが， 必ず関連するリレーションが必要とされるわけではありません．
libpq アプリケーションは， 通常の SQL による問い合わせと同じように LISTEN および UNLISTEN コマンドを発行することができます． 通知メッセージの到着は，続いて PQnotifies() を呼び出せば検出できます．
PQnotifies バックエンドから受信した通知メッセージのうち， まだ処理されていないもののリストから次の通知を返します． 保留中の通知がなくなれば NULL を返します． PQnotifies が通知を返すとその通知はもはや処理が済んだものとみなされ， 通知リストから取り除かれます．
PGnotify* PQnotifies(PGconn *conn);
typedef struct pgNotify
{
char relname[NAMEDATALEN]; /* データを含むリレーションの名前 */
int be_pid; /* バックエンドのプロセス ID */
} PGnotify;
メモリリークを防ぐため，PQnotifies が返した PGnotify オブジェクトの
処理が終ったら必ず free() で領域を開放してください．
注： 6.4 より前のバージョンでは，
be_pid が常に接続しているバックエンドのプロセス ID だったのに対し，
6.4 とそれ以降の Postgres
では通知を発行したバックエンドのプロセス ID になります．
なお，二番目のサンプルプログラムが非同期通知を使用した例です．
PQnotify は実際にバックエンドのデータを読み出すわけではありません． これは単に，他の libpq 関数が吸収してしまっていた通知メッセージを返すだけです． 以前のリリースの libpq だと， 通知メッセージを適切な時点で確実に受け取るには， 空の問い合わせでもなんでも，とにかく一定時間ごとに問い合わせを送り， そして PQexec() を実行するたびに PQnotify() をチェックするしかありませんでした． 今でもこの方法は動作しますが，処理能力の無駄使いをすることになるので やめておいてください． 実行するべき問い合わせがないときに通知メッセージをチェックするよい方法は， まず PQconsumeInput() を呼び出し，それから PQnotifies() をチェックすることです． バックエンドからのデータの到着を select(2) で待つことができ， 不必要な動作で CPU パワーを消費してしまうことがありません． なお，これは問い合わせに PQsendQuery と PQgetResult を使ったときでも， またはおなじみの PQexec を使ったときでも動作します． しかし通知が問い合わせの処理中に届いていないかどうか， PQgetResult，あるいは PQexec の実行ごとに PQnotifies() を調べることを 忘れないようにしておくべきです．