POSTGRESQL REPEATABLE READ 到底能不能用

POSTGRESQL 实际上提供了三种隔离级别, 上次已经分析了其中的序列化的隔离级别,实际上在大部分数据库上这个级别都是不被使用的.

大部分数据库的隔离级别大部分是在 read commit  和  repeatable read 两个进行抉择的. 其中repeatable read 在我们的测试中,发现了一些问题, 在什么情况下会产生和serializable一样的情况. (具体请参见前面讲serializable)

我们来看看下面两个实验, 都是repeatable read 为什么结果会不一样.

1   SESSION A  repeatable read   SESSION B  read commited

我们做以下的实验步骤 (按照序号整理顺序)

SESSION A   

1 

begin transaction isolation level repeatable read;

2 

update employee set name = 'simon' where id = 1;

SESSION B

3  begin;

4  update employee set name = '2' where id =1

(语句没有执行等待状态)

SESSION A

5  commit;

SESSION B

 6 序号4 成功操作

具体结果请看下图  SESSION A 

SESSION B

结果和大多数的网站上的介绍 repeatable read 的结果一致. 他们要的结果就是防止了幻读.

但实际上上面的测试是有漏洞的,我们进行实验2

我们将上面的操作在重做一次

SESSION A 

SESSION B

大家可以看到结果,结果和上面的不一样了,SESSION B  无法commit 进程B 直接进行了回滚.  哪里出了问题.

大家注意SESSION B  中的行

begin transaction isolation level repeatable read;

上面两个实验告诉我们什么??????

在POSTGRESQL 中如果你将事务的隔离级别调整成 repleatable read;

那么在某些时刻你的事务,会变成serializable 也就是变成序列化.

(具体看前几期关于serializable的实验结果)

那么为什么,我们来分析一下

为什么两个进程都是 REPEATABLE READ DML 同一行就产生了 序列化的可能

REPEATABLE READ  主要要完成什么任务, 防止幻读

当进程 A  占有了ID =1 这行后, 这行的信息就被锁定了,未来防止B进程修改这行数据,并读取这行数据是B 修改后的, A 必然要防止 B 修改这行数据,也就产生了序列化的概念, 我做完,你在做. 

SESSION A

SESSION B

所以实际上网上大部分的例子都是在READ COMMIT中,产生一个REPATEABLE  READ ,的结果,而不是你将你的系统调整成 REPATEABLE READ 后的结果,而如果你将你的POSTGRESQL 的数据库调整成REPATABLE READ 则那你事务回滚的概率会大大提高, 所以这个实验很明确的告诉大部分使用者, POSTGRESQL 建议你没有特殊需求还是使用 READ COMMIT 比较合适, POSTGRESQL 默认安装后的隔离级别也是READ COMMIT