从tuple格式看PG设计之CLOG

PG行记录格式

t_xmin 插入记录/元组 事务txid
t_xmax 删除/修改记录/元组 事务txid, 新插入t_xmax设置为0，
t_cid  事务内SQL执行顺序号，0开始
t_ctid 指向元组/新元组(block,offset) t_ctid
t_infomask2  HEAP_HOT_UPDATED(旧元组)HEAP_ONLY_TUPLE（无索引新元组）标志位
t_infomask  事务标准位，提交，撤销，进行中，子事务进行中
t_hoff   用户数据的偏移量
NULL bitmap   null值位图
User data   实际的数据
复制

MVCC在做可视化判断时，我们通常需要比较tuple的t_xmin,t_xmax，还需要比较该记录是否commited,按照其他数据库的经验，比最老活跃事务小的，不在read-view列表中就已经是已提交的事务，还有什么好判断的；这恰恰是PG的不同点。回到PG行记录格式，我们可以发现PG不是原地修改，not inplace,not inplace,not inplace ；除了保存commited/ in progress状态的tuple, abort的记录页保存在，即不是简单提交/未提交二元论。

clog数据写入到pg_xact，2bit存储1个事务状态，41亿事务ID需要2^32 2 /8/2^20=512M字节；实际为了加速事务状态查询访问，状态在CLOG日志缓冲池中缓存；判断事务状态也只判断TRANSACTION_STATUS_COMMITTED 和TRANSACTION_STATUS_ABORTED，只有第一次通过CLOG来判断下次再次查询时通过行设置t_infomask 标志位来判断

CLOG怎么分配内存，有没有参数来设置呢？PG没有直接参数来控制clog buffers的大小，间隔从shared_buffers来分配。具体设置写死在src/backend/access/transam/clog.c 。log buffers 占用的页的个数是NBuffers / 512 ，最大为128个页，最小为4个页，可理解为 shared_buffers的1/512