PostgreSQL源码解析 on 最后的DBA

控制文件上的参数和主从参数不一致问题

Mon, 25 Aug 2025 00:00:00 +0000

PARAMETER_CHANGE和控制文件上的数据库参数
#

pg有些参数会影响从库的运行，而这些参数不仅在参数文件中，也写到controlfile，只要参数改变就会写入wal并更新控制文件。从库会通过PARAMETER_CHANGE wal record进行redo，写入到从库的controlfile中。 PARAMETER_CHANGE wal record：

rmgr: XLOG len (rec/tot): 54/ 54, tx: 0, lsn: 27F/800001C0, prev 27F/80000148, desc: PARAMETER_CHANGE max_connections=3000 max_worker_processes=20 max_wal_senders=10 max_prepared_xacts=0 max_locks_per_xact=1024 wal_level=logical wal_log_hints=off track_commit_timestamp=on

XLOG_PARAMETER_CHANGE记录了这8种参数，控制文件也可以直接看，：

$ pg_controldata |grep setting
wal_level setting: logical
wal_log_hints setting: on
max_connections setting: 1000
max_worker_processes setting: 20
max_wal_senders setting: 10
max_prepared_xacts setting: 0
max_locks_per_xact setting: 1024
track_commit_timestamp setting: on

这些参数都是主库的，哪怕这个控制文件是从库的。 startup进程通过CheckRequiredParameterValues函数检查6个参数是否满足条件。其中1个参数wal_level>=replica，另外5个参数max_connections,max_worker_processes,max_wal_senders,max_prepared_transactions,max_locks_per_transaction会检查主从大小，从库小的话会pause recovery。直接将主库参数调大，从库直接挂掉，pg log如下：

FATAL,22023,"hot standby is not possible because max_connections = 2000 is a lower setting than on the master server (its value was 3000)",,,,,"WAL redo at 27F/800001C0 for XLOG/PARAMETER_CHANGE: max_connections=3000 max_worker_processes=20 max_wal_senders=10 max_prepared_xacts=0 max_locks_per_xact=1024 wal_level=logical wal_log_hints=off track_commit_timestamp=on",,,,"","startup"

8个参数中的6个都可能严重影响从库的运行。另外2个参数wal_log_hints,track_commit_timestamp不会被startup进程立即检查。8个参数同步到控制文件都有其意义。

wal_log_hint主从不一致
#

wal_log_hints的变化会记录到wal日志中，虽然不会被startup进程检查，pg_rewind会检查：

perform_rewind(...)
{
...
	/*
	 * Target cluster need to use checksums or hint bit wal-logging, this to
	 * prevent from data corruption that could occur because of hint bits.
	 */
	if (ControlFile_target.data_checksum_version != PG_DATA_CHECKSUM_VERSION &&
		!ControlFile_target.wal_log_hints)
	{
		pg_fatal("target server needs to use either data checksums or \"wal_log_hints = on\"");
	}

因为wal_log_hints是wal相关的，所以pg_rewind去检查从库的wal_log_hints参数有没有打开没有意义，应检查主库的wal_log_hints有没有打开，所以pg将wal_log_hints参数同步到从库的控制文件中了，非常合理。

wal_log_hint主从不一致测试：

select * from t1;
checkpoint;
update t1 set b='eee'; --观察点1
checkpoint; --忽略该online checkpoint wal record
select * from t1; --观察点2

--观察动作
pg_waldump 000000020000027F0000000A|tail -10

-- observing option
select t_ctid,lp,
case lp_flags 
when 0 then '0:LP_UNUSED' 
when 1 then 'LP_NORMAL' 
when 2 then 'LP_REDIRECT' 
when 3 then 'LP_DEAD' 
end as lp_flags,
t_xmin,t_xmax,t_field3 as t_cid, raw_flags, info.combined_flags,substring(t_data,0,40) 
from heap_page_items(get_raw_page('t1',0)) item,
LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2) info 
order by lp;

on，on:

--观察点1：
rmgr: Heap len (rec/tot): 85/ 208, tx: 11140182, lsn: 27F/5000CC38, prev 27F/5000CBC0, desc: HOT_UPDATE off 3 xmax 11140182 flags 0x10 ; new off 4 xmax 0, blkref #0: rel 1663/7472552/7472597 blk 0 FPW
rmgr: Transaction len (rec/tot): 46/ 46, tx: 11140182, lsn: 27F/5000CD08, prev 27F/5000CC38, desc: COMMIT 2025-07-21 18:28:13.292397 CST
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 27F/5000CD38, prev 27F/5000CD08, desc: RUNNING_XACTS nextXid 11140183 latestCompletedXid 11140182 oldestRunningXid 11140183
--观察点2：
rmgr: XLOG len (rec/tot): 51/ 171, tx: 0, lsn: 27F/58000110, prev 27F/580000D8, desc: FPI_FOR_HINT , blkref #0: rel 1663/7472552/7472597 blk 0 FPW
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 27F/580001C0, prev 27F/58000110, desc: RUNNING_XACTS nextXid 11140183 latestCompletedXid 11140182 oldestRunningXid 11140183

off,off:

--观察点1：
rmgr: Heap len (rec/tot): 85/ 225, tx: 11140183, lsn: 27F/580003C8, prev 27F/58000390, desc: HOT_UPDATE off 4 xmax 11140183 flags 0x10 ; new off 5 xmax 0, blkref #0: rel 1663/7472552/7472597 blk 0 FPW
rmgr: Transaction len (rec/tot): 46/ 46, tx: 11140183, lsn: 27F/580004B0, prev 27F/580003C8, desc: COMMIT 2025-07-21 18:33:18.192146 CST
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 27F/580004E0, prev 27F/580004B0, desc: RUNNING_XACTS nextXid 11140184 latestCompletedXid 11140183 oldestRunningXid 11140184
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 27F/58000518, prev 27F/580004E0, desc: RUNNING_XACTS nextXid 11140184 latestCompletedXid 11140183 oldestRunningXid 11140184
--观察点2：

on，off:

--观察点1：
rmgr: Heap len (rec/tot): 85/ 274, tx: 11140186, lsn: 27F/58000C18, prev 27F/58000BA0, desc: HOT_UPDATE off 7 xmax 11140186 flags 0x10 ; new off 8 xmax 0, blkref #0: rel 1663/7472552/7472597 blk 0 FPW
rmgr: Transaction len (rec/tot): 46/ 46, tx: 11140186, lsn: 27F/58000D30, prev 27F/58000C18, desc: COMMIT 2025-07-21 18:40:17.638691 CST
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 27F/58000D60, prev 27F/58000D30, desc: RUNNING_XACTS nextXid 11140187 latestCompletedXid 11140186 oldestRunningXid 11140187
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 27F/58000D98, prev 27F/58000D60, desc: RUNNING_XACTS nextXid 11140187 latestCompletedXid 11140186 oldestRunningXid 11140187
--观察点2：
rmgr: XLOG len (rec/tot): 51/ 236, tx: 0, lsn: 27F/58000E48, prev 27F/58000DD0, desc: FPI_FOR_HINT , blkref #0: rel 1663/7472552/7472597 blk 0 FPW
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 27F/58000F38, prev 27F/58000E48, desc: RUNNING_XACTS nextXid 11140187 latestCompletedXid 11140186 oldestRunningXid 11140187

off，on:

--观察点1：
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 27F/58001108, prev 27F/58001090, desc: RUNNING_XACTS nextXid 11140187 latestCompletedXid 11140186 oldestRunningXid 11140187
rmgr: Heap len (rec/tot): 85/ 289, tx: 11140187, lsn: 27F/58001140, prev 27F/58001108, desc: HOT_UPDATE off 8 xmax 11140187 flags 0x10 ; new off 9 xmax 0, blkref #0: rel 1663/7472552/7472597 blk 0 FPW
rmgr: Transaction len (rec/tot): 46/ 46, tx: 11140187, lsn: 27F/58001268, prev 27F/58001140, desc: COMMIT 2025-07-21 18:44:08.550109 CST
rmgr: Standby len (rec/tot): 54/ 54, tx: 0, lsn: 27F/58001298, prev 27F/58001268, desc: RUNNING_XACTS nextXid 11140188 latestCompletedXid 11140186 oldestRunningXid 11140187; 1 xacts: 11140187
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 27F/580012D0, prev 27F/58001298, desc: RUNNING_XACTS nextXid 11140188 latestCompletedXid 11140187 oldestRunningXid 11140188
--观察点2：

测试小结：

FPI_FOR_HINT在hintbit回写时产生，查询语句可产生FPI_FOR_HINT
无论从on or off，主为on的时候，FPI_FOR_HINT就会生产

附加知识：what is XLOG_RUNNING_XACTS
#

XLOG_RUNNING_XACTS是RM_STANDBY_ID的一种：

/*
 * XLOG message types
 */
#define XLOG_STANDBY_LOCK			0x00
#define XLOG_RUNNING_XACTS			0x10
#define XLOG_INVALIDATIONS			0x20

XLOG_STANDBY_LOCK：记录 AccessExclusiveLock 的获取和释放，用于 Standby 节点识别锁状态。

XLOG_RUNNING_XACTS： running-xacts snapshots用于构建快照，确保事务一致性

XLOG_INVALIDATIONS：INVALIDATIONS消息，用于同时效元数据信息给local backend

 * standbydefs.h
 *	 Frontend exposed definitions for hot standby mode.

RM_STANDBY_ID是专门为hot standby只读从库定义的rmgr。对于本地实例恢复、逻辑解析这些需要用到wal的场景，``RM_STANDBY_ID`本质上对他们没有意义。

测试事务提交观察wal record：

command	wal record
begin;
select * from txid_current(); –11140191
commit;	rmgr: Transaction len (rec/tot): 46/ 46, tx: 11140191, lsn: 27F/80000538, prev 27F/80000500, desc: COMMIT 2025-07-23 11:16:10.872724 CST
	rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 27F/80000568, prev 27F/80000538, desc: RUNNING_XACTS nextXid 11140192 latestCompletedXid 11140191 oldestRunningXid 11140192

事务id 本身commit or abort还是rmgr: Transaction在同步，快照通过rmgr: Standby RUNNING_XACTS 同步。

track_commit_timestamp主从不一致
#

track_commit_timestamp，startup进程会在接受到相应wal后将从库的commit ts功能激活，主要是为从库查看xid提交时间用:

/*
 * Activate or deactivate CommitTs' upon reception of a XLOG_PARAMETER_CHANGE
 * XLog record during recovery.
 */
void
CommitTsParameterChange(bool newvalue, bool oldvalue)
{
	/*
	 * If the commit_ts module is disabled in this server and we get word from
	 * the primary server that it is enabled there, activate it so that we can
	 * replay future WAL records involving it; also mark it as active on
	 * pg_control. If the old value was already set, we already did this, so
	 * don't do anything.
	 *
	 * If the module is disabled in the primary, disable it here too, unless
	 * the module is enabled locally.
	 *
	 * Note this only runs in the recovery process, so an unlocked read is
	 * fine.
	 */
	if (newvalue)
	{
		if (!commitTsShared->commitTsActive)
			ActivateCommitTs();
	}
	else if (commitTsShared->commitTsActive)
		DeactivateCommitTs();
}

track_commit_timestamp主从不一致测试，测试步骤：

初始状态，主=on，从=on 。均能使用committed_xact等函数
主=off（重启主库），从库=on（不动）。均不能使用committed_xact等函数

主库修改并重启后，从库复制依然正常，committed_xact等函数不可使用：

$ select * from pg_last_committed_xact();
ERROR: 55000: could not get commit timestamp data
HINT: Make sure the configuration parameter "track_commit_timestamp" is set on the primary server.
LOCATION: error_commit_ts_disabled, commit_ts.c:385

$ show track_commit_timestamp
-> ;
 track_commit_timestamp 
------------------------
 on
(1 row)

Time: 0.198 ms
$ \q
## pg_controldata |grep track_commit_timestamp
track_commit_timestamp setting: off

pg14+ pause recovery
#

pg14对主库参数修改导致从库宕机做了提升。当参数不满足条件时，只读从库直接宕掉改成只读从库不宕只停复制，代码见RecoveryRequiresIntParameter

Pause recovery on a hot standby server if the primary changes its parameters in a way that prevents replay on the standby (Peter Eisentraut)

Previously the standby would shut down immediately

测试pg14修改参数导致从库复制中断：

2025-07-23 19:46:31.337 CST,,,141823,,6880ca5f.229ff,14,,2025-07-23 19:41:19 CST,1/0,0,LOG,00000,"recovery has paused","If recovery is unpaused, the server will shut down.","You can then restart the server after making the necessary configuration changes.",,,"WAL redo at 281/78324BE8 for XLOG/PARAMETER_CHANGE: max_connections=2000 max_worker_processes=20 max_wal_senders=10 max_prepared_xacts=0 max_locks_per_xact=1024 wal_level=logical wal_log_hints=on track_commit_timestamp=on",,,,"","startup",,0

因为复制已经中断，去把主库的参数改回来也没有用，从库无法应用后面的变更并更新控制文件，所以只能修改从库参数并重启（log的提示也很明显了）。

小结8个参数
#

8个参数在主库被修改并重启后，均会更新本地控制文件，如果参数有变会将改变后的参数写入wal中同步给下游，下游redo这个parameter change wal record，即更新本地的控制文件，从库根据一定条件来判断主从或者其他功能是否可用。

写到控制文件中的8个参数	check	if not,standby(pg13-)	if not,standby(pg14+)
wal_level	!=minimal	无法同步，原理性问题	无法同步，原理性问题
max_connections	主<=从	hot standby宕机	hot standby停止同步
max_worker_processes	主<=从	hot standby宕机	hot standby停止同步
max_wal_senders	主<=从	hot standby宕机	hot standby停止同步
max_prepared_transactions	主<=从	hot standby宕机	hot standby停止同步
max_locks_per_transaction	主<=从	hot standby宕机	hot standby停止同步
wal_log_hints	pg_rewind前置条件（either data checksums or wal_log_hints = on）	不影响standby同步	不影响standby同步
track_commit_timestamp	打开/关闭从库的commit_ts功能	不影响standby同步	不影响standby同步

特别鸣谢：高长军高大师

pg truncate浅析

Mon, 12 Aug 2024 00:00:00 +0000

命令选项
#

TRUNCATE [ TABLE ] [ ONLY ] name [ * ] [, ... ]
 [ RESTART IDENTITY | CONTINUE IDENTITY ] [ CASCADE | RESTRICT ]

1.ONLY:只truncate指定的表。当表有继承子表或有子分区时，默认会一起truncate;only可只truncate继承父表。分区父表不能指定only

--不能truncate only分区父表
=> truncate only parttable;
ERROR: 42809: cannot truncate only a partitioned table
HINT: Do not specify the ONLY keyword, or use TRUNCATE ONLY on the partitions directly.
LOCATION: ExecuteTruncate, tablecmds.c:1655

--truncate only继承父表，只清理父表
=> truncate table only parenttable;
TRUNCATE TABLE
=> select tableoid::regclass,count(*) from parenttable group by tableoid::regclass ;
 tableoid | count 
------------+-------
 childtable | 1
 
--直接truncate继承父表，子表也会被清理
=> truncate table parenttable;
TRUNCATE TABLE
=> select tableoid::regclass,count(*) from parenttable group by tableoid::regclass ;
 tableoid | count 
----------+-------
(0 rows)

2.RESTART IDENTITY CONTINUE IDENTITY:列上的序列是否要重置，默认CONTINUE。

--bigserial 默认会创建列上的序列
=> create table tableserial (a bigserial not null,b name);
CREATE TABLE
=> \d+ tableserial;
 Table "public.tableserial"
 Column | Type | Collation | Nullable | Default | Storage | Stats target | Description 
--------+--------+-----------+----------+----------------------------------------+---------+--------------+-------------
 a | bigint | | not null | nextval('tableserial_a_seq'::regclass) | plain | | 
 b | name | | | | plain | | 
 
=> insert into tableserial(b) select md5(random()::text) from generate_series(1,1000);
INSERT 0 1000 
--seq当前值为1000
=> select currval('tableserial_a_seq'::regclass);
 currval 
---------
 1000

--直接truncate默认不会重置序列
=> truncate table tableserial;
TRUNCATE TABLE
=> select currval('tableserial_a_seq'::regclass) cur,nextval('tableserial_a_seq'::regclass);
 cur | nextval 
------+---------
 1000 | 1001

--显示指定RESTART IDENTITY，重置序列
=> truncate table tableserial RESTART IDENTITY;
TRUNCATE TABLE
--注意seq在nextval时重置了
=> select currval('tableserial_a_seq'::regclass) cur,nextval('tableserial_a_seq'::regclass);
 cur | nextval 
------+---------
 1001 | 1

3.CASCADE：清理表及其所有外键表的数据

--创建主表和外键表和数据
=> create table pri_tab(id bigint primary key,name varchar(10));
CREATE TABLE

=> insert into pri_tab values (1,'abc'),(2,'abc'),(3,'abc');
INSERT 0 3

=> create table frn_tab(id bigint,FOREIGN KEY (id) REFERENCES pri_tab(id));
CREATE TABLE

=> insert into frn_tab values (1),(2);
INSERT 0 2

=> select * from pri_tab;
 id | name 
----+------
 1 | abc
 2 | abc
 3 | abc
(3 rows)

--外键表frn_tab依赖主表pri_tab的数据
=> select * from frn_tab;
 id 
----
 1
 2
(2 rows)

--有主表外键reference时，外键表必须跟cascade，否则无法清理
=> truncate table pri_tab ;
ERROR: 0A000: cannot truncate a table referenced in a foreign key constraint
DETAIL: Table "frn_tab" references "pri_tab".
HINT: Truncate table "frn_tab" at the same time, or use TRUNCATE ... CASCADE.
LOCATION: heap_truncate_check_FKs, heap.c:3427

--外键约束的表一起清空
=> truncate table pri_tab cascade;
NOTICE: 00000: truncate cascades to table "frn_tab"
LOCATION: ExecuteTruncateGuts, tablecmds.c:1725
TRUNCATE TABLE
=> select * from pri_tab;
 id | name 
----+------
(0 rows)

=> select * from frn_tab;
 id 
----
(0 rows)

由于外键表依赖主表的数据，不能直接truncate主表，必须加cascade，此时外键表也跟随主表一起清空

4.RESTRICT 是否清理foreign key表。没什么用，default选项，加不加都是这样。清理附带的外键表应加CASCADE。

MVCC/transaction
#

pg官方文档有这么一段化

TRUNCATE is not MVCC-safe. After truncation, the table will appear empty to concurrent transactions, if they are using a snapshot taken before the truncation occurred. TRUNCATE is transaction-safe with respect to the data in the tables: the truncation will be safely rolled back if the surrounding transaction does not commit.

transaction-safe意思是可以放在事务块里，可以回退回滚truncate：

=> begin;
BEGIN
=> truncate t1;
TRUNCATE TABLE
=> rollback;
ROLLBACK
=> select count(*) from t1;
 count 
-------
 100

not MVCC-safe意思是一个会话在truncate前打了一个快照，快照期间如果发生truncate，这个快照是可以读到truncate清理后的结果的。这不符合MVCC。不过这个问题不算太大，在会话场景下，因为truncate是8级锁，快照没有结束的话最低在表上有一个读共享锁，所以truncate不会执行。

This will only be an issue for a transaction that did not access the table in question before the DDL command started —any transaction that has done so would hold at least an ACCESS SHARE table lock, which would block the DDL command until that transaction completes

功能更新
#

truncate更新功能不多，只需要注意14的时候支持truncate foreign tables即可。truncate foreign tables前提是fdw得支持TRUNCATE API

Also it extends postgres_fdw so that it can issue TRUNCATE command to foreign servers, by adding new routine for that TRUNCATE API.

pg truncate和其他库的功能差异
#

truncate很快、8级锁等特性已经是人尽皆知的事情了，相对于其他数据库，pg还可以：选择是否重置序列（RESTART IDENTITY CONTINUE IDENTITY）、回滚、简单的授权。

truncate做了什么
#

create table lzl(a int);
create index lzl_idx on lzl(a);
create sequence lzl_seq start with 1;
alter table lzl alter column a set default nextval('lzl_seq');
--select pg_relation_filepath('lzl');

--db路径
=> select oid from pg_database where datname='lzldb';
 oid 
--------
 418679

--刚创建时候各个rel的oid=relfilenode
=> select relname,oid,relfilenode,relkind from pg_class where relname like 'lzl%';
 relname | oid | relfilenode | relkind 
---------+--------+-------------+---------
 lzl | 428363 | 428363 | r
 lzl_idx | 428366 | 428366 | i
 lzl_seq | 428367 | 428367 | S
(3 rows)

=> truncate table lzl;
TRUNCATE TABLE
=> select relname,oid,relfilenode,relkind from pg_class where relname like 'lzl%';
 relname | oid | relfilenode | relkind 
---------+--------+-------------+---------
 lzl | 428363 | 428370 | r
 lzl_idx | 428366 | 428371 | i
 lzl_seq | 428367 | 428367 | S
--truncate后，表和索引重建了，sequence却没有


M=> truncate table lzl RESTART IDENTITY;
TRUNCATE TABLE
=> select relname,oid,relfilenode,relkind from pg_class where relname like 'lzl%';
 relname | oid | relfilenode | relkind 
---------+--------+-------------+---------
 lzl | 428363 | 428372 | r
 lzl_idx | 428366 | 428373 | i
 lzl_seq | 428367 | 428367 | S
--显示restart，sequence还是没有重建


M=> alter sequence lzl_seq restart;
ALTER SEQUENCE
M=> select relname,oid,relfilenode,relkind from pg_class where relname like 'lzl%';
 relname | oid | relfilenode | relkind 
---------+--------+-------------+---------
 lzl | 428363 | 428372 | r
 lzl_idx | 428366 | 428373 | i
 lzl_seq | 428367 | 428374 | S
--显示restart sequence是会重建sequence的

truncate ···RESTART IDENTITY没有重建我们sequence，alter sequence lzl_seq restart重建了sequence。应该是RESTART IDENTITY没有理解对。在看下官方文档对RESTART IDENTITY的解释

Automatically restart sequences owned by columns of the truncated table(s).

sequence必须owned by表上的列，注意不是owner to。虽然\d可以看到表上的sequence，但是它可能不属于表

 \d+ lzl;
 Table "public.lzl"
 Column | Type | Collation | Nullable | Default | Storage | Stats target | Description 
--------+---------+-----------+----------+------------------------------+---------+--------------+-------------
 a | integer | | | nextval('lzl_seq'::regclass) | plain | | 

用owned by修改sequence的所属表

=> ALTER SEQUENCE lzl_seq OWNED BY lzl.a;
ALTER SEQUENCE

--查看序列的所有者信息
SELECT s.relname AS seq, n.nspname AS sch, t.relname AS tab, a.attname AS col 
FROM pg_class s 
JOIN pg_depend d ON d.objid=s.oid AND d.classid='pg_class'::regclass AND d.refclassid='pg_class'::regclass 
JOIN pg_class t ON t.oid=d.refobjid 
JOIN pg_namespace n ON n.oid=t.relnamespace 
JOIN pg_attribute a ON a.attrelid=t.oid AND a.attnum=d.refobjsubid 
WHERE s.relkind='S' AND d.deptype='a';
 seq | sch | tab | col 
-------------------+--------+-------------+-----
 tableserial_a_seq | public | tableserial | a
 lzl_seq | public | lzl | a

=> truncate table lzl RESTART IDENTITY;
TRUNCATE TABLE
M=> select relname,oid,relfilenode,relkind from pg_class where relname like 'lzl%';
 relname | oid | relfilenode | relkind 
---------+--------+-------------+---------
 lzl | 428363 | 428375 | r
 lzl_idx | 428366 | 428376 | i
 lzl_seq | 428367 | 428377 | S

sequence owned by表上的列时，truncate显示带RESTART IDENTITY就会restart这个sequence，也就重建了sequence。默认以serial/bigserial方式创建的序列是被表拥有的，随表drop而删除；那些不被表拥有的序列，drop不会删除。 truncate重建特性汇总：

直接truncate table会重建表和索引
truncate table+RESTART IDENTITY，会重建（也就是retart）属于这个表的sequence。只要不属于这个表的sequence，哪怕列上关联了seq的默认值，也不会重建这个seq。

源码分析
#

truncate也是utility命令，很快就可以找到入口函数 src/backend/commands/tablecmds.c中的ExecuteTruncate为入口函数，注释其实已经说明truncate要获得exclusive lock，并检查权限和relation是否ok，递归检查所有需要truncate的表

void

ExecuteTruncate(TruncateStmt *stmt)

{

...

/*

* Open, exclusive-lock, and check all the explicitly-specified relations

*/

foreach(cell, stmt->relations)

{

...
LOCKMODE lockmode = AccessExclusiveLock; //8级锁
...

rel = table_open(myrelid, NoLock); //打开表


void
ExecuteTruncate(TruncateStmt *stmt)
{
...
	foreach(cell, stmt->relations)
	{
...
		LOCKMODE	lockmode = AccessExclusiveLock; //8级锁
...
		/* open the relation, we already hold a lock on it */
		rel = table_open(myrelid, NoLock); //打开表
...
		truncate_check_activity(rel); //虽然已经有锁了，但是还是要验证是否在使用
...
		if (recurse) //递归执行
		{
...
			children = find_all_inheritors(myrelid, lockmode, NULL); //找到所有继承子表

			foreach(child, children)
			{
...
				 //上面只检查了父表，递归要检查子表
				truncate_check_rel(RelationGetRelid(rel), rel->rd_rel);
				truncate_check_activity(rel);

				rels = lappend(rels, rel); //加入到待truncate的rel队列中
				relids = lappend_oid(relids, childrelid);
...
			}
		}
		//递归结束
		//发现truncate only分区父表，直接报错
		else if (rel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE)
			ereport(ERROR,
					(errcode(ERRCODE_WRONG_OBJECT_TYPE),
					 errmsg("cannot truncate only a partitioned table"),
					 errhint("Do not specify the ONLY keyword, or use TRUNCATE ONLY on the partitions directly.")));
	}
		
	//主体函数	
	ExecuteTruncateGuts(rels, relids, relids_logged,
						stmt->behavior, stmt->restart_seqs);

	/* And close the rels */
	foreach(cell, rels)
	{
		Relation	rel = (Relation) lfirst(cell);

		table_close(rel, NoLock);
	}
}

ExecuteTruncateGuts函数不仅被truncate命令调用，还被订阅端调用（发布订阅可以同步truncate）。

void
ExecuteTruncateGuts(List *explicit_rels,
					List *relids,
					List *relids_logged,
					DropBehavior behavior, bool restart_seqs)
{
...
	rels = list_copy(explicit_rels);
	if (behavior == DROP_CASCADE) //如果指定了cascade选项,提取所有reference的relation
	{
		for (;;)
		{
...
			newrelids = heap_truncate_find_FKs(relids); //找到fk
			if (newrelids == NIL)
				break;			/* nothing else to add */ //没有rel直接退出

			foreach(cell, newrelids)
			{
...
				rel = table_open(relid, AccessExclusiveLock); //所有rel获得AccessExclusiveLock
				ereport(NOTICE,
						(errmsg("truncate cascades to table \"%s\"",
								RelationGetRelationName(rel))));
				truncate_check_rel(relid, rel->rd_rel); //检查是否是可以truncate的对象，得是存储数据的表
				truncate_check_perms(relid, rel->rd_rel); //检查是否有权限
				truncate_check_activity(rel); //检查是否在使用
...
			}
		}
	}

...
	if (restart_seqs) //restart seq的处理
	{
		foreach(cell, rels)
		{
			Relation	rel = (Relation) lfirst(cell);
			List	 *seqlist = getOwnedSequences(RelationGetRelid(rel));
...
			//只是做sequence的权限检查
				if (!pg_class_ownercheck(seq_relid, GetUserId()))
					aclcheck_error(ACLCHECK_NOT_OWNER, OBJECT_SEQUENCE,
								 RelationGetRelationName(seq_rel));
...
		}
	}

...

	//执行所有before truncate触发器
	foreach(cell, rels)
	{
		ExecBSTruncateTriggers(estate, resultRelInfo);
		resultRelInfo++;
	}

//正式开始truncate
	foreach(cell, rels)
	{
...
		//如果是分区父表，啥都不做
		if (rel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE)
			continue;

		//如果是foreign table的处理
		if (rel->rd_rel->relkind == RELKIND_FOREIGN_TABLE)
		{
		...
		}

...
		 //如果是同一事务，因为可能会回退，直接执行heap_truncate_one_rel函数，不创建新的relfilenode
		if (rel->rd_createSubid == mySubid ||
			rel->rd_newRelfilenodeSubid == mySubid)
		{
			/* Immediate, non-rollbackable truncation is OK */
			heap_truncate_one_rel(rel);
		}
		else
		{
...
			//设置NewRelfilenode
			RelationSetNewRelfilenode(rel, rel->rd_rel->relpersistence);

			heap_relid = RelationGetRelid(rel);

			 //toast同理
			toast_relid = rel->rd_rel->reltoastrelid;
			if (OidIsValid(toast_relid))
			{
				Relation	toastrel = relation_open(toast_relid,
													 AccessExclusiveLock);

				RelationSetNewRelfilenode(toastrel,
										 toastrel->rd_rel->relpersistence);
				table_close(toastrel, NoLock);
			}

...
			 //重建索引
			reindex_relation(heap_relid, REINDEX_REL_PROCESS_TOAST,
							 &reindex_params);
		}

		pgstat_count_truncate(rel); //更新pgstat的truncate计算
	}

...
	//重置sequence 
	foreach(cell, seq_relids)
	{
		Oid			seq_relid = lfirst_oid(cell);

		ResetSequence(seq_relid);
	}

	//写wal
	if (list_length(relids_logged) > 0)
	{
	...
	}


	//触发AFTER TRUNCATE triggers
	resultRelInfo = resultRelInfos;
	foreach(cell, rels)
	{
		ExecASTruncateTriggers(estate, resultRelInfo);
		resultRelInfo++;
	}
...
}	

ExecuteTruncateGuts函数根据truncate选项进行处理，处理过程如下：

根据cascade选项找到所有reference的外键表
触发before truncate触发器
执行truncate

如果是同一事务，不立即生成NewRelfilenode，直接调用函数heap_truncate_one_rel进行truncate
如果不是同一事务，调用RelationSetNewRelfilenode新建NewRelfilenode

reindex_relation函数重建索引
根据restart identity重置sequence
写wal日志
触发after truncate触发器

后面大概追了下函数，套娃比较多 RelationSetNewRelfilenode table_relation_set_new_filenode relation_set_new_filenode在这里插入代码片 heapam_relation_set_new_filenode RelationCreateStorage 然后到src/backend/storage/smgr/smgr.c中的smgrcreate和smgr_create。后面就没看太懂了（一到函数指针就有点追不到的感觉，先这样吧~）··· 对于smgr.c有这样的注释：

public interface routines to storage manager switch All file system operations in POSTGRES dispatch through these routines.

任何文件系统操作都会经过smgr（storage manager）；到这里就是文件系统操作了。

reference
#

https://www.postgresql.org/docs/15/sql-truncate.html https://www.postgresql.org/docs/current/mvcc-caveats.html https://pgpedia.info/t/truncate.html https://www.orafaq.com/wiki/SQL_FAQ https://learnsql.com/blog/difference-between-truncate-delete-and-drop-table-in-sql/

PG在还没有pg_class的时候怎么访问基础系统表？

Mon, 12 Aug 2024 00:00:00 +0000

在没有pg_class的时候，数据库怎么访问系统表？这个问题可以分成两个阶段来看：

数据库簇初始化，此时一个database都没有，所以怎么构造和访问pg_class等系统表是一个问题
私有内存初始化系统表。PG的系统表信息是放在backend本地进程上的，backend在初始化的时候又怎么load pg_class？

初始化数据字典
#

在数据库还没有初始化的时候，明显是不能通过访问数据字典来初始化database、pg_class等等对象的，因为一个库都没有就不能create database，也没有pg_class去查元数据信息。 PG通过bki文件的特殊语言初始化一些数据结构，然后在bootstrap模式初始化一个原始database¹。

编译阶段：genbki.h & genbki.pl
#

src/include/catalog/genbki.h：

 * genbki.h defines CATALOG(), BKI_BOOTSTRAP and related macros
 * so that the catalog header files can be read by the C compiler.
 * (These same words are recognized by genbki.pl to build the BKI
 * bootstrap file from these header files.)

genbki.h内容很少，主要是为了catalog相关操作的宏定义，以及给KBI bootstrap文件的宏定义。数据字典的头文件基本都包含genbki.h genbki.pl会在编译过程读取/src/include/catalog目录下的.h表定义文件（不含pg_*_d.h），并创建postgres.bki文件和pg_*_d.h头文件。以pg_class为例：

[postgres@catalog]$ ll |grep pg_class 
-rw-r----- 1 postgres postgres 3682 Aug 6 2019 pg_class.dat
lrwxrwxrwx 1 postgres postgres 86 Apr 8 20:31 pg_class_d.h -> /lzl/soft/postgresql-11.5/src/backend/catalog/pg_class_d.h
-rw-r----- 1 postgres postgres 5219 Aug 6 2019 pg_class.h

pg_*_d.h头文件就是genbki.pl生成的。pg_*_d.h文件中都包含下面的一段话：

It has been GENERATED by src/backend/catalog/genbki.pl

每个数据字典都有一个结构体typedef struct FormData_*catalogname*用以存储数据字典的行数据²，例如pg_class的FormData_pg_class：

CATALOG(pg_class,1259,RelationRelationId) BKI_BOOTSTRAP BKI_ROWTYPE_OID(83,RelationRelation_Rowtype_Id) BKI_SCHEMA_MACRO
{
	/* oid */
	Oid			oid;

	/* class name */
	NameData	relname;

	/* OID of namespace containing this class */
	Oid			relnamespace BKI_DEFAULT(pg_catalog) BKI_LOOKUP(pg_namespace);

	/* OID of entry in pg_type for relation's implicit row type, if any */
	Oid			reltype BKI_LOOKUP_OPT(pg_type);

	/* OID of entry in pg_type for underlying composite type, if any */
	Oid			reloftype BKI_DEFAULT(0) BKI_LOOKUP_OPT(pg_type);

	/* class owner */
	Oid			relowner BKI_DEFAULT(POSTGRES) BKI_LOOKUP(pg_authid);

...

	/* access-method-specific options */
	text		reloptions[1] BKI_DEFAULT(_null_);

	/* partition bound node tree */
	pg_node_tree relpartbound BKI_DEFAULT(_null_);
#endif
} FormData_pg_class;

pg_class的OID写死了1259，所有字段都在FormData_pg_class结构体中。用户存储数据的结构体初始化后，会使用对应的.dat文件插入基础数据。pg_class中会插入4条数据，可以理解为bootstrap item（pg15中的数据字典表有49个）：

{ oid => '1247',
 relname => 'pg_type', reltype => 'pg_type' },
{ oid => '1249',
 relname => 'pg_attribute', reltype => 'pg_attribute' },
{ oid => '1255',
 relname => 'pg_proc', reltype => 'pg_proc' },
{ oid => '1259',
 relname => 'pg_class', reltype => 'pg_class' },

postgres=# select oid,relname from pg_class where oid::int >=1247 and oid::int<=1259;
 oid | relname 
------+--------------
 1247 | pg_type
 1249 | pg_attribute
 1255 | pg_proc
 1259 | pg_class

把基础数据字典写入后，其他的都可以依赖这些数据生成。

初始化database阶段：initdb&postgres.bki
#

initdb.c中的注释：

 * To create template1, we run the postgres (backend) program in bootstrap
 * mode and feed it data from the postgres.bki library file. After this
 * initial bootstrap phase, some additional stuff is created by normal
 * SQL commands fed to a standalone backend. 

以bootstrap模式启动backend并运行postgres.bki脚本，postgres.bki可以在没有任何系统表的情况下，执行相关函数。此后才可以使用正常的SQL文件和启动标准的backend进程。 template1可以称之为bootstrap database了，postgres、template0两个库是在template1建立以后才创建：

void
initialize_data_directory(void)
{
...
	/* Bootstrap template1 */
	bootstrap_template1();
...
	make_template0(cmdfd);

	make_postgres(cmdfd);

	PG_CMD_CLOSE;

	check_ok();
}

有了template1后，make_template0和make_postgres创建对应的template0 database和postgres database，直接用一般的SQL语句CREATE DATABASE命令创建：

/*
 * copy template1 to postgres
 */
static void
make_postgres(FILE *cmdfd)
{
	const char *const *line;

	/*
	 * Just as we did for template0, and for the same reasons, assign a fixed
	 * OID to postgres and select the file_copy strategy.
	 */
	static const char *const postgres_setup[] = {
		"CREATE DATABASE postgres OID = " CppAsString2(PostgresDbOid)
		" STRATEGY = file_copy;\n\n",
		"COMMENT ON DATABASE postgres IS 'default administrative connection database';\n\n",
		NULL
	};

	for (line = postgres_setup; *line; line++)
		PG_CMD_PUTS(*line);
}

backend本地缓存数据字典
#

PG私有内存的基础知识可参考PostgreSQL内存浅析³。

PG的数据字典信息存放在本地backend进程中，非共享。数据字典缓存主要关注的是syscache/catcache和relcache，他们分别缓存系统表和表模式信息。其中syscache/catcache是用于缓存系统表的，syscache相当于catcache的上层结构。syscache是一个数组，数字中的每个元素对应一个catcache，每个catcache对应一个系统表¹。

//PG15.3 SysCacheSize=35
static CatCache *SysCache[SysCacheSize];

pg在fork backend的时候调用的是InitPostgres，其中会调用syscache/catcache和relcache的初始化函数。下面来看看backend的初始化。

syscache/catcache初始化
#

struct cachedesc
{
	Oid			reloid;			/* OID of the relation being cached */
	Oid			indoid;			/* OID of index relation for this cache */
	int			nkeys;			/* # of keys needed for cache lookup */
	int			key[4];			/* attribute numbers of key attrs */
	int			nbuckets;		/* number of hash buckets for this cache */
};

static const struct cachedesc cacheinfo[] = {
	{
...	
	{RelationRelationId,		/* RELNAMENSP */
		ClassNameNspIndexId,
		2,
		{
			Anum_pg_class_relname,
			Anum_pg_class_relnamespace,
			0,
			0
		},
		128
	},
	{RelationRelationId,		/* RELOID */
		ClassOidIndexId,
		1,
		{
			Anum_pg_class_oid,
			0,
			0,
			0
		},
		128
...
};

例如pg_class，由genbki.pl生成的pg_class_d.h中定义Anum_pg_class_oid

#define Anum_pg_class_oid 1

reloid就是oid

 select oid,relname from pg_class where oid::int >=1247 and oid::int<=1259;
 oid | relname 
------+--------------
 1259 | pg_class

InitCatalogCache其实是初始化syscache数组，也就是初始化所有的catcache。InitCatalogCache最终通过InitCatCache全量初始化CatCache（这里其中一个就有pg_class的)：

void
InitCatalogCache(void)
{
...
	for (cacheId = 0; cacheId < SysCacheSize; cacheId++)
	{
		SysCache[cacheId] = InitCatCache(cacheId,
										 cacheinfo[cacheId].reloid,
										 cacheinfo[cacheId].indoid,
										 cacheinfo[cacheId].nkeys,
										 cacheinfo[cacheId].key,
										 cacheinfo[cacheId].nbuckets);
		if (!PointerIsValid(SysCache[cacheId]))
			elog(ERROR, "could not initialize cache %u (%d)",
				 cacheinfo[cacheId].reloid, cacheId);
		/* Accumulate data for OID lists, too */
		SysCacheRelationOid[SysCacheRelationOidSize++] =
			cacheinfo[cacheId].reloid;
		SysCacheSupportingRelOid[SysCacheSupportingRelOidSize++] =
			cacheinfo[cacheId].reloid;
		SysCacheSupportingRelOid[SysCacheSupportingRelOidSize++] =
			cacheinfo[cacheId].indoid;
		/* see comments for RelationInvalidatesSnapshotsOnly */
		Assert(!RelationInvalidatesSnapshotsOnly(cacheinfo[cacheId].reloid));
	}
...
	CacheInitialized = true;
}

然后来到catcache.c。 InitCatCache会开辟内存，并且放到CacheMemoryContext中管理。它也只是把宏定义的一些oid赋值给对应的catcache，此时还没有open表：

/*
 *		InitCatCache
 *
 *	This allocates and initializes a cache for a system catalog relation.
 *	Actually, the cache is only partially initialized to avoid opening the
 *	relation. The relation will be opened and the rest of the cache
 *	structure initialized on the first access.
 */
CatCache *
InitCatCache(int id,
			 Oid reloid,
			 Oid indexoid,
			 int nkeys,
			 const int *key,
			 int nbuckets)
{
...

	oldcxt = MemoryContextSwitchTo(CacheMemoryContext);
...
	sz = sizeof(CatCache) + PG_CACHE_LINE_SIZE;
	cp = (CatCache *) CACHELINEALIGN(palloc0(sz));
	cp->cc_bucket = palloc0(nbuckets * sizeof(dlist_head));

	/*
	 * initialize the cache's relation information for the relation
	 * corresponding to this cache, and initialize some of the new cache's
	 * other internal fields. But don't open the relation yet.
	 */
	cp->id = id;
	cp->cc_relname = "(not known yet)";
	cp->cc_reloid = reloid;
	cp->cc_indexoid = indexoid;
	cp->cc_relisshared = false; /* temporary */
	cp->cc_tupdesc = (TupleDesc) NULL;
	cp->cc_ntup = 0;
	cp->cc_nbuckets = nbuckets;
	cp->cc_nkeys = nkeys;
	for (i = 0; i < nkeys; ++i)
		cp->cc_keyno[i] = key[i];
...
	MemoryContextSwitchTo(oldcxt);

	return cp;
}

id是catcache数组元素的编号，赋值的reloid是已知的cacheinfo中的oid，也赋值了cacheinfo中的key[4]，其他信息基本都还不知道，例如relname、tupdesc，因为到这里系统表还没有open。 catcache只有在search的时候才有open的操作，虽然函数名字类似*init*，不过已经不在初始化的过程中了，相关函数不再这里展示。 syscache/catcache初始化完成后，实际上是没有任何元组信息的。

relcache初始化
#

relcache初始化这篇PostgreSQL内存浅析已经讲的比较好了。 relcache初始化由5个阶段:

RelationCacheInitialize - 初始化relcache，初始化为空的
RelationCacheInitializePhase2 - 初始化共享的catalog，并加载5个global系统表
RelationCacheInitializePhase3 - 完成初始化relcache，并加载4个基础系统表
RelationIdGetRelation - 通过relation id获得rel描述
RelationClose - 关闭一个relation

其中RelationCacheInitializePhase2 RelationCacheInitializePhase3 都有load系统表，他们有先后顺序的必要。 RelationCacheInitializePhase2有兴趣的可以自行查看函数，也load几个系统表；RelationCacheInitializePhase3 是与我们的问题相关的，我们看这个：

/*
 *		RelationCacheInitializePhase3
 *
 *		This is called as soon as the catcache and transaction system
 *		are functional and we have determined MyDatabaseId. At this point
 *		we can actually read data from the database's system catalogs.
 *		We first try to read pre-computed relcache entries from the local
 *		relcache init file. If that's missing or broken, make phony entries
 *		for the minimum set of nailed-in-cache relations. Then (unless
 *		bootstrapping) make sure we have entries for the critical system
 *		indexes. Once we've done all this, we have enough infrastructure to
 *		open any system catalog or use any catcache. The last step is to
 *		rewrite the cache files if needed.
 */
void
RelationCacheInitializePhase3(void)
{
...
	if (IsBootstrapProcessingMode() ||
		!load_relcache_init_file(false))
	{
		needNewCacheFile = true;

		formrdesc("pg_class", RelationRelation_Rowtype_Id, false,
				 Natts_pg_class, Desc_pg_class);
		formrdesc("pg_attribute", AttributeRelation_Rowtype_Id, false,
				 Natts_pg_attribute, Desc_pg_attribute);
		formrdesc("pg_proc", ProcedureRelation_Rowtype_Id, false,
				 Natts_pg_proc, Desc_pg_proc);
		formrdesc("pg_type", TypeRelation_Rowtype_Id, false,
				 Natts_pg_type, Desc_pg_type);

#define NUM_CRITICAL_LOCAL_RELS 4	/* fix if you change list above */
	}

	MemoryContextSwitchTo(oldcxt);

	/* In bootstrap mode, the faked-up formrdesc info is all we'll have */
	if (IsBootstrapProcessingMode())
		return;

...
		/* now write the files */
		write_relcache_init_file(true);
		write_relcache_init_file(false);
	}
}

IsBootstrapProcessingMode其实是专门为bootstrap模式定制的判断，一般的backend是不满足这个条件的。 load_relcache_init_file(false)尝试从initfile中加载系统表信息，load_relcache_init_file(false)传入的是false表示是私有initfile，不是共享initfile：

[postgres@16384]$ pwd
/pgdata/lzl/data15_6879/base/16384
--粗糙一点看。strings会忽略一部分信息，但是表和列名可以看到
[postgres@16384]$ strings pg_internal.init |grep pg_class
pg_class_oid_index
pg_class
pg_class_relname_nsp_index
[postgres@16384]$ strings pg_internal.init |grep -E "pg_class|relname"
pg_class_oid_index
pg_class
relname
relnamespace
pg_class_relname_nsp_index
relname
relnamespace

如果initfile损坏或者没有，那么加载initfile失败进入判断，去load 4个基础系统表：

	//跟2阶段差不多，加载更多的系统表描述
	if (IsBootstrapProcessingMode() ||
		!load_relcache_init_file(false))
	{
		needNewCacheFile = true;

		formrdesc("pg_class", RelationRelation_Rowtype_Id, false,
				 Natts_pg_class, Desc_pg_class);
		formrdesc("pg_attribute", AttributeRelation_Rowtype_Id, false,
				 Natts_pg_attribute, Desc_pg_attribute);
		formrdesc("pg_proc", ProcedureRelation_Rowtype_Id, false,
				 Natts_pg_proc, Desc_pg_proc);
		formrdesc("pg_type", TypeRelation_Rowtype_Id, false,
				 Natts_pg_type, Desc_pg_type);

有了pg_class 4个基础表，后面加载系统表信息一切都很简单了

References
#

《PostgreSQL内核分析》第2，3章 ↩︎ ↩︎
https://www.postgresql.org/docs/current/system-catalog-declarations.html ↩︎
PostgreSQL内存浅析 ↩︎

vacuum啥时候截断末尾页？

Mon, 12 Aug 2024 00:00:00 +0000

vacuum truncate
#

TRUNCATE—Specifies that VACUUM should attempt to truncate off any empty pages at the end of the table and allow the disk space for the truncated pages to be returned to the operating system. This is normally the desired behavior and is the default unless the vacuum_truncate option has been set to false for the table to be vacuumed. Setting this option to false may be useful to avoid ACCESS EXCLUSIVE lock on the table that the truncation requires. This option is ignored if the FULL option is used.

AKA，vacuum操作中的truncate选项是默认打开的，它会把表末尾的pages移除，移除的时候会获得一个表上的8级锁。今天发现某个环境上delete from删除完所有数据后，autovacuum自动触发或者手动跑vacuum，都不会回收空间。重现问题:

create table lzl1(a int);
insert into lzl1 select generate_series(1,1000) a;
analyze lzl1;

lzldb=# select relname,relpages,reltuples from pg_class where relname='lzl1';
 relname | relpages | reltuples 
---------+----------+-----------
 lzl1 | 5 | 1000

在relpage是5，最后一个页的页号是4

lzldb=> select t_ctid,lp,case lp_flags when 0 then '0:LP_UNUSED' when 1 then 'LP_NORMAL' when 2 then 'LP_REDIRECT' when 3 then 'LP_DEAD' end as lp_flags,t_xmin,t_xmax,t_field3 as t_cid, raw_flags, info.combined_flags,substring(t_data,0,40) from heap_page_items(get_raw_page('lzl1',4)) item,LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2) info order by lp;
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags | substring 
--------+----+-----------+--------+--------+-------+-----------------------------------------+----------------+------------
 (4,1) | 1 | LP_NORMAL | 772 | 0 | 0 | {HEAP_XMIN_COMMITTED,HEAP_XMAX_INVALID} | {} | \x89030000
 (4,2) | 2 | LP_NORMAL | 772 | 0 | 0 | {HEAP_XMIN_COMMITTED,HEAP_XMAX_INVALID} | {} | \x8a030000
 ...

delete from lzl1;
vacuum lzl1;

lzldb=> select t_ctid,lp,case lp_flags when 0 then '0:LP_UNUSED' when 1 then 'LP_NORMAL' when 2 then 'LP_REDIRECT' when 3 then 'LP_DEAD' end as lp_flags,t_xmin,t_xmax,t_field3 as t_cid, raw_flags, info.combined_flags,substring(t_data,0,40) from heap_page_items(get_raw_page('lzl1',4)) item,LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2) info order by lp;
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags | substring 
--------+----+-------------+--------+--------+-------+-----------+----------------+-----------
 | 1 | 0:LP_UNUSED | | | | | | 
 lzldb=# select relname,relpages,reltuples from pg_class where relname='lzl1';
 relname | relpages | reltuples 
---------+----------+-----------
 lzl2 | 5 | 0

看上去死元组都回收了，不过空间还是占用着的，page并没有回收为什么表里面都没有数据了还不做截断操作？带着这个问题来一探究竟。

should_attempt_truncation函数源码分析
#

（未声明版本的都是PG11）在vacuumlazy.c中有一个言简意赅的函数should_attempt_truncation，这个就是判断是否需要做truncation的函数：

static bool
should_attempt_truncation(LVRelStats *vacrelstats)
{
	BlockNumber possibly_freeable;

	possibly_freeable = vacrelstats->rel_pages - vacrelstats->nonempty_pages;
	if (possibly_freeable > 0 &&
		(possibly_freeable >= REL_TRUNCATE_MINIMUM ||
		 possibly_freeable >= vacrelstats->rel_pages / REL_TRUNCATE_FRACTION) &&
		old_snapshot_threshold < 0)
		return true;
	else
		return false;
}

其中

#define REL_TRUNCATE_MINIMUM 1000
#define REL_TRUNCATE_FRACTION 16

所以是否truncation的判断逻辑必须满足以下条件：

末尾空page数大于1000 或末尾空page数大于总page数的1/16
old_snapshot_threshold<0

第一个规则是为了不用老是去截断那先零零碎碎的末尾空page，这回收不了多少空间，不仅浪费时间还浪费8级锁，没有必要。第二个规则是这样解释的：

 * Also don't attempt it if we are doing early pruning/vacuuming, because a
 * scan which cannot find a truncated heap page cannot determine that the
 * snapshot is too old to read that page. We might be able to get away with
 * truncating all except one of the pages, setting its LSN to (at least) the
 * maximum of the truncated range if we also treated an index leaf tuple
 * pointing to a missing heap page as something to trigger the "snapshot too
 * old" error, but that seems fragile and seems like it deserves its own patch
 * if we consider it.

“因为vacuum扫描还不能确认page上的数据是否有快照过久问题，里面还有些LSN、索引页问题，代码逻辑看起来很琐碎，如果需要这个功能的话，需要一个patch来解决这个问题” OK，看起来就是没有去判断page是否真的有快照过久问题，那么简单粗暴地以old_snapshot_threshold<0来判断，数据库本身关闭了快照过久问题，才会去truncation。

回到之前的vacuum没有回收的问题，因为是delete删除了所有数据，所以肯定满足“末尾空page数大于总page数的1/16”，然而环境中的old_snapshot_threshold确是打开的：

lzldb=> show old_snapshot_threshold ;
 old_snapshot_threshold 
------------------------
 1h

关闭old_snapshot_threshold再去做这个delete全表+vacuum就会回收了。关闭old_snapshot_threshold需要重启数据库。

--重启后
lzldb=> show old_snapshot_threshold ;
 old_snapshot_threshold 
------------------------
 -1
lzldb=> select pg_relation_filepath('lzl1');
 pg_relation_filepath 
----------------------
 base/16384/16446

lzldb=> vacuum lzl1; 
--pages成功回收
lzldb=# select relname,relpages,reltuples from pg_class where relname='lzl1';
 relname | relpages | reltuples 
---------+----------+-----------
 lzl1 | 0 | 0
--没有重建表 
lzldb=> select pg_relation_filepath('lzl1');
 pg_relation_filepath 
----------------------
 base/16384/16446

pages全部成功回收，表没有重建。问题就算定位完了。不过为了更进一步了解vacuum truncation机制，还可以继续看看下面的章节。

lazy_truncate_heap函数源码分析
#

仅仅通过should_attempt_truncation函数来判断是否truncation还不严谨，还要看一眼真正执行truncation的函数lazy_truncate_heap，里面还有一些判断

/*
 * lazy_truncate_heap - try to truncate off any empty pages at the end
 */
static void
lazy_truncate_heap(Relation onerel, LVRelStats *vacrelstats)
{
	BlockNumber old_rel_pages = vacrelstats->rel_pages;
	BlockNumber new_rel_pages;
	int			lock_retry;

	/* Report that we are now truncating */
	pgstat_progress_update_param(PROGRESS_VACUUM_PHASE,
								 PROGRESS_VACUUM_PHASE_TRUNCATE);

	/*
	 * Loop until no more truncating can be done.
	 */
	do
	{
		PGRUsage	ru0;

		pg_rusage_init(&ru0);

		/*
		 * We need full exclusive lock on the relation in order to do
		 * truncation. If we can't get it, give up rather than waiting --- we
		 * don't want to block other backends, and we don't want to deadlock
		 * (which is quite possible considering we already hold a lower-grade
		 * lock).
		 */
		vacrelstats->lock_waiter_detected = false;
		lock_retry = 0;
		while (true)
		{	
			//如果可以获得锁，break while
			if (ConditionalLockRelation(onerel, AccessExclusiveLock))
				break;

			/*
			 * Check for interrupts while trying to (re-)acquire the exclusive
			 * lock.
			 */
			CHECK_FOR_INTERRUPTS();
			
			//如果没有立即获得锁，最初(++lock_retry)=1，不大于100；当大于100时，不做truncation直接返回
			if (++lock_retry > (VACUUM_TRUNCATE_LOCK_TIMEOUT /
								VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL))
			{
				/*
				 * We failed to establish the lock in the specified number of
				 * retries. This means we give up truncating.
				 */
				vacrelstats->lock_waiter_detected = true;
				ereport(elevel,
						(errmsg("\"%s\": stopping truncate due to conflicting lock request",
								RelationGetRelationName(onerel))));
				return;
			}
			
			//sleep 50ms，看起来有点笨。理论上最长可以等50*100=5s
			pg_usleep(VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL * 1000L);
		}

		//当我们拿到排他锁后，查看vacuum过程中是否有新元组，如有则不做truncation
		new_rel_pages = RelationGetNumberOfBlocks(onerel);
		if (new_rel_pages != old_rel_pages)
		{
			UnlockRelation(onerel, AccessExclusiveLock);
			return;
		}

		new_rel_pages = count_nondeletable_pages(onerel, vacrelstats);
		//如果vacuum过程中有新元组写入，不做truncation
		if (new_rel_pages >= old_rel_pages)
		{
			/* can't do anything after all */
			UnlockRelation(onerel, AccessExclusiveLock);
			return;
		}

		/*
		 * Okay to truncate.
		 */
		RelationTruncate(onerel, new_rel_pages);

		//truncation后立即释放锁
		UnlockRelation(onerel, AccessExclusiveLock);

...
	} while (new_rel_pages > vacrelstats->nonempty_pages &&
			 vacrelstats->lock_waiter_detected);
}

其中

#define VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL 50 /* 微秒！！ */
#define VACUUM_TRUNCATE_LOCK_TIMEOUT 5000 /* 微秒！！ */

真正调用的主题函数是RelationTruncate，前面一大截都是在尝试获取AccessExclusiveLock。除了之前说的2个条件外，还有以下两种情况不会做truncation

没有获得AccessExclusiveLock
vacuum过程中有新数据写入

vacuum truncate可能会等待5秒
#

上面翻lazy_truncate_heap源码的时候，发现循环获取锁那里的等待时间是有点笨：

pg_usleep(VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL * 1000L);

这里每次循环会等待50ms，理论上最长可以等50*100=5s！测试一把这个等待时间：

窗口1	窗口2
create table lzl2;
alter table lzl2 set (autovacuum_enabled=off);;
insert into lzl2 select generate_series(1,1000) a;
delete from lzl2;
begin;
select * from lzl2;
	\timing
	vacuum lzl2; –Time: 5022.122 ms (00:05.022)
可以看到等待时间约5s。
手速快的话还可以再开个窗口抓下会话2的pstack

[postgres@cncq081298 lzl]$ pstack 4113
#0 0x00002b92a978c013 in __select_nocancel () from /lib64/libc.so.6
#1 0x000000000086225a in pg_usleep (microsec=microsec@entry=50000) at pgsleep.c:56
#2 0x00000000005e8212 in lazy_truncate_heap (vacrelstats=0xfc4490, onerel=0x2b92a8bc88d8) at vacuumlazy.c:1861
#3 lazy_vacuum_rel (onerel=onerel@entry=0x2b92a8bc88d8, options=options@entry=5, params=params@entry=0x7ffc96bb31d0, bstrategy=<optimized out>) at vacuumlazy.c:290
#4 0x00000000005e4551 in vacuum_rel (relid=32778, relation=<optimized out>, options=options@entry=5, params=params@entry=0x7ffc96bb31d0) at vacuum.c:1572
#5 0x00000000005e55ac in vacuum (options=5, relations=0xfc6540, params=params@entry=0x7ffc96bb31d0, bstrategy=<optimized out>, bstrategy@entry=0x0, isTopLevel=isTopLevel@entry=true) at vacuum.c:340
...

它走到了lazy_truncate_heap上的pg_usleep ，传入entry=50000 microsec，实际上pg_usleep循环了100次，总等待时间是50000*100 microsec=5s。

后来PG15这段代码更优化了，把pg_usleep改成WaitLatch

(void) WaitLatch(MyLatch,
WL_LATCH_SET | WL_TIMEOUT | WL_EXIT_ON_PM_DEATH,
VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL,
WAIT_EVENT_VACUUM_TRUNCATE);
ResetLatch(MyLatch);

vacuum truncate小结
#

vacuum触发truncation的条件（且）：

末尾空page数大于1000 或末尾空page数大于总page数的1/16
old_snapshot_threshold<0
PG15（不含）以前需要在5s内获得8级锁AccessExclusiveLock
vacuum过程中没有新数据写入

从很慢的唯一索引扫描到索引膨胀

Mon, 12 Aug 2024 00:00:00 +0000

走主键的SQL是怎么访问了多个数据页的？
#

书接上回：长事务、表膨胀、limit问题的一个经典案例，这篇文章有一个点没有说的很仔细：为什么一个走主键的SQL会产生那么多shared hit？为什么索引膨胀会导致访问多个数据页呢？页内的HOT只要一个数据页访问，页外的数据难道不可以通过访问对应的那一条索引条目来定位？这跟索引的版本管理有关系了，其实索引还是有一点版本信息的，但不多。先温故一下pg的btree索引结构（https://en.wikibooks.org/wiki/PostgreSQL/Index_Btree）这个pg btree wiki图其实没有解释死元组和死索引条目的访问方式，它没有版本信息。目前不用硬理解这个结构的所有细节，知道有这么个btree结构就行。

为了搞清楚btree的版本访问问题，我们来做个测试：

create table tab1(a bigserial,b char(1000));
create index idx_tab1_a on tab1(a);
alter table tab1 set (autovacuum_enabled = off); --关闭autovacuum
alter table tab1 alter column b set storage PLAIN; --关闭toast

lzldb=> insert into tab1(b) values('zzzzzzzzz');
INSERT 0 1
--查看数据页上的元组信息
lzldb=> select t_ctid,lp,case lp_flags when 0 then 'LP_UNUSED' when 1 then 'LP_NORMAL' when 2 then 'LP_REDIRECT' when 3 then 'LP_DEAD' end as lp_flags,t_xmin,t_xmax,t_field3 as t_cid, raw_flags, info.combined_flags from heap_page_items(get_raw_page('tab1',0)) item,LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2) info order by lp;
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags 
--------+----+-----------+--------+--------+-------+--------------------------------------+----------------
 (0,1) | 1 | LP_NORMAL | 111875 | 0 | 0 | {HEAP_HASVARWIDTH,HEAP_XMAX_INVALID} | {}

--查看索引页上索引条目信息（注意索引0号页是meta页，没有数据）
lzldb=> SELECT itemoffset, ctid, itemlen, nulls, vars, data, dead, htid, tids[0:2] AS some_tids FROM bt_page_items('idx_tab1_a',1);
 itemoffset | ctid | itemlen | nulls | vars | data | dead | htid | some_tids 
------------+-------+---------+-------+------+-------------------------+------+-------+-----------
 1 | (0,1) | 16 | f | f | 01 00 00 00 00 00 00 00 | f | (0,1) | 

仅插入一条数据，数据页page 0上只有1个元组，索引页page 1上只有一个条目指向ctid(0,1)

lzldb=> update tab1 set b='xxxxxxx' ;
UPDATE 1
lzldb=> select t_ctid,lp,case lp_flags when 0 then 'LP_UNUSED' when 1 then 'LP_NORMAL' when 2 then 'LP_REDIRECT' when 3 then 'LP_DEAD' end as lp_flags,t_xmin,t_xmax,t_field3 as t_cid, raw_flags, info.combined_flags from heap_page_items(get_raw_page('tab1',0)) item,LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2) info order by lp;
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags 
--------+----+-----------+--------+--------+-------+-------------------------------------------------------------------+----------------
 (0,2) | 1 | LP_NORMAL | 111875 | 111876 | 0 | {HEAP_HASVARWIDTH,HEAP_XMIN_COMMITTED,HEAP_HOT_UPDATED} | {}
 (0,2) | 2 | LP_NORMAL | 111876 | 0 | 0 | {HEAP_HASVARWIDTH,HEAP_XMAX_INVALID,HEAP_UPDATED,HEAP_ONLY_TUPLE} | {}
(2 rows)

lzldb=> SELECT itemoffset, ctid, itemlen, nulls, vars, data, dead, htid, tids[0:2] AS some_tids FROM bt_page_items('idx_tab1_a',1);
 itemoffset | ctid | itemlen | nulls | vars | data | dead | htid | some_tids 
------------+-------+---------+-------+------+-------------------------+------+-------+-----------
 1 | (0,1) | 16 | f | f | 01 00 00 00 00 00 00 00 | f | (0,1) | 

更新一条数据，数据页page 0上有2个元组，活着的只有ctid(0,2)，lp=1的元组是“死”的了，但是lp_flags还是“NORMAL”的！索引页page 1上只有一个条目指向ctid(0,1)，也就是“死”元组。这个就是HOT的原理，块内更新数据时不会更新索引条目，索引通过指向死元组的ctid链去找到真正活着的数据元组。

循环更新10次，造成2个数据页和1个索引页：

DO $$
begin
	FOR i IN 1..10 LOOP
		update tab1 set b=md5(i::text);
	END LOOP; 
end $$;;

更新后：

--第一个数据页
lzldb=> select t_ctid,lp,case lp_flags when 0 then 'LP_UNUSED' when 1 then 'LP_NORMAL' when 2 then 'LP_REDIRECT' when 3 then 'LP_DEAD' end as lp_flags,t_xmin,t_xmax,t_field3 as t_cid, raw_flags, info.combined_flags from heap_page_items(get_raw_page('tab1',0)) item,LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2) info order by lp;
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flag
s 
--------+----+-------------+--------+--------+-------+--------------------------------------------------------------------------------------+--------------
--
 | 1 | LP_REDIRECT | | | | | 
 (0,3) | 2 | LP_NORMAL | 111876 | 111877 | 0 | {HEAP_HASVARWIDTH,HEAP_XMIN_COMMITTED,HEAP_UPDATED,HEAP_HOT_UPDATED,HEAP_ONLY_TUPLE} | {}
 (0,4) | 3 | LP_NORMAL | 111877 | 111877 | 0 | {HEAP_HASVARWIDTH,HEAP_COMBOCID,HEAP_UPDATED,HEAP_HOT_UPDATED,HEAP_ONLY_TUPLE} | {}
 (0,5) | 4 | LP_NORMAL | 111877 | 111877 | 1 | {HEAP_HASVARWIDTH,HEAP_COMBOCID,HEAP_UPDATED,HEAP_HOT_UPDATED,HEAP_ONLY_TUPLE} | {}
 (0,6) | 5 | LP_NORMAL | 111877 | 111877 | 2 | {HEAP_HASVARWIDTH,HEAP_COMBOCID,HEAP_UPDATED,HEAP_HOT_UPDATED,HEAP_ONLY_TUPLE} | {}
 (0,7) | 6 | LP_NORMAL | 111877 | 111877 | 3 | {HEAP_HASVARWIDTH,HEAP_COMBOCID,HEAP_UPDATED,HEAP_HOT_UPDATED,HEAP_ONLY_TUPLE} | {}
 (1,1) | 7 | LP_NORMAL | 111877 | 111877 | 4 | {HEAP_HASVARWIDTH,HEAP_COMBOCID,HEAP_UPDATED,HEAP_ONLY_TUPLE} | {}
(7 rows)
--第二个数据页
lzldb=> select t_ctid,lp,case lp_flags when 0 then 'LP_UNUSED' when 1 then 'LP_NORMAL' when 2 then 'LP_REDIRECT' when 3 then 'LP_DEAD' end as lp_flags,t_xmin,t_xmax,t_field3 as t_cid, raw_flags, info.combined_flags from heap_page_items(get_raw_page('tab1',1)) item,LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2) info order by lp;
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags 
--------+----+-----------+--------+--------+-------+--------------------------------------------------------------------------------+----------------
 (1,2) | 1 | LP_NORMAL | 111877 | 111877 | 5 | {HEAP_HASVARWIDTH,HEAP_COMBOCID,HEAP_UPDATED,HEAP_HOT_UPDATED} | {}
 (1,3) | 2 | LP_NORMAL | 111877 | 111877 | 6 | {HEAP_HASVARWIDTH,HEAP_COMBOCID,HEAP_UPDATED,HEAP_HOT_UPDATED,HEAP_ONLY_TUPLE} | {}
 (1,4) | 3 | LP_NORMAL | 111877 | 111877 | 7 | {HEAP_HASVARWIDTH,HEAP_COMBOCID,HEAP_UPDATED,HEAP_HOT_UPDATED,HEAP_ONLY_TUPLE} | {}
 (1,5) | 4 | LP_NORMAL | 111877 | 111877 | 8 | {HEAP_HASVARWIDTH,HEAP_COMBOCID,HEAP_UPDATED,HEAP_HOT_UPDATED,HEAP_ONLY_TUPLE} | {}
 (1,5) | 5 | LP_NORMAL | 111877 | 0 | 9 | {HEAP_HASVARWIDTH,HEAP_XMAX_INVALID,HEAP_UPDATED,HEAP_ONLY_TUPLE} | {}

第一个数据页page 0通过LP_REDIRECT的状态可以直接判断当前数据页肯定有HOT，此时的lp1上是没有任何其他任何信息的，甚至连ctid，data、infomask都没有。无法这条lp找到最终的数据，对于索引第一个个条目来说，访问到ctid(0,1)就可以了，这个数据页里面没有想要的数据行。但是数据页2是有没有LP_REDIRECT的，索引可以通过找到ctid(1,0)的ctid链，找到页内的活元组(1,5)。源码对line pointer状态的解释：

/*
 *lp_flags has these possible states. An UNUSED line pointer is available
 *for immediate re-use, the other states are not.
 */
#define LP_UNUSED		0		/* unused (should always have lp_len=0) */
#define LP_NORMAL		1		/* used (should always have lp_len>0) */
#define LP_REDIRECT		2		/* HOT redirect (should have lp_len=0)，其实不是HOT，而是页外的redirect标识 */
#define LP_DEAD			3		/* dead, may or may not have storage */

//对LP_REDIRECT的解释
Redirecting line pointer

	A line pointer that points to another line pointer and has no
	associated tuple. It has the special lp_flags state LP_REDIRECT,
	and lp_off is the OffsetNumber of the line pointer it links to.
	This is used when a root tuple becomes dead but we cannot prune
	the line pointer because there are non-dead heap-only tuples
	further down the chain.

再仔细回看会发现，我们认为的“死”元组的lp状态是LP_NORMAL，而不是LP_DEAD。这个很重要，因为后面还会用到这个知识点。

继续查看索引页：

lzldb=> SELECT itemoffset, ctid, itemlen, nulls, vars, data, dead, htid, tids[0:2] AS some_tids FROM bt_page_items('idx_tab1_a',1);
 itemoffset | ctid | itemlen | nulls | vars | data | dead | htid | some_tids 
------------+-------+---------+-------+------+-------------------------+------+-------+-----------
 1 | (0,1) | 16 | f | f | 01 00 00 00 00 00 00 00 | f | (0,1) | 
 2 | (1,1) | 16 | f | f | 01 00 00 00 00 00 00 00 | f | (1,1) | 

因为多了一个页，HOT不再适用，此时索引被更新了，索引页只有2个条目，而且都是活的dead=f，均指向各自page的第一个元组：(0,1) 和（1,1）。页外的更新，索引页也会更新，每个索引条目指向各自的页。请注意，此时表里只有1条数据，索引有2个条目且都是活的，这也是为什么主键扫描会访问多个数据页。

再多更新一些数据，造成索引也是多个页：

DO $$
begin
	FOR i IN 1..10000 LOOP
		update tab1 set b=md5(i::text);
	END LOOP; 
end $$;

--第一个索引页
lzldb=> SELECT itemoffset, ctid, itemlen, nulls, vars, data, dead, htid, tids[0:2] AS some_tids FROM bt_page_items('idx_tab1_a',1);
 itemoffset | ctid | itemlen | nulls | vars | data | dead | htid | some_tids 
------------+-------------+---------+-------+------+-------------------------+------+----------+-------------------------
 1 | (1278,4097) | 24 | f | f | 01 00 00 00 00 00 00 00 | | (1277,1) | 
 2 | (16,8414) | 1352 | f | f | 01 00 00 00 00 00 00 00 | f | (0,1) | {"(0,1)","(1,1)"}
 3 | (16,8414) | 1352 | f | f | 01 00 00 00 00 00 00 00 | f | (222,1) | {"(222,1)","(223,1)"}
 4 | (16,8414) | 1352 | f | f | 01 00 00 00 00 00 00 00 | f | (444,1) | {"(444,1)","(445,1)"}
 5 | (16,8414) | 1352 | f | f | 01 00 00 00 00 00 00 00 | f | (666,1) | {"(666,1)","(667,1)"}
 6 | (16,8414) | 1352 | f | f | 01 00 00 00 00 00 00 00 | f | (888,1) | {"(888,1)","(889,1)"}

--第2个索引页
lzldb=> SELECT itemoffset, ctid, itemlen, nulls, vars, data, dead, htid, tids[0:2] AS some_tids FROM bt_page_items('idx_tab1_a',2);
 itemoffset | ctid | itemlen | nulls | vars | data | dead | htid | some_tids 
------------+----------+---------+-------+------+-------------------------+------+----------+-----------
 1 | (1278,1) | 16 | f | f | 01 00 00 00 00 00 00 00 | f | (1278,1) | 
 2 | (1279,1) | 16 | f | f | 01 00 00 00 00 00 00 00 | f | (1279,1) | 
 3 | (1280,1) | 16 | f | f | 01 00 00 00 00 00 00 00 | f | (1280,1) | 
 4 | (1281,1) | 16 | f | f | 01 00 00 00 00 00 00 00 | f | (1281,1) | 
...
 152 | (1429,1) | 16 | f | f | 01 00 00 00 00 00 00 00 | f | (1429,1) | 
 153 | (1430,1) | 16 | f | f | 01 00 00 00 00 00 00 00 | f | (1430,1) | 
(153 rows)

--第3个索引页
lzldb=> SELECT itemoffset, ctid, itemlen, nulls, vars, data, dead, htid, tids[0:2] AS some_tids FROM bt_page_items('idx_tab1_a',3);
 itemoffset | ctid | itemlen | nulls | vars | data | dead | htid | some_tids 
------------+----------+---------+-------+------+-------------------------+------+----------+-----------
 1 | (1,0) | 8 | f | f | | | | 
 2 | (2,4097) | 24 | f | f | 01 00 00 00 00 00 00 00 | | (1277,1) | 

总共3个索引页，page1 是root节点，page 2和page 3是叶节点。他们的索引条目的dead状态都是“f”的

此时再回到sql，用主键索引

lzldb=> explain (analyze,buffers) select * from tab1 where a=1;
 QUERY PLAN 
-----------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on tab1 (cost=4.39..56.41 rows=14 width=4012) (actual time=2.594..2.596 rows=1 loops=1)
 Recheck Cond: (a = 1)
 Heap Blocks: exact=1
 Buffers: shared hit=1437 dirtied=1026
 -> Bitmap Index Scan on idx_tab1_a (cost=0.00..4.39 rows=14 width=0) (actual time=0.152..0.153 rows=1431 loops=1)
 Index Cond: (a = 1)
 Buffers: shared hit=6
 Planning:
 Buffers: shared hit=5
 Planning Time: 0.087 ms
 Execution Time: 2.614 ms

此时用主键查询，shared hit有1437，跟表的page有1430是差不多对得上的。由于索引没有版本信息，而且索引条目的dead状态没有被更新，所以pg根据所有活的索引条目去数据页中找版本信息。这就是为什么走主键索引的SQL可以很慢。

kill index item
#

由于索引没有存储可见性信息（即MVCC版本信息），索引所指向的元组的可见性信息决定了索引可见性本身。这也是为什么pg中的index-only-scan还是会访问数据页。当然有vm的话，vm会保留all-visible和all-frozen的数据页是哪些，此时的index-only-scan不会访问这些数据页，因为他们都可见了。即便没有vacuum，pg内核仍有处理此类索引膨胀问题的方法——kill index item。这个特性有时候也叫Simple deletion or index deletion（src/backend/access/nbtree/README的叫法），总之是将已经为LP_DEAD的元组所对应的索引条目标记为dead，不改变原有的索引结构。源码函数_bt_killitems：

* _bt_killitems - set LP_DEAD state for items an indexscan caller has
* told us were killed

明确说明是索引扫描触发kill item操作（也就是说select也可能触发这个操作从而更新索引）。这也很好测试。因为之前的数据已经有过索引扫描了，我们重新造数据来测试。

create table tab2(a bigserial,b char(100));
create index idx_tab2_a on tab2(a);
create index idx_tab2_b on tab2(b);
alter table tab2 set (autovacuum_enabled = off); --关闭autovacuum
alter table tab2 alter column b set storage PLAIN; --关闭toast
--插入1条数据并反复更新
insert into tab2(b) values('00000');

DO $$
begin
	FOR i IN 1..10000 LOOP
		update tab2 set b=i::text;
	END LOOP; 
end $$;

--表的页
lzldb=> select t_ctid,lp,case lp_flags when 0 then 'LP_UNUSED' when 1 then 'LP_NORMAL' when 2 then 'LP_REDIRECT' when 3 then 'LP_DEAD' end as lp_flags,t_xmin,t_xmax,t_field3 as t_cid, raw_flags, info.combined_flags from heap_page_items(get_raw_page('tab2',2)) item,LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2) info order by lp;
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags 
--------+----+-----------+--------+--------+-------+-----------------------------------------------+----------------
 (2,2) | 1 | LP_NORMAL | 509 | 509 | 115 | {HEAP_HASVARWIDTH,HEAP_COMBOCID,HEAP_UPDATED} | {}
 (2,3) | 2 | LP_NORMAL | 509 | 509 | 116 | {HEAP_HASVARWIDTH,HEAP_COMBOCID,HEAP_UPDATED} | {}
 (2,4) | 3 | LP_NORMAL | 509 | 509 | 117 | {HEAP_HASVARWIDTH,HEAP_COMBOCID,HEAP_UPDATED} | {}
 (2,5) | 4 | LP_NORMAL | 509 | 509 | 118 | {HEAP_HASVARWIDTH,HEAP_COMBOCID,HEAP_UPDATED} | {}
 (2,6) | 5 | LP_NORMAL | 509 | 509 | 119 | {HEAP_HASVARWIDTH,HEAP_COMBOCID,HEAP_UPDATED} | {}
 (2,7) | 6 | LP_NORMAL | 509 | 509 | 120 | {HEAP_HASVARWIDTH,HEAP_COMBOCID,HEAP_UPDATED} | {}
 (2,8) | 7 | LP_NORMAL | 509 | 509 | 121 | {HEAP_HASVARWIDTH,HEAP_COMBOCID,HEAP_UPDATED} | {}
...

--a索引的页
lzldb=> SELECT itemoffset, ctid, itemlen, nulls, vars, dead, htid, tids[0:2] AS some_tids FROM bt_page_items('idx_tab2_a',4);
 itemoffset | ctid | itemlen | nulls | vars | dead | htid | some_tids 
------------+-----------+---------+-------+------+------+---------+-----------------------
 1 | (66,4097) | 24 | f | f | | (66,6) | 
 2 | (16,8414) | 1352 | f | f | f | (44,5) | {"(44,5)","(44,6)"}
 3 | (16,8414) | 1352 | f | f | f | (47,53) | {"(47,53)","(47,54)"}
 4 | (16,8414) | 1352 | f | f | f | (51,43) | {"(51,43)","(51,44)"}
 5 | (16,8414) | 1352 | f | f | f | (55,33) | {"(55,33)","(55,34)"}
 6 | (16,8414) | 1352 | f | f | f | (59,23) | {"(59,23)","(59,24)"}
 7 | (16,8360) | 1024 | f | f | f | (63,13) | {"(63,13)","(63,14)"}
--b索引的页
lzldb=> SELECT itemoffset, ctid, itemlen, nulls, vars, dead, htid, tids[0:2] AS some_tids FROM bt_page_items('idx_tab2_b',4);
 itemoffset | ctid | itemlen | nulls | vars | dead | htid | some_tids 
------------+---------+---------+-------+------+------+---------+-----------
 1 | (57,1) | 112 | f | t | | | 
 2 | (0,34) | 112 | f | t | f | (0,34) | 
 3 | (5,41) | 112 | f | t | f | (5,41) | 
 4 | (56,53) | 112 | f | t | f | (56,53) | 
 5 | (56,54) | 112 | f | t | f | (56,54) | 
 6 | (56,55) | 112 | f | t | f | (56,55) | 
 7 | (56,56) | 112 | f | t | f | (56,56) | 
 8 | (56,57) | 112 | f | t | f | (56,57) | 

此时用全表扫描的方式查一次表，再次查看数据元组和索引条目的状态

lzldb=> explain (analyze,buffers) select * from tab2;
 QUERY PLAN 
-----------------------------------------------------------------------------------------------------
 Seq Scan on tab2 (cost=0.00..204.14 rows=3114 width=412) (actual time=1.077..1.079 rows=1 loops=1)
 Buffers: shared hit=173 dirtied=173
 Planning Time: 0.042 ms
 Execution Time: 1.090 ms
lzldb=> select t_ctid,lp,case lp_flags when 0 then 'LP_UNUSED' when 1 then 'LP_NORMAL' when 2 then 'LP_REDIRECT' when 3 then 'LP_DEAD' end as lp_flags,t_xmin,t_xmax,t_field3 as t_cid, raw_flags, info.combined_flags from heap_page_items(get_raw_page('tab2',4)) item,LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2) info order by lp;
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags 
--------+----+----------+--------+--------+-------+-----------+----------------
 | 1 | LP_DEAD | | | | | 
 | 2 | LP_DEAD | | | | | 
 | 3 | LP_DEAD | | | | | 
 | 4 | LP_DEAD | | | | | 
 | 5 | LP_DEAD | | | | | 
 | 6 | LP_DEAD | | | | | 
 | 7 | LP_DEAD | | | | | 

lzldb=> SELECT itemoffset, ctid, itemlen, nulls, vars, dead, htid, tids[0:2] AS some_tids FROM bt_page_items('idx_tab2_a',4);
 itemoffset | ctid | itemlen | nulls | vars | dead | htid | some_tids 
------------+-----------+---------+-------+------+------+---------+-----------------------
 1 | (66,4097) | 24 | f | f | | (66,6) | 
 2 | (16,8414) | 1352 | f | f | f | (44,5) | {"(44,5)","(44,6)"}
 3 | (16,8414) | 1352 | f | f | f | (47,53) | {"(47,53)","(47,54)"}
 4 | (16,8414) | 1352 | f | f | f | (51,43) | {"(51,43)","(51,44)"}
 5 | (16,8414) | 1352 | f | f | f | (55,33) | {"(55,33)","(55,34)"}
 6 | (16,8414) | 1352 | f | f | f | (59,23) | {"(59,23)","(59,24)"}
 7 | (16,8360) | 1024 | f | f | f | (63,13) | {"(63,13)","(63,14)"}
(7 rows)

lzldb=> SELECT itemoffset, ctid, itemlen, nulls, vars, dead, htid, tids[0:2] AS some_tids FROM bt_page_items('idx_tab2_b',4);
 itemoffset | ctid | itemlen | nulls | vars | dead | htid | some_tids 
------------+---------+---------+-------+------+------+---------+-----------
 1 | (57,1) | 112 | f | t | | | 
 2 | (0,34) | 112 | f | t | f | (0,34) | 
 3 | (5,41) | 112 | f | t | f | (5,41) | 
 4 | (56,53) | 112 | f | t | f | (56,53) | 
 5 | (56,54) | 112 | f | t | f | (56,54) | 
 6 | (56,55) | 112 | f | t | f | (56,55) | 
 7 | (56,56) | 112 | f | t | f | (56,56) | 

数据元组，除了最后一个页其他都被标记为了LP_DEAD。索引条目，什么都没动。再用a索引查询一次表

lzldb=> explain (analyze,buffers) select * from tab2 where a=1;
 QUERY PLAN 
---------------------------------------------------------------------------------------------------------------------
 Index Scan using idx_tab2_a on tab2 (cost=0.28..68.56 rows=16 width=412) (actual time=1.282..1.510 rows=1 loops=1)
 Index Cond: (a = 1)
 Buffers: shared hit=190 dirtied=8
 Planning Time: 0.058 ms
 Execution Time: 1.525 ms
(5 rows)

lzldb=> select t_ctid,lp,case lp_flags when 0 then 'LP_UNUSED' when 1 then 'LP_NORMAL' when 2 then 'LP_REDIRECT' when 3 then 'LP_DEAD' end as lp_flags,t_xmin,t_xmax,t_field3 as t_cid, raw_flags, info.combined_flags from heap_page_items(get_raw_page('tab2',0)) item,LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2) info order by lp;
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags 
--------+----+----------+--------+--------+-------+-----------+----------------
 | 1 | LP_DEAD | | | | | 
 | 2 | LP_DEAD | | | | | 
 | 3 | LP_DEAD | | | | | 
 | 4 | LP_DEAD | | | | | 
 | 5 | LP_DEAD | | | | | 
 | 6 | LP_DEAD | | | | | 
lzldb=> SELECT itemoffset, ctid, itemlen, nulls, vars, dead, htid, tids[0:2] AS some_tids FROM bt_page_items('idx_tab2_a',4);
 itemoffset | ctid | itemlen | nulls | vars | dead | htid | some_tids 
------------+-----------+---------+-------+------+------+---------+-----------------------
 1 | (66,4097) | 24 | f | f | | (66,6) | 
 2 | (16,8414) | 1352 | f | f | t | (44,5) | {"(44,5)","(44,6)"}
 3 | (16,8414) | 1352 | f | f | t | (47,53) | {"(47,53)","(47,54)"}
 4 | (16,8414) | 1352 | f | f | t | (51,43) | {"(51,43)","(51,44)"}
 5 | (16,8414) | 1352 | f | f | t | (55,33) | {"(55,33)","(55,34)"}
 6 | (16,8414) | 1352 | f | f | t | (59,23) | {"(59,23)","(59,24)"}
 7 | (16,8360) | 1024 | f | f | t | (63,13) | {"(63,13)","(63,14)"}
(7 rows)

lzldb=> SELECT itemoffset, ctid, itemlen, nulls, vars, dead, htid, tids[0:2] AS some_tids FROM bt_page_items('idx_tab2_b',4);
 itemoffset | ctid | itemlen | nulls | vars | dead | htid | some_tids 
------------+---------+---------+-------+------+------+---------+-----------
 1 | (57,1) | 112 | f | t | | | 
 2 | (0,34) | 112 | f | t | f | (0,34) | 
 3 | (5,41) | 112 | f | t | f | (5,41) | 
 4 | (56,53) | 112 | f | t | f | (56,53) | 
 5 | (56,54) | 112 | f | t | f | (56,54) | 
 6 | (56,55) | 112 | f | t | f | (56,55) | 
 7 | (56,56) | 112 | f | t | f | (56,56) | 

索引a的死元组都被标记为了dead=t，而索引b的死元组还是dead=f，因为我们没有扫描过索引b。此时再次通过索引a查询表

lzldb=> explain (analyze,buffers) select * from tab2 where a=1;
 QUERY PLAN 
---------------------------------------------------------------------------------------------------------------------
 Index Scan using idx_tab2_a on tab2 (cost=0.28..68.56 rows=16 width=412) (actual time=0.020..0.021 rows=1 loops=1)
 Index Cond: (a = 1)
 Buffers: shared hit=10
 Planning Time: 0.059 ms
 Execution Time: 0.033 ms

因为索引a上的死元组对应的索引条目都被标记为了dead=t，所以不需要再通过数据页上的版本信息来判断元组是不是“活”的。为什么这里的shared hit=10呢，还是稍微有点多？因为kill index item只会标记死亡的索引条目，不会改变索引结构，索引页数没有减少，这10个shared hit就是10个索引页（包含meta页）。

lzldb=> analyze tab2;
ANALYZE
lzldb=> select relname,relpages,reltuples from pg_class where relname='idx_tab2_a';
 relname | relpages | reltuples 
------------+----------+-----------
 idx_tab2_a | 10 | 1

Bottom-Up deletion
#

在pg14中，index deletion功能的触发条件有增强。前面已经提到，触发index deletion的条件是扫描索引，pg14中还可以在即将发生索引分裂时，触发index deletion，以找到空闲的索引空间，减少索引分裂的概率。当然这个特性减少了索引分离，也同样减少了索引膨胀，从而缓解索引膨胀带来的问题。

具体的测试可参考：INDEX BLOAT REDUCED IN POSTGRESQL V14

index deduplication
#

pg13引入了index deduplication的特性，它将GIN索引的posting list思想，引入到btree索引中，以减少btree重复索引占用的空间并缓解索引分裂问题。原本btree索引条目只指向一个ctid（就像我们前面测试看到的那样），有了deduplicate index item，一个索引条目可以有一个posting list，一个posting list可以存放多个ctid。

The representation of posting lists is almost identical to the posting lists used by GIN

like GIN posting tree(list)（*btree的posting list不一定是这个结构，待研究）：（https://postgrespro.com/blog/pgsql/4261647）

对index deduplication的测试：

create table tab3(same char(100),diff char(100));
create index idx_tab3_same on tab3(same);
create index idx_tab3_diff on tab3(diff);
insert into tab3 select 10000::text,i::text from generate_series(10000, 99999) as i;

lzldb=> SELECT itemoffset, ctid, itemlen, nulls, vars, dead, htid, tids[0:2] AS some_tids FROM bt_page_items('idx_tab3_same',4);
 itemoffset | ctid | itemlen | nulls | vars | dead | htid | some_tids 
------------+------------+---------+-------+------+------+----------+-----------------------
 1 | (104,4097) | 120 | f | t | | (104,10) | 
 2 | (112,8398) | 1352 | f | t | f | (69,19) | {"(69,19)","(69,20)"}
 3 | (112,8398) | 1352 | f | t | f | (75,21) | {"(75,21)","(75,22)"}
 4 | (112,8398) | 1352 | f | t | f | (81,23) | {"(81,23)","(81,24)"}
 5 | (112,8398) | 1352 | f | t | f | (87,25) | {"(87,25)","(87,26)"}
 6 | (112,8398) | 1352 | f | t | f | (93,27) | {"(93,27)","(93,28)"}
 7 | (112,8344) | 1024 | f | t | f | (99,29) | {"(99,29)","(99,30)"}
(7 rows)

lzldb=> SELECT itemoffset, ctid, itemlen, nulls, vars, dead, htid, tids[0:2] AS some_tids FROM bt_page_items('idx_tab3_diff',4);
 itemoffset | ctid | itemlen | nulls | vars | dead | htid | some_tids 
------------+--------+---------+-------+------+------+--------+-----------
 1 | (5,1) | 112 | f | t | | | 
 2 | (3,23) | 112 | f | t | f | (3,23) | 
 3 | (3,24) | 112 | f | t | f | (3,24) | 
... 
 62 | (5,15) | 112 | f | t | f | (5,15) | 
 63 | (5,16) | 112 | f | t | f | (5,16) | 
(63 rows) 

bt_page_items函数里面的tids列其实就是posting list。上面的same字段插入的是同一个相同的数据，索引产生了deduplication；diff字段没有相同的数据，没有产生deduplication。他们各自所占用的空间差异是非常大的:

lzldb=> select relname,relpages,reltuples from pg_class where relname like 'idx_tab3%';
 relname | relpages | reltuples 
---------------+----------+-----------
idx_tab3_diff | 1484 | 90000
idx_tab3_same | 81 | 90000

唯一索引会产生deduplication吗？
#

唯一索引没有重复数据，看上去是不会，实际上是会的。因为即便是唯一索引，在HOT满足不了更新的时候，就会产生多个索引条目。这个测试我们从本文的第一个测试用例就可以看出来。update反复更新一条记录，也会产生deduplication，它产生在delete index item之前。另外，delete index item在删除posting list索引时，需要确保posting list下的所有ctids所对应的元组都是DEAD的。

关闭deduplication
#

index deduplication是pg13引入的。该功能默认开启，可以在索引级别关闭该功能。修改索引的deduplicate_items不会直接改动现有的索引结构，只会影响新插入的数据。

alter index idx_tab3_same set (deduplicate_items=off);
create index idx_tab3_same1 on tab3(same) with (deduplicate_items=off);

vacuum做了什么？
#

vacuum做的事情挺多的，这里只关注表、索引膨胀和空间回收，回卷等事情就不看了。

拿刚才反复更新一条数据的tab2表来测试，已经触发过simple deletion，表和索引条目几乎都是DEAD。直接执行vacuum

lzldb=# vacuum verbose tab2;
INFO: vacuuming "public.tab2"
INFO: scanned index "idx_tab2_a" to remove 10000 row versions
DETAIL: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
INFO: scanned index "idx_tab2_b" to remove 10000 row versions
DETAIL: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
INFO: "tab2": removed 10000 row versions in 173 pages
DETAIL: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
INFO: index "idx_tab2_a" now contains 1 row versions in 10 pages
DETAIL: 10000 index row versions were removed.
7 index pages have been deleted, 0 are currently reusable.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO: index "idx_tab2_b" now contains 1 row versions in 276 pages
DETAIL: 10000 index row versions were removed.
269 index pages have been deleted, 0 are currently reusable.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO: "tab2": found 24 removable, 1 nonremovable row versions in 173 out of 173 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 526
There were 0 unused item identifiers.
Skipped 0 pages due to buffer pins, 0 frozen pages.
0 pages are entirely empty.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUM

idx_tab2_a索引在10个page中remove了 10000个行版本，7个index pages被delete tab2表在173个page中remove了10000个行版本。

--表的第一页
lzldb=> select t_ctid,lp,case lp_flags when 0 then 'LP_UNUSED' when 1 then 'LP_NORMAL' when 2 then 'LP_REDIRECT' when 3 then 'LP_DEAD' end as lp_flags,t_xmin,t_xmax,t_field3 as t_cid, raw_flags, info.combined_flags from heap_page_items(get_raw_page('tab2',0)) item,LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2) info order by lp;
t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags 
--------+----+-----------+--------+--------+-------+-----------+----------------
 | 1 | LP_UNUSED | | | | | 
 | 2 | LP_UNUSED | | | | | 
...
 | 45 | LP_UNUSED | | | | | 

--表的最后一页
lzldb=> select t_ctid,lp,case lp_flags when 0 then 'LP_UNUSED' when 1 then 'LP_NORMAL' when 2 then 'LP_REDIRECT' when 3 then 'LP_DEAD' end as lp_flags,t_xmin,t_xmax,t_field3 as t_cid, raw_flags, info.combined_flags from heap_page_items(get_raw_page('tab2',172)) item,LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2) info order by lp;
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags 
----------+----+-----------+--------+--------+-------+-----------------------------------------------------------------------+----------------
 | 1 | LP_UNUSED | | | | | 
 | 2 | LP_UNUSED | | | | | 
...
 | 23 | LP_UNUSED | | | | | 
 | 24 | LP_UNUSED | | | | | 
(172,25) | 25 | LP_NORMAL | 509 | 0 | 9999 | {HEAP_HASVARWIDTH,HEAP_XMIN_COMMITTED,HEAP_XMAX_INVALID,HEAP_UPDATED} | {}

--索引的第一页
lzldb=> SELECT itemoffset, ctid, itemlen, nulls, vars, dead, htid, tids[0:2] AS some_tids FROM bt_page_items('idx_tab2_a',1);
NOTICE: page is deleted
itemoffset | ctid | itemlen | nulls | vars | dead | htid | some_tids 
------------+----------------+---------+-------+------+------+------+-----------
 1 | (4294967295,0) | 8 | f | f | | | 
(1 row)

--索引的最后一页
lzldb=> SELECT itemoffset, ctid, itemlen, nulls, vars, dead, htid, tids[0:2] AS some_tids FROM bt_page_items('idx_tab2_a',9);
itemoffset | ctid | itemlen | nulls | vars | dead | htid | some_tids 
------------+----------+---------+-------+------+------+----------+-----------
 1 | (172,25) | 16 | f | f | f | (172,25) | 

表的死元组所在的lp全部被标记为UNUSED，数据被清理，只剩下一条活元组在表中为NORMAL状态，表的pages还是那么多。索引的死元组（dead=t）的全部被清理，索引活元组在索引页内被移位了（最后一页的索引元组原本的itemoffset<>1），所有被清空的索引页被标记为deleted，这些deleted的索引页其实还在，为半死状态——half dead。 nbtree README中对Deleting entire pages during VACUUM的解释（原文比较长，摘了比较重要的出来）：

We consider deleting an entire page from the btree only when it’s become completely empty of items. Page deletion always begins from an empty leaf page. An internal page can only be deleted as part of deleting an entire subtree.

只有当索引页完全为空的时候才会考虑delete entire page。deleting总是从页节点开始，non-leaf节点只有在删除整个子树时才会被删除。

Deleting a leaf page is a two-stage process.
In the first stage, the page is unlinked from its parent, and marked as half-dead. In the second-stage, the half-dead leaf page is unlinked from its siblings. We first lock the left sibling (if any) of the target, the target page itself, and its right sibling (there must be one) in that order. Then we update the side-links in the siblings, and mark the target page deleted.

删除页节点有2个阶段：

从父节点unlink，此时的页节点为half-dead状态
从左右兄弟节点unlink，此时的叶节点为deleted状态

A deleted page cannot be recycled immediately, since there may be other processes waiting to reference it (ie, search processes that just left the parent, or scans moving right or left from one of the siblings). These processes must be able to observe a deleted page for some time after the deletion operation, in order to be able to at least recover from it (they recover by moving right, as with concurrent page splits). Searchers never have to worry about concurrent page recycling.

因为其他进程可能还在使用deleted page，vacuum不能立即回收这些索引页。

这段描述跟我们看到的现象是一致的虽然vacuum后，索引的pages还是那么多：

 relname | relpages | reltuples 
------------+----------+-----------
 idx_tab2_a | 10 | 1
 tab2 | 173 | 1

但是通过索引扫描已经不需要访问deleted page了：

lzldb=> explain (analyze,buffers) select * from tab2 where a=1; QUERY PLAN 
-------------------------------------------------------------------------------------------------------------------
 Index Scan using idx_tab2_a on tab2 (cost=0.12..8.14 rows=1 width=109) (actual time=0.011..0.012 rows=1 loops=1)
 Index Cond: (a = 1)
 Buffers: shared hit=2
 Planning Time: 0.056 ms
 Execution Time: 0.025 ms

vacuum之前shared hit=10，vacuum后索引page数没有变，还是有10个，其中有8个pages被deleted 但是没有直接recycle，所以shared hit=2。为什么是2也很容易理解，就是“meta page” + “只有一个存活的leaf page”。

Placing deleted pages in the FSM
#

Recycling a page is decoupled from page deletion. A deleted page can only be put in the FSM to be recycled once there is no possible scan or search that has a reference to it; until then, it must stay in place with its sibling links undisturbed, as a tombstone that allows concurrent searches to detect and then recover from concurrent deletions (which are rather like concurrent page splits to searchers)

什么是Placing deleted pages in the FSM？在索引页被deleted后，并没有被直接recycle，索引在分裂或新增页时，很难找到被deleted pages重复利用。Placing deleted pages in the FSM便是把这些可回收的页放在索引对应的FSM文件中，方便找到可直接利用的空闲页。我们前面提到，首次vacuum的时候，哪些deleted pages虽然被unlink了，但是它还是在那里占用着空间，在pg14以前

We implement the technique by waiting until all active snapshots and registered snapshots as of the page deletion are gone

删除的条件之一：所有活动快照和delete pages所涉及的快照必须都必须都结束。所以长事务肯定影响placing。

Placing an already-deleted page in the FSM to be recycled when needed doesn’t actually change the state of the page. The page will be changed whenever it is subsequently taken from the FSM for reuse. The deleted page’s contents will be overwritten by the split operation (it will become the new right sibling page).

此外，把 already-deleted page放到FSM文件中不会改变页的状态，这只是为了快速找到可用空闲页。

Prior to PostgreSQL 14, VACUUM would only place old deleted pages that it encounters during its linear scan (pages deleted by a previous VACUUM operation) in the FSM. Newly deleted pages were never placed in the FSM, because that was assumed to always be unsafe. PostgreSQL 14 added the ability for VACUUM to consider if it’s possible to recycle newly deleted pages at the end of the full index scan where the page deletion took place

在PG14以前，第一次vacuum产生的deleted pages不会被放到FSM，只有“旧”的deleted pages才会被放到FSM文件中。在PG14之后，第一次vacuum也会考虑将deleted pages放到FSM中。

测试（我的版本是pg13）：上面的tab2测试刚跑了一次vacuum，虽然已经产生了deleted pages，但是索引没有对应的FSM文件：

lzldb=> select * from pg_relation_filepath('idx_tab2_a');
 pg_relation_filepath 
----------------------
 base/16384/16437
 
[postgres@lzlhost data]$ ll base/16384/16437*
-rw------- 1 postgres postgres 81920 Apr 5 11:04 base/16384/16437

此时再跑一次vacuum：

lzldb=> vacuum tab2;

[postgres@lzlhost data]$ ll base/16384/16437*
-rw------- 1 postgres postgres 81920 Apr 5 11:04 base/16384/16437
-rw------- 1 postgres postgres 24576 Apr 5 15:52 base/16384/16437_fsm

索引立即产生了fsm文件。

流程图：索引膨胀和清理
#

请注意：

下图不包含表的fsm、vm信息
下图不包含deduplication信息
版本为pg13

fillfactor
#

以上讲了各种pg内核支持的方式以减少索引膨胀，出这些我们基本不需要参与的方式，还可以调整表和索引的fillfactor来控制膨胀问题。

fillfactor相当于表或索引的水位线，在INSERT数据时，插入到page的fillfactor线就到下一页去插入。fillfactor本身是为了给update留一定的空间，防止update频繁的去寻找新的page。

虽然表和索引都有fillfactor，他们的目的是一样的（为了update），但是具体细节有很大区别：

表：如果表的某个page上还有留有空间，那么update可以在这个page中进行，不需要申请新的page或者到其他有空闲空间的page上去。不仅如此，因为PG 独有的HOT特性，页内更新不会更新索引，当然也就会减缓索引膨胀
索引：不同的数据行或者相同数据行的页外更新，会新生成索引条目。fillfactor给索引页留下余量，会极大的减缓索引分离问题。

当然，fillfactor的设置跟业务模型是息息相关的，如果数据类似日志那样是递增且完全没有更新的，那么表和索引的fillfactor设置成100无可厚非。但是大部分业务表总是有更新的，表和索引fillfactor就不应该设置成100，如果是频繁的update，那么fillfactor应该设置得更低。然而，pg默认的fillfactor如下：

表默认 fillfactor=100
索引默认 fillfactor=90

表fillfactor=100完全用不了HOT！只要更新立即寻找新数据页，并在索引的10%里去新增一个索引元组。最后导致update频繁的业务总是在更新索引，此时90的索引也撑不住了，最终导致update频繁造成索引分裂···

以下是对fillfactor的测试，两张表仅fillfactor不一样，更新相同量的数据，看看最终share hit的差异：

create table tab4(a bigserial,b char(100));
create index idx_tab4_a on tab4(a);
alter index idx_tab4_a set (deduplicate_items=off); --关闭索引的deduplication
alter table tab4 alter column b set storage PLAIN; --关闭toast
alter table tab4 set (autovacuum_enabled = off); --关闭autovacuum

--tab5跟表tab4定义一样，除了表和索引的fillfactor更新
alter table tab5 set (fillfactor=70);
alter index idx_tab5_a set (fillfactor=80);

insert into tab4(b) values('lllllllllll'); 
--反复更新一条记录
DO $$
begin
	FOR i IN 1..10000 LOOP
		update tab4 set b=md5(i::text) where a=1;
	END LOOP; 
end $$;;

--默认fillfactor的主键查询
lzldb=> explain (analyze,buffers) select * from tab4 where a=1;
 QUERY PLAN 
----------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on tab4 (cost=4.28..53.88 rows=16 width=412) (actual time=0.894..0.895 rows=1 loops=1)
 Recheck Cond: (a = 1)
 Heap Blocks: exact=1
 Buffers: shared hit=174
 -> Bitmap Index Scan on idx_tab4_a (cost=0.00..4.28 rows=16 width=0) (actual time=0.023..0.023 rows=173 loops=1)
 Index Cond: (a = 1)
 Buffers: shared hit=1
 Planning Time: 0.057 ms
 Execution Time: 0.913 ms
(9 rows)

--fillfactor调低后的主键查询
lzldb=> explain (analyze,buffers) select * from tab5 where a=1;
 QUERY PLAN 
-----------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on tab5 (cost=4.39..56.41 rows=14 width=4012) (actual time=3.367..3.369 rows=1 loops=1)
 Recheck Cond: (a = 1)
 Heap Blocks: exact=1
 Buffers: shared hit=1434
 -> Bitmap Index Scan on idx_tab5_a (cost=0.00..4.39 rows=14 width=0) (actual time=0.195..0.195 rows=1429 loops=1)
 Index Cond: (a = 1)
 Buffers: shared hit=5
 Planning Time: 0.059 ms
 Execution Time: 3.390 ms

fillfactor调低后，shared hit的降低是非常明显的，Execution Time也有数倍提升。实际上数据页和索引页都有减少。所以，在总是update的业务表中，设置调低表和索引的fillfactor可以缓解表膨胀问题。

总结
#

虽然索引膨胀总是伴随着表膨胀，但是他们的原理不太一样。HOT不会更新索引元组，页外更新会新增索引元组。将表和索引的fillfactor参数调低，可以减缓update频繁的业务表的膨胀问题，当然最终也减缓了主键查询等SQL变慢问题。另外还有一些内核自带的增效索引空间的功能：

扫描索引时顺便清理死亡索引元组（index tuple deletion）
索引分裂时清理死亡索引元组（Bottom-Up index tuple deletion）
vacuum标记全是死索引元组的页（Deleting entire pages during VACUUM）
快速定位以在索引分离时更快的找到回收的索引页（Placing deleted pages in the FSM）

references
#

src/backend/access/nbtree/README https://mp.weixin.qq.com/s/GBN7dFQU72BfzvLSzlLmYA pg事务：事务相关元组结构 https://www.cybertec-postgresql.com/en/killed-index-tuples/ https://www.cybertec-postgresql.com/en/index-bloat-reduced-in-postgresql-v14/?spm=a2c6h.12873639.article-detail.8.2f153438mIV8JK https://www.cybertec-postgresql.com/en/b-tree-index-improvements-in-postgresql-v12/ https://www.cybertec-postgresql.com/en/b-tree-index-deduplication/

PostgreSQL源码解析 on 最后的DBA

控制文件上的参数和主从参数不一致问题

PARAMETER_CHANGE和控制文件上的数据库参数 #

wal_log_hint主从不一致 #

附加知识：what is XLOG_RUNNING_XACTS #

track_commit_timestamp主从不一致 #

pg14+ pause recovery #

小结8个参数 #

pg truncate浅析

命令选项 #

MVCC/transaction #

功能更新 #

pg truncate和其他库的功能差异 #

truncate做了什么 #

源码分析 #

reference #

PG在还没有pg_class的时候怎么访问基础系统表？

初始化数据字典 #

编译阶段：genbki.h & genbki.pl #

初始化database阶段：initdb&postgres.bki #

backend本地缓存数据字典 #

syscache/catcache初始化 #

relcache初始化 #

References #

vacuum啥时候截断末尾页？

vacuum truncate #

should_attempt_truncation函数源码分析 #

lazy_truncate_heap函数源码分析 #

vacuum truncate可能会等待5秒 #

vacuum truncate小结 #

从很慢的唯一索引扫描到索引膨胀

走主键的SQL是怎么访问了多个数据页的？ #

kill index item #

Bottom-Up deletion #

index deduplication #

唯一索引会产生deduplication吗？ #

关闭deduplication #

vacuum做了什么？ #

Placing deleted pages in the FSM #

流程图：索引膨胀和清理 #

fillfactor #

总结 #

references #

PARAMETER_CHANGE和控制文件上的数据库参数
#

wal_log_hint主从不一致
#

附加知识：what is XLOG_RUNNING_XACTS
#

track_commit_timestamp主从不一致
#

pg14+ pause recovery
#

小结8个参数
#

命令选项
#

MVCC/transaction
#

功能更新
#

pg truncate和其他库的功能差异
#

truncate做了什么
#

源码分析
#

reference
#

初始化数据字典
#

编译阶段：genbki.h & genbki.pl
#

初始化database阶段：initdb&postgres.bki
#

backend本地缓存数据字典
#

syscache/catcache初始化
#

relcache初始化
#

References
#

vacuum truncate
#

should_attempt_truncation函数源码分析
#

lazy_truncate_heap函数源码分析
#

vacuum truncate可能会等待5秒
#

vacuum truncate小结
#

走主键的SQL是怎么访问了多个数据页的？
#

kill index item
#

Bottom-Up deletion
#

index deduplication
#

唯一索引会产生deduplication吗？
#

关闭deduplication
#

vacuum做了什么？
#

Placing deleted pages in the FSM
#

流程图：索引膨胀和清理
#

fillfactor
#

总结
#

references
#