PosegreSQL基础回顾(第 13 章 并发控制)

前端之家收集整理的这篇文章主要介绍了PosegreSQL基础回顾(第 13 章 并发控制)前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

来源: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语句检索到的行被锁定,就好像它们要被更新。这可以阻止它们被其他事务锁定、修改或者删除,一直到当前事务结束。也就是说其他尝试UPDATEDELETESELECT FOR UPDATESELECT FOR NO KEY UPDATESELECT FOR SHARE或者SELECT FOR KEY SHARE这些行的事务将被阻塞,直到当前事务结束。反过来,SELECT FOR UPDATE将等待已经在相同行上运行以上这些命令的并发事务,并且接着锁定并且返回被更新的行(或者没有行,因为行可能已被删除)。不过,在一个REPEATABLE READSERIALIZABLE事务中,如果一个要被锁定的行在事务开始后被更改,将会抛出一个错误。进一步的讨论请见第 13.4 节

任何在一行上的DELETE命令也会获得FOR UPDATE锁模式,在某些列上修改值的UPDATE也会获得该锁模式。当前UPDATE情况中被考虑的列集合是那些具有能用于外键的唯一索引的列(所以部分索引和表达式索引不被考虑),但是这种要求未来有可能会改变。

 

原文链接:https://www.f2er.com/postgresql/883073.html

猜你在找的Postgre SQL相关文章