SELECT 能否使用 Read Committed Isolation Level 在一个事务中获得不同的结果？

Question

这里是来自postgresql 9.6 docs 关于读取提交隔离级别的完整段落：

Read Committed 是 PostgreSQL 中的默认隔离级别。当一个 事务使用这个隔离级别，一个 SELECT 查询（没有 FOR UPDATE/SHARE 子句）只看到查询开始前提交的数据； 它永远不会看到未提交的数据或期间提交的更改 通过并发事务执行查询。实际上，一个 SELECT 查询 在查询开始的那一刻看到数据库的快照 跑步。但是， SELECT 确实看到了以前执行的更新的效果 在它自己的事务中，即使它们尚未提交。 另请注意，两个连续的 SELECT 命令可以看到不同的数据， 即使它们在单个事务中，如果其他 事务在第一个 SELECT 开始之后和之前提交更改 第二个 SELECT 开始。

---

所以基本上：

SELECT 查询只能看到在查询开始之前提交的数据，并且永远不会看到在查询执行期间提交的更改 并发事务。

但在最后一句中它指出：

还要注意两个连续的 SELECT 命令可以看到不同的数据， 即使它们在单个事务中，如果其他 事务在第一个 SELECT 开始之后和之前提交更改 第二个 SELECT 开始。

对我来说，这看起来很矛盾。有人可以详细说明吗？两个 SELECT 查询究竟如何在一个事务中看到不同的数据？事务不是孤立的吗？

Answer 1

是的，这是真的。为了避免这种情况，您需要使用更高的隔离级别：“可重复读取”。 如果您需要完全隔离事务，甚至可以“序列化”。 请记住，更高的隔离度会通过性能来支付更高的成本。

这里可以找到详细解释：https://www.postgresql.org/docs/9.1/static/transaction-iso.html

所以这里有一个例子是怎么发生的：

1. Connection1 打开事务并从 Table1 中读取一行 "选择 *"

2. Connection2 更新同一行并提交

3. Connection1 再次读取同一行并获取更新的数据

隔离级别是“已提交读”，因此从字面上看，所有已提交的内容都对其他连接可见。

如果由于某种原因您不能使用更高的隔离级别，有一种方法可以防止这种“意外”更新的发生：您的 Connection1 可以使用“select ... for update”来代替。这将有效地锁定该行，直到 Connection1 的事务提交或回滚。因此 Connection2 将等待此提交或回滚才能更新行。

Answer 2

没有矛盾。事务中的两个连续 SELECT 语句可能会获取不同的结果。考虑一下 - 您开始交易，然后发出
从emp中选择*； 你得到2条记录。 另一个会话将记录插入 emp 并提交。 在第一个会话中，您再次发出 从emp中选择*； 你得到3条记录。这是 READ COMMITTED 隔离级别的预期行为。

示例代码

tmp=# begin ; 
BEGIN
tmp=# select * from emp;
 id 
----
  1
  2
(2 rows)

tmp=# select * from emp;
 id 
----
  1
  2
  3
(3 rows)

tmp=# commit;