2015-11-19 18 views
6

トランザクションを開始したが、コミットしたりロールバックしたりしないアプリケーションコードにバグが見つかりました。接続は定期的に使用され、10秒ごとにデータを読み取るだけです。 pg_stat_activityテーブルでは、その状態は「アイドル・トランザクションで」報告され、そのbackend_start時間は1週間以上前です。データベーストランザクションを終了しないとどうなるのですか?

これにはどのような影響がありますか? CPUとRAMの使用量が増えますか?それは他の接続に影響を与えますか?この状態でどれぐらい持続することができますか?

私はpostgresql 9.1と9.4を使用しています。

+0

影響:1.あなたのデータは他のトランザクションには見えません2。最終的にコミットしないと、データが失われます。 – zerkms

+0

@zerkms私はサーバーの処理への影響にもっと関心があります。変更が行われた場合、他の接続では表示されないことに気づきます(この場合は、データの読み取りのみで、何も変更しません) – wolfcastle

+0

データを失うことはありません最終的にSAVEPOINTSを使用することができます。 – Madthew

答えて

10

を使用して変更することはできません。変更がコミットされるまで他のトランザクションには表示されず、決してコミットされない場合には失われる書き込み操作の方が重大です。

それは、コストいくつかのRAMないと永久にはあなたの許可された接続(または重要ではないかもしれない可能性がある)の1を占めます。

トランザクションが非常に長く実行されると、さらに深刻な結果になります。古い行が表示される古いトランザクションが存在するため、VACUUMはブロックします。システムが膨張し始める。

特に、SELECTは、すべての参照テーブルでACCESS SHAREロック(すべてのブロックが最も少ないブロック)を取得します。これは、他のDMLに干渉しないINSERTUPDATEまたはDELETEなどのコマンドが、それはブロックDDLはだけでなく、TRUNCATEまたは(自動バキュームジョブを含む)VACUUMをコマンドします。それは十分に長いオープン/あなたは十分に速く、十分なXIDを燃やす留まる場合See "Table-level Locks" in the manual.

それはまた、様々な複製ソリューションの妨げとトランザクションIDにつながることができますが、長期的にをラップアラウンド。その詳細についてはin the manual on "Routine Vacuuming"

ブロッキング効果マッシュルーム他のトランザクションがコミットをブロックされていて、自分でロックを取得している場合接続が閉じられるまで
しかし、長く必要以上に開いているトランザクションを離れることはない(サーバーは明らかに、再起動されたときにも起こりいる。) - など

あなたは(ほぼ)無限に開いているトランザクションを維持することができます。

+0

トランザクションで使用されるテーブル、またはすべてのテーブルのVACUUMをブロックするだけですか? – wolfcastle

+0

@wolfcastle:トランザクションで参照されているものだけです(どんな方法でも!)。その効果がきのこをすることができることに注意してください。 –

+2

実際、 'VACUUM'は仮想xidによって' ACCESS SHARE'のためにロックされたテーブルを処理できます。ただし、スペースをOSに戻すために切り捨てることはできません。トランザクションが 'SERIALIZABLE'であるか、または現在実行されている文がある場合、並行更新/削除によって作成された不通行を削除することはできません。自分で試してみてください。ダミー行を持つテーブルを作成します。 xactを開始し、テーブルから選択してロックします。別のxactを開始し、行の半分を削除しますが、まだコミットしないでください。他のセッションからの「VACUUM VERBOSE」。それは死んだ行を削除します。 –

3

システムに2つの大きな影響があります。これらのトランザクションで使用されている

テーブル:

  1. は、彼らが「クリーンアップ」されていないとその統計が悪い(=遅い)実行計画につながる可能性がある更新されていないことを意味するvacuumedではありません
  2. はあなただけSELECT、影響は限られているためALTER TABLE
関連する問題