來源：http://www.postgres.cn/docs/11/ 13.2.1. 讀已提交隔離級別 讀已提交是PostgreSQL中的預設隔離級別。 當一個事務運行使用這個隔離級別時， 一個查詢（沒有FOR UPDATE/SHARE子句）只能看到查詢開始之前已經被提交的數據， 而無法看到未提交的 ...
來源：http://www.postgres.cn/docs/11/
13.2.1. 讀已提交隔離級別
讀已提交是PostgreSQL中的預設隔離級別。 當一個事務運行使用這個隔離級別時， 一個查詢（沒有FOR UPDATE/SHARE子句）只能看到查詢開始之前已經被提交的數據， 而無法看到未提交的數據或在查詢執行期間其它事務提交的數據。實際上，SELECT查詢看到的是一個在查詢開始運行的瞬間該資料庫的一個快照。不過SELECT可以看見在它自身事務中之前執行的更新的效果，即使它們還沒有被提交。還要註意的是，即使在同一個事務里兩個相鄰的SELECT命令可能看到不同的數據， 因為其它事務可能會在第一個SELECT開始和第二個SELECT開始之間提交。
13.3.2. 行級鎖
除了表級鎖以外，還有行級鎖，在下文列出了行級鎖以及在哪些情境下PostgreSQL會自動使用它們。行級鎖的完整衝突表請見表 13.3。註意一個事務可能會在相同的行上保持衝突的鎖，甚至是在不同的子事務中。但是除此之外，兩個事務永遠不可能在相同的行上持有衝突的鎖。行級鎖不影響數據查詢，它們只阻塞對同一行的寫入者和加鎖者。
行級鎖模式
FOR UPDATE-
FOR UPDATE會導致由SELECT語句檢索到的行被鎖定，就好像它們要被更新。這可以阻止它們被其他事務鎖定、修改或者刪除，一直到當前事務結束。也就是說其他嘗試UPDATE、DELETE、SELECT FOR UPDATE、SELECT FOR NO KEY UPDATE、SELECT FOR SHARE或者SELECT FOR KEY SHARE這些行的事務將被阻塞，直到當前事務結束。反過來，SELECT FOR UPDATE將等待已經在相同行上運行以上這些命令的併發事務，並且接著鎖定並且返回被更新的行（或者沒有行，因為行可能已被刪除）。不過，在一個REPEATABLE READ或SERIALIZABLE事務中，如果一個要被鎖定的行在事務開始後被更改，將會拋出一個錯誤。進一步的討論請見第 13.4 節。任何在一行上的
DELETE命令也會獲得FOR UPDATE鎖模式，在某些列上修改值的UPDATE也會獲得該鎖模式。當前UPDATE情況中被考慮的列集合是那些具有能用於外鍵的唯一索引的列（所以部分索引和表達式索引不被考慮），但是這種要求未來有可能會改變。
