博士

ロボ子、大変なのじゃ！JepsenがAmazon RDS for PostgreSQLのトランザクション可視性に関するレポートを出したみたいだぞ！

ロボ子

トランザクションの可視性ですか？それはまた、難しい話ですね。具体的にはどのような問題が報告されているのでしょうか？

博士

クラスタ構成で、プライマリとレプリカでトランザクションの可視順序が違うらしいのじゃ！データ損失や破損には繋がらないみたいだけど。

ロボ子

なるほど。シングルAZ PostgreSQLデプロイメントには存在しないとのことですが、マルチAZ構成特有の問題ということですね。

博士

そうみたいじゃな。しかも、Amazon Aurora PostgreSQL Limitless DatabaseやAmazon Aurora DSQLデータベースには影響しないらしいぞ。

ロボ子

影響範囲が限定的なのは不幸中の幸いでしょうか。しかし、トランザクションの順序が異なるというのは、一体どういうことなのでしょう？

博士

これは「Long Fork anomaly」として知られていて、Snapshot Isolationの違反とみなされるらしいのじゃ。2つのリーダーがトランザクションの結果を違う順序で観察する可能性があるんだと。

ロボ子

つまり、PostgreSQLのプライマリで、トランザクションの結果が可視になる順序が、永続化される順序と異なると…。

博士

そういうことじゃ！トランザクションの可視順序が、ログに記録されたコミット順序と常に一致するとは限らないらしいぞ。

ロボ子

それは怖いですね。データの整合性に影響はないとのことですが、アプリケーション側で予期せぬ挙動を引き起こす可能性はありそうですね。

博士

そうなんじゃ。このLong Fork anomalyは、PostgreSQLコミュニティでは長年知られていて、pgsql-hackersメーリングリストで議論されてきたらしいぞ。

ロボ子

コミュニティでも認知されていた問題なのですね。Amazon RDS特有の問題ではなく、自己管理のPostgreSQLデプロイメントでも再現可能とのことですが、全ての分離レベルに影響するのでしょうか？

博士

その通り！Read Committed、Repeatable Read、Serializable、全ての分離レベルに影響するらしいぞ。

ロボ子

それは広範囲ですね。AWSはPostgreSQLの成功に尽力しており、PostgreSQL Contributors Teamを結成して貢献しているとのことですが、今回の問題に対してはどのような対応を取るのでしょうか？

博士

AWSはPostgreSQLコミュニティと協力して、PostgreSQLのSnapshot Isolation anomalyに対処していくと言っているぞ。

ロボ子

頼もしいですね。私たちエンジニアとしては、どのような点に注意すべきでしょうか？

博士

ノードやエンドポイントを跨いだトランザクションの順序付けについて、暗黙的なコミット順序に依存すべきではないらしいぞ。厳密なトランザクションの順序付けが必要な場合は、共有カウンター、タイムスタンプ、データベース制約などの明示的な同期メカニズムを使うと良いみたいじゃ。

ロボ子

了解しました。明示的な同期メカニズムですね。肝に銘じておきます。

博士

しかし、ロボ子よ。トランザクションの順序がぐちゃぐちゃになるなんて、まるで私の部屋みたいじゃな！

ロボ子

博士、それは違います！博士の部屋は、トランザクションどころか、物理法則すら無視しているように見えます…。