67) Because readers in Postgres don't lock data, regardless of transaction isolation level, data read by one transaction can be overwritten by another. In the other words, if a row is returned by SELECT it doesn't mean that this row really exists at the time it is returned (i.e. sometime after the statement or transaction began) nor that the row is protected from deletion or update by concurrent transactions before the current transaction does a commit or rollback.
ところで，Postgres では どのようなトランザクションの隔離レベルが設定されていても，読み込み処理 に関してはデータのロックをしないので，あるトランザクションが読み込んだデータを， 他のトランザクションが書き換えてしまうことも起こり得ます． いいかえれば， SELECT 文で行が返されたとしても，それは 行が返された時点で（つまり，文あるいはトランザクション開始後のある時点で） その行が実際に存在していることを意味してはいませんし， また，このトランザクションがコミット／ロールバックされるまで，同時に 実行されているトランザクションによる削除や更新から保護されている，という ことでもないのです．
68) To ensure the actual existance of a row and protect it against concurrent updates one must use SELECT FOR UPDATE or an appropriate LOCK TABLE statement. This should be taken into account when porting applications using serializable mode to Postgres from other environments.
したがって， SELECT FOR UPDATE か，適切な LOCK TABLE 文を使用することで， 確実に行が存在するようにしておき，また同時に実行される他の更新から 行を保護します． このことは，シリアライザブルレベルを使ったアプリケーションを Postgres 以外の環境から， Postgres へとポーティングする際には考慮すべきです．
Note: 69) Before version 6.5 Postgres used read-locks and so the above consideration is also the case when upgrading to 6.5 (or higher) from previous Postgres versions.
バージョン 6.5 以前の Postgres は読み込み ロックを使用していたので，上記事項は以前のバージョンから， バージョン 6.5 （またはそれ以上）の Postgres に バージョンアップする場合にも適用されます．