定義上、コネクションプーラーはコネクションを再利用するから、PGに限らずどんなコネクションプーリングの設定でも起こり得るよ。pgbouncerでは、カスタマイズ可能なコマンド[0]を使ってコネクションをリセットするから、クリーンな状態に戻せるはずだよ。[0] https://www.pgbouncer.org/config.html#server_reset_query

そうだね、pgbouncerがPostgresのワイヤプロトコルに対してどれだけ透明性を持とうとしているかの結果だよ。このことをうまく説明している記事があるよ: https://www.augusteo.com/blog/how-pgbouncer-works

こういうのは「永続接続」をサポートしている他のデータベースでも見られるよ。起動するとき、データベースの状態が全くわからないからね。前のプロセスがエラーになってたら、壊れたトランザクションの真っ只中にいるかもしれない。前のセッションが何か変なSETマジックを使って動かしてた？一時テーブルを作ってた？まあ、全部そのまま残ってるからね！

PostgreSQLに特有の話じゃないよ。他の人も言ってるけど、MySQLのプーラーやプロキシでも同じことが起こる可能性がある。接続の挙動は動的に変わることができて、その接続のライフタイム中は持続するからね。例えば、レガシーなクライアントAがバウンサーを通じてMySQLに接続して「会話は全部latin-1を使いたい、utf-8じゃなくて」って言うと、MySQLがクエリを解析する際の文字セットが変わるんだ。レガシーなクライアントがいくつかクエリを実行してから切断すると、今度は新しいクライアントがMySQLに接続するんだけど、バウンサーは前の接続のまま割り当てちゃう。新しいクライアントは完全にUTF-8に対応してるし、デフォルトがそれだから明示的に言わないんだよね。ただ、データベースサーバーはまだlatin-1で考えてるから、新しいクライアントがUTF-8データを送ると、それがlatin-1として解析されちゃう。latin-1はUTF-8のサブセットだから、クエリは実際にはうまくいくけど、latin-1の範囲外の文字を使うとエラーが出たり、サーバーから壊れたデータが返ってきたりする。これを回避するための解決策は以下の通り。1. すべてのクライアントが同じ設定を使うことを確認する。もしデータベースが同じORMを使う単一のアプリ用なら、これは自動的にできる。2. すべてのクライアントが、必要な変更を毎回明示的に設定することを確認する。UTF-8クライアントは、デフォルトでも明示的にUTF-8接続を設定するし、utf8mb4が必要なクライアントはそれを明示的に要求する。これを確実にする一つの方法は、サーバー（またはバウンサー）を、誰にも有効でないデフォルトを使うように設定することだ。例えば、デフォルトの文字セットを7ビットのスウェーデン語に設定すると、頻繁にエラーが起こる。3. これらの変更を禁止するか、元のクライアントが切断された後に検出して元に戻すことができるバウンサーを使う。MySQL用にこれが存在するかは分からないけど。4. 異なるアプリケーションごとに別々のバウンサーを使う（#1の延長）。つまり、データベースサーバーのプールごとにバウンサーを持つのではなく、各アプリケーションごとに持つってこと。ウェブアプリには1つ、レガシーなレポートツールには1つ、ODBCコネクタには1つ、みたいに。理論上はかなりの混乱だけど、実際には多くのインストールが#1のケースに当てはまるから、あまり問題にならない。ただ、たまに問題になるときはデバッグがめちゃくちゃ難しくなる。

pgbouncerには、漏洩の可能性に影響を与えるいくつかのプールモードがあるよ。

まあ、正直言ってpgdogは見た目がめっちゃすごいし、マルチスレッドを超えてるよ。notify/listenの修正や、リードレプリカへの自動クエリルーティング、自動シャーディングがあれば、Postgresがついにvitessに近づくかもね。

一番厳密なCAP定理の定義から言うと、そうだね、トランザクショナルではない。でも、かなり近いよ。データベースの世界ではそれは良い答えじゃないって分かってるけど、実際には大多数のメッセージを届けるから、まあそれで十分かもね？どうなるか見てみよう。DBやアプリを壊さずに近づくことが可能だって示してるけど、まだ_耐久性_のあるワークキュー、例えばKafkaから期待されるレベルには達してないと思う。すぐにそれを置き換えることはないだろうね。

ないと思う。面倒すぎる。キャッシュは文脈なしでは本当に難しい問題で、通常その文脈はアプリ特有なんだよね。