この仕組みを利用した接続は、実際には2つのステップで構成されていますが、アプリケーションから見たときには、1つのSQL接続に見えます。アプリケーションは、接続文字列にconmgrプロセスが動作するサーバのIPアドレスまたはホスト名（ほとんどの場合には“localhost”です）とポート番号、および、target_session_attrsパラメータを指定します。このとき接続先がconmgrプロセスであることを明示する必要はありません。なぜならば、クライアントドライバは、接続先がインスタンスであるかconmgrプロセスであるかを自動的に判定できるからです。
接続の第1段階では、アプリケーションからの接続要求を受け取ったクライアントドライバが、その接続文字列に指定された場所に接続します。最初はPostgreSQLが要求するプロトコルを使用し、接続先がconmgrプロセスであることを途中で知ったならば、接続パラメータtarget_session_attrsに指定された属性を持つインスタンスが待ち受けるIPアドレスとポート番号をconmgrプロセスに要求します。接続先がconmgrプロセスでなくbackendプロセスならば、接続処理はただちに完了し、そのまま通常のSQL実行のデータ送受信を続けるだけです。なお、第1段階の処理は、各クライアントドライバによる、SQL接続処理に対するタイムアウト監視の対象範囲に入ります。例えば、libpqの接続パラメータconnection_timeoutです。
接続の第2段階では、conmgrプロセスから得たIPアドレスとポート番号を使って、クライアントドライバがインスタンスへ接続します。以降は、クライアントドライバとインスタンスがSQL実行のためのデータを直接、送受信します。これによって、Connection ManagerがSQL実行の性能に影響を与えないことが保証されます。
クライアントドライバは、第2段階が終了した以降にデータ受信待ちになったときに、接続時の各段階で得た2つのソケットへのデータ受信を監視します。これによって、例えばconmgrプロセスがネットワークのリンクダウンをクライアントに通知したときに、クライアントドライバがその通知を認識することができます。
