读已提交是PostgreSQL中默认的隔离级别。当事务使用这一隔离级别时，SELECT查询（不带FOR UPDATE/SHARE子句）只能看到查询开始之前已经提交的数据；它既看不到未提交的数据，也看不到查询执行期间并发事务提交的更改。实际上，SELECT查询看到的是该查询开始运行瞬间的数据库快照。不过，SELECT能看到其自身事务中先前执行的更新效果，即使这些更新尚未提交。还要注意，即使两个连续的SELECT命令位于同一个事务中，如果其他事务在第一个SELECT执行期间提交了更改，这两个命令也可能看到不同的数据。

UPDATE、DELETE、SELECT FOR UPDATE 和 SELECT FOR SHARE 命令在搜索目标行时的行为与 SELECT 相同： 它们只会找到在命令开始时已经提交的目标行。不过，当找到这样的目标行时， 它可能已经被其他并发事务更新、删除或者锁定。在这种情况下，即将执行更新的事务会等待第一个更新事务提交或回滚 （如果它仍在进行中）。如果第一个更新事务回滚，那么它的作用将被撤销，第二个更新事务就可以继续更新最初找到的行。 如果第一个更新事务提交了，那么若该行已被第一个更新者删除，第二个更新事务就会忽略该行； 否则，第二个更新者将尝试在该行的已更新版本上应用自己的操作。 该命令的搜索条件（WHERE 子句）会被重新计算，以判断该行的已更新版本是否仍然符合搜索条件。 如果符合，则第二个更新者会基于该行的已更新版本继续执行操作。 对于 SELECT FOR UPDATE 和 SELECT FOR SHARE， 这意味着被锁住并返回给客户端的是该行的已更新版本。

由于上述规则，更新命令可能看到一个不一致的快照：它能够看到并发更新命令在它试图更新的同一行上的效果， 却看不到这些命令对数据库中其他行的影响。这种行为使得读已提交模式不适合涉及复杂搜索条件的命令； 不过，对于较简单的场景它恰到好处。例如，考虑以如下事务更新银行余额：

BEGIN;
UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 12345;
UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 7534;
COMMIT;

如果两个这样的事务并发地尝试更改账户 12345 的余额，我们显然希望第二个事务从该账户行的已更新版本开始。 因为每个命令只影响一个预先确定的行，让它看到该行的已更新版本不会造成任何麻烦的不一致。

在读已提交模式下，更复杂的用法可能产生不理想的结果。例如，考虑一个 DELETE 命令，另一个命令正在修改数据，使某些行开始满足其筛选条件、另一些行不再满足。 假设 website 是一个有两行的表，其中 website.hits 分别等于 9 和 10：

BEGIN;
UPDATE website SET hits = hits + 1;
-- 从另一个会话运行：  DELETE FROM website WHERE hits = 10;
COMMIT;

该 DELETE 将不会产生任何效果，即使在 UPDATE 之前和之后都存在一行 website.hits = 10。这是因为更新前值为 9 的那一行被跳过了，而当 UPDATE 完成并且 DELETE 获得锁时，新行值已经不再是 10 而是 11，因此不再匹配条件。

因为在读已提交模式中，每个命令都从一个新快照开始，而该快照包含截至当时已提交的所有事务， 所以同一事务中的后续命令无论如何都会看到并发事务已提交的效果。上面真正的问题在于， 单个命令是否能看到数据库的绝对一致视图。

读已提交模式所提供的部分事务隔离对于许多应用来说已经足够，而且这种模式既快速又容易使用。 不过，它并不能满足所有场景。执行复杂查询和更新的应用，可能需要比读已提交模式所提供的更严格一致的数据库视图。

可串行化隔离级别提供最严格的事务隔离。该级别模拟串行事务执行，就像事务是一个接一个串行执行而不是并发执行一样。不过，使用该级别的应用必须准备好在发生串行化失败时重试事务。

当事务使用可串行化级别时，SELECT查询只能看到事务开始之前已经提交的数据；它既看不到未提交的数据，也看不到事务执行期间并发事务提交的更改。（不过，查询能看到其自身事务中先前执行的更新效果，即使这些更新尚未提交。）这一点与读已提交不同：可串行化事务中的查询看到的是事务开始时刻的快照，而不是事务中当前查询开始时刻的快照。因此，单个事务中连续的SELECT命令看到相同的数据，也就是说，它们看不到在本事务启动之后由其他事务提交的更改。（这种行为对于报表类应用来说可能非常理想。）

UPDATE、DELETE、SELECT FOR UPDATE和SELECT FOR SHARE命令在搜索目标行方面的行为与SELECT相同：它们只会找到事务开始时刻已提交的目标行。然而，这样的目标行在被找到时，可能已经被另一个并发事务更新（或删除、锁定）。在这种情况下，可串行化事务将等待第一个更新事务提交或回滚（如果仍在进行）。如果第一个更新事务回滚，那么它的作用将被撤销，可串行化事务就可以继续更新最初找到的行。但如果第一个更新事务提交了（并且确实更新或删除了该行，而不仅仅是锁定它），那么可串行化事务将被回滚，并收到以下消息：

ERROR:  could not serialize access due to concurrent update

这是因为可串行化事务不能修改或锁定在它开始之后被其他事务更改过的行。

当应用收到这条错误消息时，应当中止当前事务，并从头重试整个事务。 第二次执行时，该事务会把先前已提交的更改视为其初始数据库视图的一部分， 因此以该行的新版本作为新事务更新的起点时，就不存在逻辑冲突。

注意，只有更新事务才可能需要重试；只读事务永远不会发生串行化冲突。

可串行化模式严格保证每个事务看到的都是完全一致的数据库视图。然而，当并发更新使得串行执行的假象无法维持时，应用必须准备好重试事务。由于重做复杂事务的代价可能相当可观，只有当更新事务包含的逻辑复杂到在读已提交模式下可能给出错误结果时，才推荐使用可串行化模式。最常见的情况是，当一个事务要执行多条必须看到相同数据库视图的连续命令时，就需要使用可串行化模式。

 class | value 
-------+-------
     1 |    10
     1 |    20
     2 |   100
     2 |   200

SELECT SUM(value) FROM mytab WHERE class = 1;

SELECT SUM(value) FROM mytab WHERE class = 2;