[11/15開催: PostgreSQL Conference Japan 2019 参加受付中] 
他のバージョンの文書 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

9.5. アプリケーションレベルでのデータの一貫性チェック

PostgreSQLでのデータ読みとりはデータをロックしないので、トランザクションの隔離レベルに関係なく、あるトランザクションで読み込まれたデータは、同時に実行されているもう一方のトランザクションによって書き変えられる可能性があります。つまり、SELECTで得た行は、その行が返ってきたとき(現在のトランザクションが開始されたあとのある時点)にも存在しているということを意味していません。このトランザクションが開始した後に、その行は別のトランザクションによって更新、または削除され、コミットされている可能性があります。「今」その行が有効であったとしても、現在実行中のトランザクションがコミットする、またはロールバックする以前に変更されたり、削除される可能性があります。

各々のトランザクションはデータベースの内容のスナップショットを参照していて、同時に実行されているトランザクションでは、違ったスナップショットを参照している可能性があると考えることもできます。したがって、どちらにしても「今」という概念は少々疑わしいものとなります。これは、クライアントアプリケーションが隔離されている場合は大きな問題ではありませんが、クライアントがデータベースの外の世界と何かのチャンネルを使用して通信できる場合は大きな問題となります。

現在存在する行を確実なものとし、同時に起こりうる更新を避けるためには、 SELECT FOR UPDATE文や、適切なLOCK TABLE 文を使用する必要があります(SELECT FOR UPDATE文は返ってきたデータのみを同時に起こる更新から保護し、LOCK TABLEはテーブル全体を保護します)。これはPostgreSQLに他の環境からアプリケーションを移植するときに考慮される必要があります。

Note: PostgreSQLバージョン6.5以前のものでは読み込みロックを使用しているので、PostgreSQLのバージョン6.5 以前のものからバージョンアップする際にも上記の考慮が必要となります。