PostgreSQL 應(yīng)用級別的數(shù)據(jù)完整性檢查

如果可序列化事務(wù)隔離級別被用于所有需要一個一致數(shù)據(jù)視圖的寫入和讀取，不需要其他的工作來保證一致性。在PostgreSQL中，來自于其他環(huán)境的被編寫成使用可序列化事務(wù)來保證一致性的軟件應(yīng)該“只工作”在這一點上。

當使用這種技術(shù)時，如果應(yīng)用軟件通過一個框架來自動重試由于序列化錯誤而回滾的事務(wù)，它將避免為應(yīng)用程序員帶來不必要的負擔。把default_transaction_isolation設(shè)置為serializable可能是個好主意。通過觸發(fā)器中的事務(wù)隔離級別檢查來采取某些動作來保證沒有其他事務(wù)隔離級別被使用（由于疏忽或者為了破壞完整性檢查）也是明智的。

性能建議見第 13.2.3 節(jié)。

當可以使用非可序列化寫時，要保證一行的當前有效性并保護它不受并發(fā)更新的影響，我們必須使用SELECT FOR UPDATE、SELECT FOR SHARE或一個合適的LOCK TABLE 語句（SELECT FOR UPDATE和SELECT FOR SHARE鎖只針對并發(fā)更新返回行，而 LOCK TABLE會鎖住整個表）。當從其他環(huán)境移植應(yīng)用到PostgreSQL時需要考慮這些。

關(guān)于這些來自其他環(huán)境的轉(zhuǎn)換還需要注意的是SELECT FOR UPDATE不保證一個并發(fā)事務(wù)將不會更新或刪除一個被選中的行。要在PostgreSQL中這樣做，你必須真正地更新該行，即便沒有值需要被改變。SELECT FOR UPDATE 臨時阻塞其他事務(wù)，讓它們不能獲取該相同的鎖或者執(zhí)行一個會影響被鎖定行的 UPDATE或DELETE，但是一旦正持有該所鎖的事務(wù)提交或回滾，一個被阻塞的事務(wù)將繼續(xù)執(zhí)行沖突操作，除非當鎖被持有時一個該行的實際UPDATE被執(zhí)行。

在非可序列化MVCC環(huán)境下，全局有效性檢查需要一些額外的考慮。例如，一個銀行應(yīng)用可能會希望檢查一個表中的所有扣款總和等于另外一個表中的收款總和，同時兩個表還會被更新。比較兩個連續(xù)的在讀已提交模式下不會可靠工作的SELECT sum(...)命令， 因為第二個查詢很可能會包含沒有被第一個查詢考慮的事務(wù)提交的結(jié)果。在一個單一的可重復讀事務(wù)里進行兩個求和則給出在可串行化事務(wù)開始之前提交的所有事務(wù)產(chǎn)生的準確結(jié)果 — 但有人可能會合理地置疑在結(jié)果被遞交的時候，它們是否仍然相關(guān)。 如果可重復讀事務(wù)本身在嘗試做一致性檢查之前應(yīng)用了某些變更，那么檢查的有用性就更加值得討論了， 因為現(xiàn)在它包含了一些（但不是全部）事務(wù)開始后的變化。 在這種情況下，一個小心的人可能希望鎖住所有需要檢查的表，這樣才能獲得一個無可置疑的當前現(xiàn)狀的圖像。 一個SHARE模式（或者更高）的鎖保證在被鎖定表中除了當前事務(wù)所作的更改之外，沒有未提交的更改。

還要注意如果某人正在依賴顯式鎖定來避免并發(fā)更改，那么他應(yīng)該使用讀已提交模式， 或者是在可重復讀模式里在執(zhí)行命令之前小心地獲取鎖。 在可重復讀事務(wù)里獲取的鎖保證了不會有其它修改該表的事務(wù)正在運行，但是如果事務(wù)看到的快照在獲取鎖之前， 那么它可能早于表中一些現(xiàn)在已經(jīng)提交的更改。 一個可重復讀事務(wù)的快照實際上是在它的第一個查詢或者數(shù)據(jù)修改命令（SELECT、INSERT、UPDATE或 DELETE）開始的時候凍結(jié)的，因此我們可以在快照凍結(jié)之前顯式地獲取鎖。