POSTGRESQL实际上提供了三个隔离级别，上次分析了其中序列化的隔离级别，但实际上大多数数据库都没有使用该级别。
大多数数据库的隔离级别在读提交和读两者中是选定的。 其中，repeatableread在我们的测试中，发现了几个问题。 什么情况下会发生与serializable相同的情况？ (请参阅
让我们来看看以下两个实验。 都是repeatable read。 为什么结果会不同呢？
1 sessionarepeatablereadsessionbreadcommited
进行以下实验步骤(按编号顺序整理) )。
SESSION A
1
begintransactionisolationlevelrepeatableread；
2
updateemployeesetname=' Simon ' where id=1；
SESSION B
3占线；
4 updateemployeesetname='2' where id=1
(语句未执行的等待状态)
SESSION A
5commit；
SESSION B
序列号6成功操作
具体结果请参阅下图的SESSION A
SESSION B
结果与大多数网站上介绍的repeatable read结果一致。 他们要求的结果是防止幻读。
但实际上上面的测试有一个漏洞。 进行实验2
正在重试上述操作
SESSION A
SESSION B
知道结果。 结果和上面的不一样。 SESSION B无法直接回滚commit进程b。 哪里出了问题。
各位，请关注SESSION B的第一行
begintransactionisolationlevelrepeatableread；
上面的两个实验能告诉我什么？ 是什么？ 是什么？ 是什么？ 是什么？ 是什么？
如果在POSTGRESQL中将事务的隔离级别调整为repleatable read；
在某个时刻你的事务会变成序列化，也就是序列化。
(具体来说，看前几天关于可串行化的实验结果)
那为什么，试着分析一下吧
为什么两个进程都有可能在REPEATABLE READ DML的同一行上序列化
REPEATABLE READ主要需要完成哪些任务，以防止幻读
在进程a占有了ID=1的行之后，该行的信息被锁定，将来要防止b进程修正该行的数据，读取该行的数据要在b修正了之后，a必须防止b修正该行的数据，序列化的概念
SESSION A
SESSION B
因此，大多数实际的internet示例在READ COMMIT中生成REPATEABLE READ的结果，而不是将系统调整为REPATEABLE READ的结果。 通过将POSTGRESQL数据库调整为REPATABLE READ，可以大大提高事务回滚的概率。 因此，该实验明确告知大部分用户，POSTGRESQL建议在没有特殊需求的情况下也适合使用READCOMMIT，POSTGRESQL的默认安装后隔离级别也是READCOMMIT