PostGreSQL多版本实现中的几个问题

发表于 十二月 4th, 2009 大树 没人乘凉

出现当前可见版本的tuple已经被其他事务更新，而当前事务又需要更新此tuple时的处理如下：

1.如果当前的隔离级别为可串行化，则报错：可串行化失败，并abort当前事务

2.如果当前隔离级别为Read Commited，则判断该tuple的最新版本是否满足当前update的条件，如果满足，则更新之，否则直接返回，继续执行其它plan分支

1.如何标志一个版本：每个tuple在heap中的实际存储内加入三个标志，即xmin，xmax和cid。Xmin是创建该tuple的事务id，xmax是删除或更新该tuple的事务id。Cid在创建该tuple时是创建者的commandid–cmin，如果被同一事务删除或更新，则cid中包含了创建者的commandid cmin和删除者的commandid cmax，当该事务提交时，cid内存储最后操作该tuple的commandid cmax。

2.如何判断可见性：事务启动时，截取快照。Tuple可见的条件是：（xmin已经commit或者xmin是当前事务且当前cid > cmin）且（xmax尚未启动、比当前事务晚启动或xmax是当前事务但是cmax >当前cid）。从而，当前事务所作出的更新对当前事务的后续命令可见。

3.Halloween问题通过cid已经解决：同一cid作出的更改对该cid不可见。

4.当需要更新发现当前可见的tuple已经被其他事务更新的时候。按照隔离级别不同进行不同处理：在可串行化隔离级别下，记录出错，并且Abort当前事务（即在事务日志中记录abort）；在ReadCommited隔离级别下，则尝试获得最新的tuple，并检验其是否符合当前scan条件，如符合则更新之。

您来到小站很多次了哦，喜欢的话，不妨订阅我吧·!

相关文章:

1. PostGreSQL之MVCC代码分析（1）：概览 Transaction启动时形成快照就是要记录该Transaction可见的TransactionID，排除不可见的ID。PostGreSQL中每一个版本的数据有两个ID，其中一个是CreationID即插入该数据的TransactionID，一个是ExpiredID，即删除或更新该数据的TransactionID。对一个Transaction可见的数据的ID要满足以下条件： 1.CreationID当前TransactionID或ExpiredID不存在 Transaction启动形成快照的过程： 遍历当前所有活动的Transaction，记录在一个活动Transaction的ID数组中；根据Transaction的先后顺序，选择当前Transaction可见的最小TransactionID，记录在xmin，选择可见的最大TransactionID，记录在xmax中。 PostGreSQL8.5中进行最终的版本选择是在从外存中获取一个页面的数据之后，由一个检验函数（HeapTupleSatisfiesMVCC等一系列函数）检验所有该页面数据的数据对当前Transaction的可见性，如果不可见，则将数据除去，最后返回所有可见数据。...
2. PostGreSQL之MVCC分析终结篇 从9月中旬开始的PostGreSQL代码阅读+MVCC，至今总算告一段落。此次分析，既有意料之中，亦有出乎意料。意料之中的是过程复杂曲折，意料之外的是PostGreSQL的MVCC实现居然如此简单。...
3. 内存越界的概念和调试方法 所谓内存越界（Heap Corruption），就是指当内存输入超出了预分配的空间大小，就会覆盖该空间之后的一段存储区域，导致系统异常。越界访问是非常常见的一种黑客手段。...
4. [转载]一种理想的在关系数据库中存储树型结构数据的方法 理想中的树型结构应具备哪些特点呢？数据存储冗余小、直观性强；方便返回整个树型结构数据；可以很轻松的返回某一子树（方便分层加载）；快整获以某节点的祖谱路径；插入、删除、移动节点效率高等等。带着这些需求我查找了很多资料，发现了一种理想的树型结构数据存储及操作算法，改进的前序遍历树模型（The Nested Set Model）。...
5. Chrome OS发布 在Google的官方Blog中写道，Chrome发布已经9个月了，近3000万用户试用了Google的高效率浏览器，但是遗憾的是目前Chrome赖以运行的操作系统都是在Web出现前开发的，为了能让Chrome发挥出所有的能量，Google决定推出Chrome Opreating System！...