アプリケーションレベルでのデータの一貫性チェックPostgreSQLでのデータ読みとりはデータをロックしないので、トランザクションの隔離レベルに関係なく、あるトランザクションで読み込まれたデータは、同時に実行されているもう一方のトランザクションによって書き変えられる可能性があります。最新であるということを意味していません。このトランザクションが開始した後であっても別のトランザクションがコミットしたことで、見ている行は更新、もしくは削除されてしまっている可能性があります。「今」その行が有効であったとしても、現在実行中のトランザクションがコミットまたはロールバックで完了する前に(別のトランザクションによって)変更されたり、削除される可能性があります。各々のトランザクションは特定のデータベースの内容のスナップショットを参照していて、同時に実行されているトランザクションが異なったスナップショットを参照している可能性が十分にありうると考えることもできます。したがって、どちらにしても「今」という概念は少々疑わしいものとなります。これは通常、それぞれのクライアントアプリケーションがお互いに隔離されている場合は大きな問題ではありませんが、クライアントどうしがデータベースの外で何かのチャンネルを使用して通信できる場合は大きな問題となります。テーブル全体をロックします)。これはPostgreSQLに他の環境からアプリケーションを移植するときに考慮されなければなりません。以前のものからバージョンアップする際には上記の対象となります。おいてはグローバル有効性チェックに特別な考慮を払わなければなりません。銀行のアプリケーションで、テーブルにあるすべての貸方の合計が、別のテーブルにある借方の合計と同じであることをチェックする必要があるとします。この両方のテーブルは常に更新されています。番目の問い合わせは、おそらく最初の問い合わせによってカウントされなかったトランザクションの結果を含んでいるため、リードコミッティドモードでは信頼のおける処理を実行できないことが分かります。つの合計を出力すると、シリアライザブルトランザクションが開始される前にコミットされたトランザクション結果の正確な状況を得ることができます。その結果がもたらされた時点でもなお妥当であるかどうかは、実際には疑わしいかもしれません。整合性チェックを行なう前にシリアライザブルトランザクション自身が変更を行なった場合、そのチェックの有効性はさらに疑わしくなります。これにより、トランザクション開始後に行なわれる変更のすべてではなく、その一部だけが含まれるためです。このような場合、注意深い人であれば、現状を確実に把握するためにチェックに必要なすべてのテーブルをロックするでしょう。ロックにより、現在のトランザクションでの変更を除き、ロックされたテーブルにコミットされていない変更が存在しないことが保証されます。明示的なロックを使用して、同時に変更が実行されるのを防ごうとする場合、リードコミッティドモードを使用すべきであることに注意してください。シリアライザブルモードを使用する場合は、問い合わせを実行する前にロックを獲得するよう留意してください。シリアライザブルトランザクションにおいて獲得された明示的なロックは、テーブルに変更をかける他のトランザクションが現在実行されていないことを保証します。トランザクションが参照しているスナップショットが、ロックの獲得より前に取得されたものであれば、そのスナップショットは現時点においてコミットされている変更より前のテーブルのものである可能性があります。開始された時点で取得されます。したがって、スナップショットを取得する前に、明示的なロックを獲得することは可能です。ロックとインデックス。