彼は次のリリースを忘れませんでした。 彼のブログには、すでにWaiting for 9.0シリーズの 34の投稿があります。 ポーランドの兄弟に遅れずについていくことは不可能のように思われます。 しかし、もう一度リリースノートを見ると、注目を集めていない貴重な革新が見つかりました。 つまり、 LISTEN / NOTIFYメカニズムの新しい実装です。
事実から始めましょう。 そして、結論として、この機能の実装に伴う熱狂的な生活について説明します。
内部NOTIFY / LISTEN実装の置き換え
現時点（バージョン8.x以前）では、メカニズムは
pg_listener
システムテーブルを使用して通知を保存します。 通知を待っているすべての「リスナー」が含まれています。 必要に応じて、テーブルがスキャンおよび更新されます。
新しいバージョンでは、これらはすべてRAMにあるキューの形式で実装されます。 まず、速度が大幅に向上します。 次に、この実装はホットスタンバイメカニズムと互換性があります。 ただし、現時点では、HSスレーブがマスターから通知を受信する可能性はありませんが、今後の実装が計画されていることに注意してください。
ペイロード
最後に、開発者は、NOTIFYコマンドに2番目のパラメーター、いわゆる「ペイロード」（ペイロード）を追加しました。 実行計画は、地球の大空の創造の前でした。
この追加情報は、最大8000文字の通常の文字列です。 日常のニーズについては、頭で十分だと思います。 ビッグデータの場合、テーブルに保存し、通知にレコード識別子を送信することをお勧めします。
主なものについて簡単に
- NOTIFYがトランザクション内で実行される場合、トランザクションが完了するまで通知は送信されません（COMMIT）。
- 「リスニング」セッションがトランザクション中に通知信号を受信した場合、トランザクション自体の結果（COMMITまたはROLLBACK）に関係なく、トランザクションが完了すると通知自体がクライアントに配信されます。
- 通知が重複している場合（同じチャネル名と追加情報）、サーバーは複数の通知を1つにまとめることができます。
- 異なるトランザクションからの通知は、複製の場合でも結合せずに「そのまま」配信されます。
- 通知は、送信された順に配信されます。 トランザクションの場合、通知はトランザクションの完了順に配信されます。
- チャンネル名または情報を文字列として表現できない場合、
pg_notify(text, text)
関数を使用すると便利です。 例えば
SELECT pg_notify(current_user, 'pay' || 'load');
- 通知キューは8GBに制限されています。 （ほとんど不可能であるが）いっぱいになると、キューをオーバーフローしたトランザクションはロールバックされます。
どうでしたか
前述したように、NOTIFYコマンド形式に新しいパラメーターを追加することは、最初はTODOリストに含まれていました。 どうやら、開発者は、現在の形ではこの機能が栄誉を主張するものではないことを理解していました。 しかし、実装に必要な作業量は恐ろしいものでした。
2009年11月11日、Joachim Wielandは、通知メカニズムの新しい実装を含むパッチを公開しました。 この第1版では、追加情報（ペイロード）のサイズは128文字に制限され、多くの文字がひっくり返っていました。
著者は、追加のパラメーターの長さを長くすることについて、オープンな嘆願の手紙を受け取りました。 そして要塞が倒れました。 現在の8000文字のサイズは、内部制限によってのみ決定されます。
パッチディスカッションスレッドは合計63文字をカウントしました。 世界的な問題は解決されました。 コミュニティは、数日後にヨアヒムが詳細に取り組んだときに復活しました。 「キューがいっぱいになったときに何をすべきか」という単純な質問は、感情の嵐を引き起こしました。 オーバーフロー状況自体は決して現れない可能性が高いという事実にもかかわらず。 結局、このためには、サーバーに2,147,483,647個以上の通知が蓄積されている必要があります（導入された8GBの制限により、現在では少なくなっています）。
慈悲の聖戦のログを楽しみたい方は、 アーカイブしてください。
誰がこれを必要としますか？
誰もが自分でこの質問に答えるべきです。 追加のパラメーターの存在は、新しい視野を開きます。 この時点までにクライアントが変更に関する正式なニュースのみを受け取っていた場合、サーバーで追加のリクエストを実行することなく、何が起きたかの本質について知る機会が得られます。
％usernameが必要ですか？