<div dir="ltr"><div class="gmail_extra">お世話になっております。調査は難航中なのでしょうか？　レプリケーションモードかつロードバランスの使用者は極めて少ないかもしれませんが、一応、こちらのとった対策を投稿しておきます。</div><div class="gmail_extra"><br></div><div class="gmail_extra">この不具合は、これが起因となって、高負荷時や、開発時などSQLエラーが混じった状況で、クライアントへの応答がフリーズし、バックエンドへの接続が　idle in transaction のまま残り続け、システムの安定稼働を阻害します。</div><div class="gmail_extra"><br></div><div class="gmail_extra">こちらは以下の２点の修正をソースに加えることで、過去の2.2系統と同様の動作かつ安定稼働が可能となっております。</div><div class="gmail_extra"><br></div><div class="gmail_extra">　１．明示的なトランザクション内の　select を、全ノードに送付するように変更</div><div class="gmail_extra">　２．トランザクション内でのselect エラー発生時、１の変更により全てのノードに同じselectが送られているため、他のノードへエラーを発生させる処理は不要。バイパスするように変更。</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">当初、replicate_select をONにして新バージョンに対応しようとしましたが、以下の２点で断念しました。</div><div class="gmail_extra"><br></div><div class="gmail_extra">１．psql で、 \d  がエラーになりがちで使いづらい。（\d も常に両方のノードに送られてしまい、oid が異なっているとエラーとなるため。）</div><div class="gmail_extra"><br></div><div class="gmail_extra">２．常に select処理が両方のノードに送られるため、パフォーマンスが半分になってしまう。</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">以上<br></div></div>