Using connection pooling in your application

Connection Manager Authentication の接続プーリングで動作するようにアプリケーションを調整します。

プーリングの有効化と操作に関するDBAガイダンスについては、 Configuring connection pooling を参照してください。

アクティブプールモードの理解

bdr.node_group_summary を照会して、アクティブなプールモードを確認します。

SELECT node_group_name, server_pool_mode FROM bdr.node_group_summary;

プールモードは、トランザクション間でどのセッション状態を持続するかを決定します。

Feature	none/session	transaction with discard_all reset mode	transaction with fast reset mode
SET changes persist	Yes	No	Not guaranteed
PREPARE/EXECUTE statements persist	Yes	No	Not guaranteed
Temporary tables persist	Yes	No	Not guaranteed
Advisory locks across transactions	Yes	No	Not guaranteed
Holdable cursors (WITH HOLD)	Yes	No	Not guaranteed
LISTEN subscriptions	Yes	No	Not guaranteed

none およびsession モードでは、アプリケーションは、ほとんどの場合Postgres直接接続の場合と同じように動作します。例外は、接続マネージャーが特定の接続パラメーターのセットのみをバックエンドに転送することです。詳細は、 セッションパラメーターの管理 を参照してください。 none とsession の違いはインフラレベルです。session モードでは、クライアントが切断した後にバックエンド接続が再利用され、サーバーオーバーヘッドが削減されますが、これはアプリケーションには見えません。

transaction モードでは、トランザクションが終了するとバックエンド接続はプールに戻り、グループのserver_reset_mode はセッション状態をクリアするかどうかを決定します。デフォルトのdiscard_all モードはこれをクリアするため、次のトランザクションはクリーンに開始されます。 fast モードは、必要な場合を除き、クリーンアップをスキップするため、状態が別のクライアントのトランザクションにリークする可能性があります。いずれの場合も、トランザクション間で存続するセッション状態に依存するアプリケーションコードを作成しないでください。 リセットモードの構成 および Connection pooling's unsupported features を参照してください。

アプリケーションがこれらの機能に依存している場合は、 DBAに session またはnone モード Configuring connection pooling を参照してください 、または影響を受けるコードパスを再設計して、単一のトランザクション内のすべての状態を維持します。

アプリケーションをトランザクションモードに適応させる

Postgresの直接接続で動作する一部のアプリケーションパターンは、トランザクションモードでの調整が必要です。

セッションパラメーターの管理

接続マネージャーは、特定の接続パラメーターのセットをバックエンドに転送し、トランザクションモードでの新しいバックエンドの割り当てごとにそれらを再適用します。認識するパラメーターはclient_encoding 、DateStyle 、TimeZone 、standard_conforming_strings 、application_name 、search_path 、およびextra_float_digits です。

これらをSET コマンドではなく接続文字列で設定して、プールが割り当てるすべてのバックエンドに適用されるようにします。

host=myhost dbname=mydb options=-c search_path=myschema -c work_mem=256MB

またはURIで。

postgresql://myhost/mydb?options=-c%20search_path%3Dmyschema%20-c%20work_mem%3D256MB

認識されるリストの外部のパラメーターは、 options 接続パラメーターを介して渡されない限り、バックエンドの変更に再適用されません。

プリペアドステートメントを使用する

接続マネージャーは、バックエンドで欠落しているプリペアドステートメントを自動的に検出し、オンデマンドで再準備するため、拡張クエリプロトコルを介して送信されるプリペアドステートメントは、トランザクション間でシームレスに動作します。ほとんどのクライアントライブラリは、デフォルトで拡張クエリプロトコルを使用します。

デフォルトのdiscard_all リセットモードでは、各トランザクションの最後にバックエンド接続がプールに返されたときにDISCARD ALL が実行され、PREPARE /EXECUTE SQLステートメントで作成されたプリペアドステートメントの割り当てが解除されます。 fast リセットモードでは、このような準備されたステートメントは、それを作成したトランザクションを超えてバックエンドで生き残ることができますが、そのバックエンドに割り当てられる次のトランザクションは同じクライアントからであることが保証されていないため、それに依存してまだ存在することはできません。安全ではありません。いずれの場合もエラーを回避するには、次のプラクティスに従ってください。

• PREPARE 、EXECUTE 、およびDEALLOCATE SQLステートメントは避けます。代わりに拡張クエリープロトコルを使用します。ほとんどのクライアントライブラリはデフォルトで使用します。

• PREPARE /EXECUTE /DEALLOCATE SQLステートメントを使用する必要がある場合は、使用するトランザクション内で発行します。