PostgreSQL内功修炼 on 最后的DBA

UUIDv4和v7两篇精彩文章-碰撞和性能

Fri, 29 May 2026 00:00:00 +0000

素材来源：HN UUID v4 碰撞帖、dev.to UUID Benchmark

AI率99%

太长不看
#

UUID v4 碰撞了——HackerNews 上有人真的撞了。原因是软件栈的 bug，不是数学。v4 和 v7 在碰撞安全性上没本质区别，差异在索引性能：v7 有时序，B-tree 更紧凑，写入快 35%、索引小 22%。你的 UUID v4 大概率没事，但如果你追求索引性能，换 v7 有实惠。

UUID v4 碰撞事故
#

HackerNews 上有个帖子火了——Ask HN: We just had an actual UUID v4 collision…，479 赞 347 评论。

发帖人的原话：

I know what you’re thinking… and I still can’t believe it, but… This morning, our database flagged a duplicate UUID (v4).

不是 double-insert 的 bug，不是代码写了两遍。库里只有 ~15,000 条记录，用 npm 的 uuid 包生成 uuidv4()，两个不同时间创建的行撞了同一个 UUID：

b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd

UUID v4 碰撞的概率是多少？122 位随机位，2^122 ≈ 5.3×10^36 种可能，15,000 条记录下碰撞概率约 2×10^-29。理论上"不可能"。

但它发生了。

原因一：熵源不可靠
#

HN 最高赞评论（jandrewrogers）：

UUIDv4 的安全性依赖高质量熵源。硬件缺陷、软件 bug、对"高质量熵"的误解，都会让这个假设失效。检测熵源故障很贵，所以没人检查——直到撞了。

UUID v4 在高可靠系统中被明确禁止，原因是无法验证熵源质量。

原因二：npm uuid 包有已知 bug
#

uuid npm 包的 README 自己都在警告：

This module may generate duplicate UUIDs when run in clients with deterministic random number generators, such as Googlebot crawlers.

更严重的是，它的 rng() 函数内部有全局可变状态。一个评论者指出：调用 rng() 然后把结果发出去，等于覆盖了别人的随机数而且你能猜到它。

原因三：Linux 内核 /dev/random 竞态
#

另一个评论：

我在分布式系统的浸泡测试里碰到了 dup UUID。排查很久发现是 Linux 内核的一个竞态 bug——多处理器系统上，两个进程同时读 /dev/random，极低概率（~百万分之一）拿到相同的字节。

原因四：Go 的 UUID 库不检查返回值
#

早期 Go UUID 库调用随机数函数时，不检查返回值长度。“请求 N 字节，返回了 3 字节"的情况在大部分硬件上不出现，所以没人检查，直到上生产环境撞了成千上万个重复 UUID。

原因五：AMD CPU RNG 的历史缺陷
#

AMD 某些 CPU 的内置随机数生成器曾经有问题。VM 环境还会"虚拟化掉"熵——虚拟机的时间源和熵源都可能退化。

v4 和 v7 在碰撞安全性上没有本质区别，差异在前 48 位——v4 是随机数，v7 是时间戳。时序源出问题的情况你基本碰不到，随机源出问题的概率同样极低。HN 那个帖子是个有趣的特例，知道极少数人遇到了就行，不需要因此怀疑自己系统里的 UUID v4。

选 v4 还是 v7，真正该看的不是碰撞，是索引性能。

UUID v7 在 PG 16 中的性能对比
#

UUID v7 比 v4 在 PostgreSQL 里有一个实打实的优势：时序聚簇，B-tree 更友好。v4 膨胀 v7 也能膨胀，区别只是 v7 的前 48 位有时序，insert 集中在 B-tree 右侧，页分裂少。

Umang Sinha 的 benchmark 在 PG 16 Docker 容器（8 核 16GB NVMe）上做了严格的对比测试。

测试条件
#

CREATE TABLE uuid_v4_test (id UUID PRIMARY KEY, payload TEXT);
CREATE TABLE uuid_v7_test (id UUID PRIMARY KEY, payload TEXT);

参数	值
数据量	1000 万行/表
批次	每批 1 万行
客户端	Go + pq 驱动
UUID 预生成	在内存中生成好，不计时

性能结果
#

指标	UUID v4	UUID v7	提升
写入 1000 万行	5 分 35 秒	3 分 38 秒	35% 更快
表+索引总大小	3618 MB	3443 MB	5% 更小
B-tree 索引大小	776 MB	602 MB	22% 更小
单点查询	0.167 ms	0.038 ms	4.4 倍
范围扫描	8.283 ms	3.791 ms	2.2 倍

为什么差这么多
#

UUID v4 是完全随机的。新插入的 UUID 在 B-tree 索引里随机分布，导致大量页分裂（page split），索引碎片化严重。UUID v7 前 48 位是毫秒级时间戳，新生成的 UUID 天然有序——写入集中在 B-tree 的右侧，页分裂大幅减少，索引更紧凑。

索引小 22% 不是魔法，是减少了碎片。单点查询快 4 倍也不奇怪——B-tree 层级更少、缓存命中率更高。

总结
#

UUID v4 和 v7 在碰撞安全性上是一样的——都依赖熵源质量，一个用随机数填充前 48 位，一个用时间戳。碰撞是极少数人在特定环境下踩到的坑，你的环境大概率没事，这个基本判断不用变。

真正该琢磨的是索引性能。v7 的时序特性让 B-tree 更紧凑，实测写入快 35%、索引小 22%、查询快 2-4 倍。如果系统对 UUID 的写入量很大，换 v7 能省不少存储和 CPU。

PG 18 会原生支持 gen_uuid_v7()，目前可以应用层生成。不管用哪个版本，加 UNIQUE 约束总是对的。

从collation mismatch异常到其原理

Sat, 13 Dec 2025 00:00:00 +0000

问题现象
#

物理迁移信创后pg log偶有报错，版本是pg15：

WARNING: 01000: collation "zh_CN.utf8" has version mismatch
DETAIL: The collation in the database was created using version 2.17, but the operating system provides version 2.28.
HINT: Rebuild all objects affected by this collation and run ALTER COLLATION pg_catalog."zh_CN.utf8" REFRESH VERSION, or build RaseSQL with the right library version.
LOCATION: pg_newlocale_from_collation, pg_locale.c:1660

前景：物理切换的时候做了失效索引重建和refresh database collation version。

虽然物理迁移后libc版本升了，但是做了索引重建的，索引现在是有效的，而且db中的collation version已经与OS libc一致。

所以，

为什么会报错？

报错哪里触发的？

报错有什么影响？

怎么解决？

问题分析
#

为什么会报错？
#

数据库内部的collation主要看3块：db、列、索引。前两个都是默认collation，索引的collation才是真collation。

先检查database的collation，db的都是en_US.UTF8，且已经refresh database collation过了，所以“collation “zh_CN.utf8” has version mismatch”这个报错不应该在db层抛出。

然后再查看字段没有特殊指定的默认collation：

select attrelid,attname,attcollation from pg_attribute where attcollation not in (0,100,950,951);
 attrelid | attname | attcollation 
----------+---------+--------------
(0 rows)

0表示没有collation，default oid=100,C oid=950,POSIX oid=951；“zh_CN.utf8"肯定不会是这四个。

最后再查看索引没有特殊指定的collation

select * from (select indexrelid ,unnest(indcollation) coll from pg_index) i where coll not in (0,100,950,951);
 indexrelid | coll 
------------+------
(0 rows)

排除db、字段、索引，那么只能是一种情况：业务层指定排序规则

select col1 from (values ('a'), ('A'), ('啊'), ('阿')) AS l(col1) order by col1 collate "zh_CN.utf8";
WARNING: 01000: collation "zh_CN.utf8" has version mismatch
DETAIL: The collation in the database was created using version 2.17, but the operating system provides version 2.28.
HINT: Rebuild all objects affected by this collation and run ALTER COLLATION pg_catalog."zh_CN.utf8" REFRESH VERSION, or build RaseSQL with the right library version.
LOCATION: pg_newlocale_from_collation, pg_locale.c:1660
 col1 
------
 阿
 啊
 a
 A

这个zh_CN.utf8的version就跟实际的不一致：

 select collname,collversion,pg_collation_actual_version(oid) from pg_collation where collname ='zh_CN.utf8';
 collname | collversion | pg_collation_actual_version 
------------+-------------+-----------------------------
 zh_CN.utf8 | 2.17 | 2.28

不仅zh_CN.utf8不一样，所有都不一样（除了几个没有version说法的coll）

所以很有可能是业务自己指定了一个排序规则"zh_CN.utf8”，但是库中的coll version与OS不一致，才抛出了报错。

源码理解
#

通过报错信息是很好定位到源码位置的，主要关注2个函数：pg_newlocale_from_collation和CheckMyDatabase。

`pg_newlocale_from_collation`缓存和检查`pg_collation`
#

pg_newlocale_from_collation是pg10才有

/*
 * Create a locale_t from a collation OID. Results are cached for the
 * lifetime of the backend. Thus, do not free the result with freelocale().
 *
 * As a special optimization, the default/database collation returns 0.
 * Callers should then revert to the non-locale_t-enabled code path.
 * In fact, they shouldn't call this function at all when they are dealing
 * with the default locale. That can save quite a bit in hotspots.
 * Also, callers should avoid calling this before going down a C/POSIX
 * fastpath, because such a fastpath should work even on platforms without
 * locale_t support in the C library.
 *
 * For simplicity, we always generate COLLATE + CTYPE even though we
 * might only need one of them. Since this is called only once per session,
 * it shouldn't cost much.
 */
/* locale_t指非ICU。该函数是为backend cache一个locale_t类型的collation OID
* the default/database collation returns 0。其中default表示使用db的collation
*/
pg_locale_t
pg_newlocale_from_collation(Oid collid) //注意传入的是collation的oid，不是拿所有pg_collation
{
...
	/* Return 0 for "default" collation, just in case caller forgets */
	if (collid == DEFAULT_COLLATION_OID) //有三个特殊的coll：
		return (pg_locale_t) 0; //default oid=100,C oid=950,POSIX oid=951

...
	if (cache_entry->locale == 0)
	{
...
		collversion = SysCacheGetAttr(COLLOID, tp, Anum_pg_collation_collversion,
									 &isnull); //从pg_collation中拿数据字典中的version
		if (!isnull)
		{
...
			actual_versionstr = get_collation_actual_version(collform->collprovider, collcollate); //通过get_collation_actual_version获得实际的version
...
			collversionstr = TextDatumGetCString(collversion);

			if (strcmp(actual_versionstr, collversionstr) != 0) //对比数据字典中的version和实际的version，不同就抛出报错
				ereport(WARNING,
						(errmsg("collation \"%s\" has version mismatch",
								NameStr(collform->collname)),
						 errdetail("The collation in the database was created using version %s, "
								 "but the operating system provides version %s.",
								 collversionstr, actual_versionstr),
						 errhint("Rebuild all objects affected by this collation and run "
								 "ALTER COLLATION %s REFRESH VERSION, "
								 "or build PostgreSQL with the right library version.",
								 quote_qualified_identifier(get_namespace_name(collform->collnamespace),
															NameStr(collform->collname)))));
		}
...
	return cache_entry->locale;
}

主要是通过coll oid检查这个coll在pg_collation数据字典的version和实际的version是否一致，如果不一致就抛出报错。

`CheckMyDatabase`缓存和检查`pg_database`
#

CheckMyDatabase已经存在很久了，它要做很多db方面的检查。不过在pg15增加了检查db version的逻辑

/*
 * CheckMyDatabase -- fetch information from the pg_database entry for our DB
 */
static void
CheckMyDatabase(const char *name, bool am_superuser, bool override_allow_connections)
{
...
	/* Fetch our pg_database row normally, via syscache */
	tup = SearchSysCache1(DATABASEOID, ObjectIdGetDatum(MyDatabaseId));
...
	default_locale.provider = dbform->datlocprovider; //default就是db的

	/*
	 * Default locale is currently always deterministic. Nondeterministic
	 * locales currently don't support pattern matching, which would break a
	 * lot of things if applied globally.
	 */
	default_locale.deterministic = true; //字节序敏感的

	/*
	 * Check collation version. See similar code in
	 * pg_newlocale_from_collation(). Note that here we warn instead of error
	 * in any case, so that we don't prevent connecting.
	 */
	datum = SysCacheGetAttr(DATABASEOID, tup, Anum_pg_database_datcollversion,
							&isnull); //从pg_database中拿datcollversion
	if (!isnull)
	{
		char	 *actual_versionstr;
		char	 *collversionstr;

		collversionstr = TextDatumGetCString(datum);

		actual_versionstr = get_collation_actual_version(dbform->datlocprovider, dbform->datlocprovider == COLLPROVIDER_ICU ? iculocale : collate); //通过get_collation_actual_version获得实际的version
...
		else if (strcmp(actual_versionstr, collversionstr) != 0) //对比db datcollversion和实际的version，不相等则抛出warning
			ereport(WARNING,
					(errmsg("database \"%s\" has a collation version mismatch",
							name),
					 errdetail("The database was created using collation version %s, "
							 "but the operating system provides version %s.",
							 collversionstr, actual_versionstr),
					 errhint("Rebuild all objects in this database that use the default collation and run "
							 "ALTER DATABASE %s REFRESH COLLATION VERSION, "
							 "or build PostgreSQL with the right library version.",
							 quote_identifier(name))));
	}
...
}

CheckMyDatabase函数会对比数据字典pg_database中的datcollversion和实际的version。

函数差异
#

在pg14及之前，对比collation的逻辑只有1个:会话首次缓存对应collation时，调用pg_newlocale_from_collation访问pg_collation数据字典中的对应的那个collation的version，对比真实的version
在PG15及以后，因为在pg_database表中新增了datcollversion字段，所以新增了一个检查db collation version的逻辑：会话首次访问pg_database中的db时，调用CheckMyDatabase检查pg_database中对应的那个db的datcollversion，对比真实的version

为什么仅refresh database后报错不多
#

refresh database collation version后，不会触发pg_database的coll version不一致的warning，但是也不能排除pg_collation的coll version不一致的情况。为什么仅refresh database后，报错就少量这么多，难道pg_collation的coll version就不会被加载了?

select c.coll,count(*) from (select unnest(indcollation) coll from pg_index ) c group by c.coll;
 coll | count 
------+-------
 950 | 37 --C
 0 | 2841 --不存在collation
 100 | 723 --default

真实环境中，用的最多的还是default，一般也没人去指定collation，没有指定就是default，default就是db的默认collation。

这里要回来再次关注pg_newlocale_from_collation函数。函数刚开头是这样的：

pg_locale_t
pg_newlocale_from_collation(Oid collid)
{
	collation_cache_entry *cache_entry;

	/* Callers must pass a valid OID */
	Assert(OidIsValid(collid));

	/* Return 0 for "default" collation, just in case caller forgets */
	if (collid == DEFAULT_COLLATION_OID)
		return (pg_locale_t) 0;
...

当collid==DEFAULT_COLLATION_OID==100时，直接return，不再执行下面的真实version的判断，也就不会抛出warning。这个逻辑是合理的，因为db coll version已经在登入db时校验过了，如果有问题，那么肯定已经在session层抛出过一次warning了。

另外，即便是传入可能的值collid=37，对应的C也没有version的说法。

所以，refresh database后，绝大部分场景下，只要是用数据库内部的排序（非表达式排序和指定索引排序），就不会抛出报错了。

测试
#

这里仅测试是否有refresh warning，不测试索引corrupt或者库跑崩。

#查看libc版本
getconf GNU_LIBC_VERSION

源主机版本 glibc 2.17
目标主机 glibc 2.28
pg版本 pg15+

测试：刷db不刷新pg_collation，仅db coll version改变
#

select datname,datlocprovider,datcollate,datctype,datcollversion from pg_database 
 datname | datlocprovider | datcollate | datctype | datcollversion 
------------+----------------+-------------+-------------+----------------
 lzldb | c | en_US.UTF-8 | en_US.UTF-8 | 2.17
 
select collname,collprovider,collversion,pg_collation_actual_version(oid) from pg_collation where collname ~ 'en_US.utf8';
 collname | collprovider | collversion | pg_collation_actual_version 
------------+--------------+-------------+-----------------------------
 en_US.utf8 | c | 2.17 | 2.28

alter database lzldb refresh collation version;
NOTICE: 00000: changing version from 2.17 to 2.28
LOCATION: AlterDatabaseRefreshColl, dbcommands.c:2399
ALTER DATABASE

再次查看pg_collation和pg_database

 collname | collprovider | collversion | pg_collation_actual_version 
------------+--------------+-------------+-----------------------------
 en_US.utf8 | c | 2.17 | 2.28

 datname | datlocprovider | datcollate | datctype | datcollversion 
------------+----------------+-------------+-------------+----------------
 lzldb | c | en_US.UTF-8 | en_US.UTF-8 | 2.28

跟官方文档的描述一致，refresh database collation version只是在刷db的默认collation，pg_collation本身是不会变的

测试：刷db不刷新pg_collation，指定表达式排序报warning
#

如开头分析，表达式排序会报warning，略

测试：刷db不刷新pg_collation，新建指定collation的索引报warning
#

测试1：建索引时指定collation

 collname | collversion | pg_collation_actual_version 
------------+-------------+-----------------------------
 zh_CN.utf8 | 2.17 | 2.28
 
 > create index idx11 on tt(a collate "zh_CN.utf8");
WARNING: 01000: collation "zh_CN.utf8" has version mismatch
DETAIL: The collation in the database was created using version 2.17, but the operating system provides version 2.28.
HINT: Rebuild all objects affected by this collation and run ALTER COLLATION pg_catalog."zh_CN.utf8" REFRESH VERSION, or build PostgreSQL with the right library version.
LOCATION: pg_newlocale_from_collation, pg_locale.c:1664
CREATE INDEX

测试2：建表时指定字段默认collation，建索引时不指定

\c lzldb --重连一个session
You are now connected to database "lzldb" as user "postgres".
create table ttt(a varchar(10) collate "zh_CN.utf8");
CREATE TABLE

> create index idxttt on ttt(a);
WARNING: 01000: collation "zh_CN.utf8" has version mismatch
DETAIL: The collation in the database was created using version 2.17, but the operating system provides version 2.28.
HINT: Rebuild all objects affected by this collation and run ALTER COLLATION pg_catalog."zh_CN.utf8" REFRESH VERSION, or build PostgreSQL with the right library version.
LOCATION: pg_newlocale_from_collation, pg_locale.c:1664
CREATE INDEX
Time: 7.904 ms

字段默认collation和建索引指定collation本质是一个东西，都是为了指定索引的collation。他们都可以报warning。

测试：刷db不刷新pg_collation，已建指定collation的索引不报warning
#

场景为原库已经有索引指定collation zh_CN.utf8，跟db的不一样，refresh db刷不到。但是到新库后vendor的coll version肯定是变了。

select collname,collprovider,collversion,pg_collation_actual_version(oid) from pg_collation where collname ~ 'zh_CN.utf8';
 collname | collprovider | collversion | pg_collation_actual_version 
------------+--------------+-------------+-----------------------------
 zh_CN.utf8 | c | 2.17 | 2.28

不用表达式排序的话，可以用到索引，但是不能使用索引排序

> set enable_seqscan =off;
SET
> EXPLAIN ANALYZE SELECT a FROM tt ORDER BY a LIMIT 1000;
 QUERY PLAN 
----------------------------------------------------------------------------------------------------------------------------------------
 Limit (cost=6667.80..6670.30 rows=1000 width=33) (actual time=44.928..45.145 rows=1000 loops=1)
 -> Sort (cost=6667.80..6892.81 rows=90004 width=33) (actual time=44.926..45.021 rows=1000 loops=1)
 Sort Key: a
 Sort Method: top-N heapsort Memory: 127kB
 -> Index Only Scan using idxtt on tt (cost=0.42..1732.98 rows=90004 width=33) (actual time=0.029..15.434 rows=90004 loops=1)
 Heap Fetches: 4

已建指定collation的索引，使用到的时候不报warning

这个问题的总结
#

refresh database和refresh collation的warning是session级。在每个会话中，对于每个db或每个collation只报一次。

仅refresh database，很有可能不会再报warning，但是存在创建指定collation索引、运行指定表达式collation SQL时报warning的情况。

数据字典中的coll version只是为了在db层追踪collation provider version是否发生改变。试想一下没有数据字典中的coll version，那么db可能都无法返回warning告知“你的排序规则提供商升级了版本，你的数据排序可能有问题，你需要检查一下了”（当然不止是排序）。

这个问题的解决方案
#

corrupt的索引已经重建过，db也refresh过，只是没有refresh collation。数据字典中的coll version不一致，问题不算太大，只是提示而已，至于还有其他什么隐秘又奇怪的坑，参考more章节。

这个问题的解决方案：

第一步：检查是否还有依赖

SELECT pg_describe_object(refclassid, refobjid, refobjsubid) AS "Collation",
 pg_describe_object(classid, objid, objsubid) AS "Object"
 FROM pg_depend d JOIN pg_collation c
 ON refclassid = 'pg_collation'::regclass AND refobjid = c.oid
 WHERE c.collversion <> pg_collation_actual_version(c.oid)
 ORDER BY 1, 2;

如果有返回，最好重建依赖的对象；没有的话遵循第二步：

方案一：不动。warning不多也可以不动
方案二：仅refresh collation zh_CN.UTF8。来一个解决一个
方案三：所有collation都refresh一遍。哪怕业务有增量使用表达式或索引指定collation，也不会报warning

more
#

glibc升级相关的精华总结
#

locale是一个非常坑的领域，glibc升级导致的collation的问题也非常多，参考ref资料，汇总一些比较重要的东西：

pg_collation是从OS命令locale -a取的；provider基本都是glibc，所以要看glibc的version。

在pg_collation中"C"和"posix"的collprovider都是c，看着跟“C.UTF8”等一样，其实不是的。“C.UTF8”的provider是glibc，有version，一般是unicode码点排序或unicode语义排序；“C"和“POSIX”是等价的，是POSIX 标准定义的最基础的locale，由libc实现，不在locale -a中，没有version，直接以字节序排序。

collation问题的根源：数据库要的是数据库生命周期内locale定义永远不变，但是OS提供商特别是GNU C library每个小版本都会对locale做出改动，而且这是合法的。

GNU C library每个小版本都会对locale做出改动，现实中最容易出问题的版本是glibc 2.28，因为2.28升级了大版本unicode 9.0.0(has been updated to a new upstream version from ISO which is in sync with Unicode 9.0.0)。

pg没有办法检测glibc升级带来的兼容性问题。索引损坏检查不是all check，同时索引也只是一方面。物理复制或upgrade后，即使重建索引，也不能排除因为collation version的问题，某天库跑崩了的情况。

数据异常包括：主键重复，依赖排序的约束，范围分区表数据写入错误分区，mergejoin等排序操作等等

字符类型依赖collation，不依赖collation的数据类型：

bytea
tsvector gin indexes
pg_trgm indexes
numeric data types: int, bigint, numeric, float, …
custom data types like geometry (PostGIS)
timestamp

ASCII排序比较常见但不符合人类理解，即不符合语义。符合语义的国际排序标准一般都是unicode标准。

基于unicode的排序规则也分了好2种：码点排序、UCA（Unicode Collation Algorithm）

UCA基于DUCET（Default Unicode Collation Element Table），DUCET表本身在不同版本间可能发生排序变化。举个栗子，en_US.UTF8是UCA排序，相当于语义排序，版本升级会改变排序规则。C.UTF8是码点排序，码点确认后不会改变，不会改变排序规则。

PG 17+提供了非常安全的locale提供方式：builtin，不再依赖OS提供的glibc、ICU等provider。启用命令例如

initdb --locale-provider=builtin --bultin-locale=C.UTF-8 dbname1

17仅支持C, C.UTF-8，C是字节序排序（约等于ASCII排序），C.UTF-8是unicode码点排序；18多一个PG_UNICODE_FAST ，也是unicode码点排序，跟C.UTF-8稍有区别。

因为数据库必须保持排序稳定不变，业务自定义排序只有推给业务层实现，例如表达式排序就是语义明确的，而且不影响数据库本身对collation的选择。如果哪天pg也支持build-in en_US.utf8的话，再考虑build-in的语义排序。

信创迁移时，信创主机的glibc版本一般都比老的英特尔服务器glibc版本高，很可能跨了2.28这个版本。加上任务急、kpi推动、人力不足和大库，物理迁移是在所难免。所以信创物理迁移得关注glibc版本和collation导致的许多异常。

物理迁移后可以做什么
#

假设数据库是en_US.utf8，provider c，已经做了跨libc版本的物理迁移，应该做如下操作:

一、官方必修方案

1.至少要重建有问题的索引。安装amcheck插件，用bt_index_check函数

SELECT bt_index_check('idx1'::regclass, true);

2.refresh database version，(pg15+)

ALTER DATABASE name REFRESH COLLATION VERSION

3.检查有没有其他依赖的对象，有的话得看情况处理了

SELECT pg_describe_object(refclassid, refobjid, refobjsubid) AS "Collation",
 pg_describe_object(classid, objid, objsubid) AS "Object"
 FROM pg_depend d JOIN pg_collation c
 ON refclassid = 'pg_collation'::regclass AND refobjid = c.oid
 WHERE c.collversion <> pg_collation_actual_version(c.oid)
 ORDER BY 1, 2;

处理完以后，再

4.refresh collation version，(pg10+)

ALTER COLLATION name REFRESH VERSION

二、非官方邪修方案

我这没有做出完整的方案，只是一点思路。

1.处理分区表写入错误分区的问题

分区键是int/bigint/float，跟collation没有关系，可以不用管了

分区键是时间分区，如果是timestamp不用管了，如果是varchar等等字符类型，就看情况了

分区键是字符类型，参考“a”和“-”的排序（pgconf Collation Challenges Sorting It Out）。但要注意以下几点

如果要查数据的话，不要从父表查，可能会崩或者查不出来
没有简单的检测方案

2.处理主键/唯一键冲突

3.处理fdw排序范围异常的问题

4.未知问题

ref
#

https://wiki.postgresql.org/wiki/Locale_data_changes

https://wiki.postgresql.org/wiki/Collations

pgconf Collation Challenges Sorting It Out

PFCONF Collations from A to Z

http://www.unicode.org/reports/tr10/tr10-34.html

https://sourceware.org/glibc/wiki/Release/2.28

https://www.postgresql.org/docs/18/sql-altercollation.html

https://www.postgresql.org/docs/18/sql-alterdatabase.html

https://www.postgresql.org/docs/17/locale.html#LOCALE-PROVIDERS

简评ORACLE,MYSQL,PG的逻辑复制

Sun, 30 Nov 2025 00:00:00 +0000

postgresql逻辑复制
#

（https://www.pgconf.asia/JA/2017/wp-content/uploads/sites/2/2017/12/D2-A7-EN.pdf）

PostgreSQL把所有逻辑解析相关的事情全部放在数据库中的复制槽进行管理，大包大揽。早期版本的逻辑复制支持的还不太好，近期的几个大版本中，逻辑复制是主要的功能提升之一。 PG方案的优势：

非常灵活，把逻辑解码接口提供给用户，有多种类的解析方式
用户可根据需求订阅所需要的数据

PG方案的劣势：

知识点多学习成本相对MYSQL要高很多。仅仅是基础知识点：发布、订阅、walsender、复制槽、output plugin等等，我相信很多人没有弄明白他们概念和关系
干最累的活挨最毒的打。逻辑解析的问题全部暴露在数据库中，wal积压、大事物、长事务、reorder事务排序、权限问题、流式传输等等都是PG要考虑的问题

mysql的binlog
#

(https://blog.fasterinfo.top/6243.html)

mysql把所有解析出来的逻辑数据放在本地——binlog文件中，方案简单。mysql的binlog约等于PostgreSQL开启全表逻辑复制并写入本地。 MYSQL方案的优势：

简单粗暴，mysql不把逻辑解码接口直接暴露给用户，而是把已解析出来的文件直接给到用户，用户不需要关心怎么解析的，直接读binlog文件即可
生态成熟。个人认为mysql生态成熟跟binlog有较大关系，在互联网时代PG的逻辑复制还很弱，而binlog十分简单，下游解析binlog把数据放到其他平台已成为一种常见方案

MYSQL方案的劣势：

数据必须全部解析，不可定制化订阅数据，灵活性差
两阶段提交。由于mysql主从强依赖binlog，又导致binlog数据在提交的时候必须全部落盘到binlog file，一次提交必须写两份（或者两种）日志——binlog和redolog，日志双写是mysql永恒的痛点之一。

oracle的逻辑复制
#

（https://www.oracle-scn.com/oracle-goldengate-integrated-capture/）

oracle本身是有逻辑DG的功能的，但基本上没见有人用过，这里只聊logminer 。oracle数据库本身提供了logminer这样的接口来解析日志（如OGG集成模式），逻辑复制链路管理本身完全没有，依赖第三方工具来创建和管理复制链路 ORACLE方案的优势：

只提供解析接口，没有复制链路管理，对于数据库本身来说非常省心
充值就有方案。把强大的OGG直接买下来，不要说我ORACLE没有提供逻辑复制解决方案，我们不仅有，而且很强大、认可度高。

ORACLE方案的劣势：

依赖第三方软件管理复制链路

总之，PG的逻辑复制是大包大揽什么都做，非常有开源精神、技术精神。MYSQL的方案简单粗暴但好用，有点“一步到位”的意思。ORACLE属于给个接口后就什么都不管，全部给第三方管理，但对于客户来说是有成熟的解决方案的。

查询冲突：从静态表查询冲突到其原理

Sat, 13 Sep 2025 00:00:00 +0000

问题现象
#

现象
#

一个静态历史表，没有任何更新，在同城从库跑SQL稳定触发查询冲突：

ERROR: 40001: canceling statement due to conflict with recovery
DETAIL: User query might have needed to see row versions that must be removed.
LOCATION: ProcessInterrupts, postgres.c:3197
Time: 30534.973 ms (00:30.535)

为什么一个静态表查询冲突是一个值得关注的问题
#

我的理解中静态表是不应该发生冲突的（这个理解错了，后面会解释）。

官方文档 Conflict cases include:

Access Exclusive locks taken on the primary server, including both explicit LOCK commands and various DDL actions, conflict with table accesses in standby queries.
Dropping a tablespace on the primary conflicts with standby queries using that tablespace for temporary work files.
Dropping a database on the primary conflicts with sessions connected to that database on the standby.
Application of a vacuum cleanup record from WAL conflicts with standby transactions whose snapshots can still “see” any of the rows to be removed.
Application of a vacuum cleanup record from WAL conflicts with queries accessing the target page on the standby, whether or not the data to be removed is visible.

LOCK,DDL,drop tablespace ,drop database肯定没有。

vacuum，这也没有，这可以从pg_stat_all_tables.last_autovacuum和wal vacuum record可以看出来

官方文档的解释就到此为止了，我自己仔细排查了一下确认没有以上情况。

利用现有知识可能还有其他场景干掉从库查询的所持有快照的xmin。例如页内修剪会干掉page中行上的xmin，如果下游的查询的快照还依赖这些xmin，这理论上也会发生查询冲突。但是，page是属于一个表的，只查一个表只能持有这个表上的快照以及表上的xmin，所以，理论上A表的页内修剪，应该不会发生B表上的查询冲突（这个理解错了，后面会解释）。

pg官方文档对查询冲突场景的解释比较糊，没有很好的解释静态表发生冲突的场景和原因。加上自己联想的场景，也不应该有查询冲突。但我发现这个场景似乎在很多库上都有，所以得看下咋回事。

原因分析
#

因为是startup把查询掐掉的，所以看startup进程的pstack即可找到查询冲突函数

$ pstack 212012
#0 0x00002b283f63d783 in __select_nocancel () from /lib64/libc.so.6
#1 0x00000000008fcf5a in pg_usleep (microsec=<optimized out>) at pgsleep.c:56
#2 0x0000000000787905 in WaitExceedsMaxStandbyDelay (wait_event_info=134217762) at standby.c:208
#3 ResolveRecoveryConflictWithVirtualXIDs (waitlist=0x2398a50, reason=reason@entry=PROCSIG_RECOVERY_CONFLICT_SNAPSHOT, wait_event_info=wait_event_info@entry=134217762, report_waiting=report_waiting@entry=true) at standby.c:276
#4 0x0000000000787b33 in ResolveRecoveryConflictWithVirtualXIDs (report_waiting=true, wait_event_info=134217762, reason=PROCSIG_RECOVERY_CONFLICT_SNAPSHOT, waitlist=<optimized out>) at standby.c:333
#5 ResolveRecoveryConflictWithSnapshot (latestRemovedXid=<optimized out>, node=...) at standby.c:329
#6 0x00000000004c8ffe in heap_xlog_clean (record=0x2366978) at heapam.c:7764
#7 heap2_redo (record=0x2366978) at heapam.c:8917
#8 0x0000000000519e55 in StartupXLOG () at xlog.c:7411
#9 0x000000000072f211 in StartupProcessMain () at startup.c:204
#10 0x00000000005286b1 in AuxiliaryProcessMain (argc=argc@entry=2, argv=argv@entry=0x7ffeb7e39d70) at bootstrap.c:450
#11 0x000000000072c369 in StartChildProcess (type=StartupProcess) at postmaster.c:5494
#12 0x000000000072eb54 in PostmasterMain (argc=argc@entry=3, argv=argv@entry=0x232edb0) at postmaster.c:1407
#13 0x00000000004892cf in main (argc=3, argv=0x232edb0) at main.c:210

XLOG_HEAP2_CLEAN
#

void
heap2_redo(XLogReaderState *record)
{
	uint8		info = XLogRecGetInfo(record) & ~XLR_INFO_MASK;

	switch (info & XLOG_HEAP_OPMASK)
	{
		case XLOG_HEAP2_CLEAN:
			heap_xlog_clean(record);
			break;

当redo是XLOG_HEAP2_CLEAN时，才会进入这个下一个函数heap_xlog_clean

pg 18已经没有XLOG_HEAP2_CLEAN这个东西了（15左右其实就没有了，这篇文章就只看13和18两个版本），但是可以在heapam_xlog.h中找到define

//pg13
#define XLOG_HEAP2_CLEAN		0x10
#define XLOG_HEAP2_FREEZE_PAGE	0x20
#define XLOG_HEAP2_CLEANUP_INFO 0x30

//pg18
 * There's no difference between XLOG_HEAP2_PRUNE_ON_ACCESS,
 * XLOG_HEAP2_PRUNE_VACUUM_SCAN and XLOG_HEAP2_PRUNE_VACUUM_CLEANUP records.
 * They have separate opcodes just for debugging and analysis purposes, to
 * indicate why the WAL record was emitted.
 */
#define XLOG_HEAP2_PRUNE_ON_ACCESS		0x10
#define XLOG_HEAP2_PRUNE_VACUUM_SCAN	0x20
#define XLOG_HEAP2_PRUNE_VACUUM_CLEANUP	0x30

把pg18的源码掏出来，主要是因为pg13（当前生产库的版本）对这几个xl_info 的CLEAN宏定义一点解释没有，我看不懂。由于18这段宏换了个更容易理解的名字，而且加上了注释，我们可以从18的源码来理解13，看看这个wal record是干什么的。

这3个opcodes本质上都是为了PRUNE产生的wal record。从名字上看PRUNE ON ACCESS看着像访问产生PRUNE，另外两个跟VACUUM动作相关。

用pg_waldump查看wal record的时候，rmgr: Heap2 CLEAN remxid这种record每几秒钟就生成几条，而且filenode差异很大，且跟静态表毫无关系：

$ pg_waldump 00000001000012FE00000001 |tail -200|egrep -i heap2
pg_waldump: fatal: error in WAL record at 12FE/F34F138: invalid resource manager ID 50 at 12FE/F34F168
rmgr: Heap2 len (rec/tot): 61/ 3520, tx: 0, lsn: 12FE/0F346ED0, prev 12FE/0F346EA0, desc: CLEAN remxid 1983744188, blkref #0: rel 1663/88121/1083807 blk 617606 FPW
rmgr: Heap2 len (rec/tot): 66/ 66, tx: 0, lsn: 12FE/0F34BC60, prev 12FE/0F34BC30, desc: CLEAN remxid 1984090598, blkref #0: rel 1663/88121/504681 blk 1447147

这个就跟我们的现象有点匹配了：没有vacuum动作但是有PRUNE，可以走到后续heap_xlog_clean ResolveRecoveryConflictWithSnapshot等查询冲突主函数上去。

PRUNE动作产生rmgr: Heap2 CLEAN remxidwalrecord后面会测试复现。

先把源码撸完。

ResolveRecoveryConflictWithSnapshot
#

void
ResolveRecoveryConflictWithSnapshot(TransactionId latestRemovedXid, RelFileNode node)
{
	VirtualTransactionId *backends;

	/*
	 * If we get passed InvalidTransactionId then we do nothing (no conflict).
	 *
	 * This can happen when replaying already-applied WAL records after a
	 * standby crash or restart, or when replaying an XLOG_HEAP2_VISIBLE
	 * record that marks as frozen a page which was already all-visible. It's
	 * also quite common with records generated during index deletion
	 * (original execution of the deletion can reason that a recovery conflict
	 * which is sufficient for the deletion operation must take place before
	 * replay of the deletion record itself).
	 */
	if (!TransactionIdIsValid(latestRemovedXid))
		return;

	backends = GetConflictingVirtualXIDs(latestRemovedXid,
										 node.dbNode);

	ResolveRecoveryConflictWithVirtualXIDs(backends,
										 PROCSIG_RECOVERY_CONFLICT_SNAPSHOT,
										 WAIT_EVENT_RECOVERY_CONFLICT_SNAPSHOT,
										 true);
}

查询冲突有几个类型，其中ResolveRecoveryConflictWithSnapshot人如其名就是跟快照冲突了，

其中GetConflictingVirtualXIDs是找到哪些backends跟快照冲突。ResolveRecoveryConflictWithVirtualXIDs主要是解决冲突，时间限制。

GetConflictingVirtualXIDs
#

GetConflictingVirtualXIDs是判断是否vxid backend发生查询冲突的关键函数，要稍微用点脑力。关键函数解读所需要的基础知识：

limitXmin就是latestRemovedXid，也就是wal中的 CLEAN remxid，也就是需要被清理的xid（remxid我理解为remove xid）。/*limitXmin is supplied as either latestRemovedXid, or InvalidTransactionId*/
PGPROC是当前进程信息，有backend id，databas id，锁信息等等很多东西
PGXACT是当前进程持有的快照的事务信息，信息没有那么多，最关键的就是xmin——当前进程运行的最小xid
c中||的规则是：只要有一个操作数为真（非零），结果就为真（1）
TransactionIdIsValid即xid!=0，0完全没有意义

关键函数GetConflictingVirtualXIDs解读：

VirtualTransactionId *
GetConflictingVirtualXIDs(TransactionId limitXmin, Oid dbOid)
{
	...
	for (index = 0; index < arrayP->numProcs; index++) //所有本地进程循环处理
	{
		int			pgprocno = arrayP->pgprocnos[index];
		PGPROC	 *proc = &allProcs[pgprocno]; //进程的PGPROC
		PGXACT	 *pgxact = &allPgXact[pgprocno]; //进程的PGXACT

		/* Exclude prepared transactions */
		if (proc->pid == 0) //prepared transaction没有进程持有，处理不了
			continue;

		if (!OidIsValid(dbOid) || //要注意全局的表，全局表的dbOid=0是invalid的，满足条件
			proc->databaseId == dbOid) //只处理当前database。跨库是另一码事了，根本不会事务冲突。
		{
			/* Fetch xmin just once - can't change on us, but good coding */
			TransactionId pxmin = UINT32_ACCESS_ONCE(pgxact->xmin); //pgxact->xmin即是当前进程持有事务的最小xid，UINT32_ACCESS_ONCE只是为了保护原子操作，取xmin逻辑不变

			/*
			 * We ignore an invalid pxmin because this means that backend has
			 * no snapshot currently. We hold a Share lock to avoid contention
			 * with users taking snapshots. That is not a problem because the
			 * current xmin is always at least one higher than the latest
			 * removed xid, so any new snapshot would never conflict with the
			 * test here.
			 */
			if (!TransactionIdIsValid(limitXmin) || //limitXmin=0还能出现？至少latestRemovedXid不可能有，我想不到有什么场景会出现wal日志写入无效xid
				(TransactionIdIsValid(pxmin) && !TransactionIdFollows(pxmin, limitXmin))) //TransactionIdIsValid(pxmin)也没有什么用。!TransactionIdFollows(pxmin, limitXmin)表示只要pxmin<=limitXmin即可
			{
				VirtualTransactionId vxid;

				GET_VXID_FROM_PGPROC(vxid, *proc);
				if (VirtualTransactionIdIsValid(vxid))
					vxids[count++] = vxid;
			}
		}
	}

最关键的是!TransactionIdFollows(pxmin, limitXmin)

所以这段判断是否存在查询冲突的代码，最主要判断逻辑是：

主库清理的remxid>=从库查询的快照持有的最小xid，即冲突。
只掐掉当前db的；没有db的全局系统表就不管了会无脑掐

所以即使被清理的主库表和从库查询的表不相干，也会冲突！！！

页内修剪
#

发生冲突的逻辑理完了，但wal CLEAN 怎么来的还没有弄清楚，这就需要先看下PRUNE怎么产生的。

README.HOT关于什么时候产生prune和defragment的描述– When can/should we prune or defragment?

The currently planned heuristic is to prune and defrag when first accessing a page that potentially has prunable tuples

prune和defragment确实是2个概念，但是很有可能一起做了。

prune指更新line pointers使HOT链更短，但不会释放空间
defragment指回收prune后page上已死的line pointers和行所占用的空间

We cannot prune or defragment unless we can get a “buffer cleanup lock” on the target page; otherwise, pruning might destroy line pointers that other backends have live references to, and defragmenting might move tuples that other backends have live pointers to

page是"buffer cleanup lock"的，才会产生prune或者defragment

The worst-case consequence of this is only that an UPDATE cannot be made HOT but has to link to a new tuple version placed on some other page, for lack of centralized space on the original page.

其中一个典型场景是，HOT更新到了page外（容易测试）

space reclamation happens during tuple retrieval when the page is nearly full (<10% free) and a buffer cleanup lock can be acquired. This means that UPDATE, DELETE, and SELECT can trigger space reclamation, but often not during INSERT … VALUES because it does not retrieve a row.

SELECT/UPDATE/DELETE扫描行的都可能发生空间回收动作，INSERT不会，因为INSERT不会扫描行。

显然prune or defragment后对应的xid应该回收了，从readme就可以看出来通过HOT更新可以复现prune or defragment，然后产生CLEAN walrecord。见[测试：update产生页内修剪](## 测试：纯update产生页内修剪)

测试
#

以下测试只观察到冲突产生或者有CLEAN walrecord或者有页上lp的更新，不区分到底是prune还是defragment。很多场景应该是一起触发两者，区分两者有点费劲，maybe以后再说。这里主要是看CLEAN walrecord等有没有。

会用到的sql：

--sql for test
--heap_page_items
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('lzl',0)) item,
LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2) info 
order by lp;

--heap header 
select * from page_header(get_raw_page('lzl',0));

--bt_page_items
SELECT itemoffset, ctid, itemlen, nulls, vars, dead, htid, tids[0:2] AS some_tids FROM bt_page_items('idxlzl',1);

--create table
create table lzl(a char(2000));
create index idxlzl on lzl(a);
insert into lzl values('z');
update lzl set a=md5(random()::text); --非hot
update lzl set a='z'; --hot

--触发索引扫描
set enable_seqscan =off;
set enable_indexonlyscan=off;

--开启rr事务获取快照不释放，方便观察
BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;

测试：异表查询冲突
#

primary	standby
create table lzl(a bigint primary key);
insert into lzl values(1);
	BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;
	select 1;
update lzl set a=2;
	不阻塞
vacuum lzl;
	#3 ResolveRecoveryConflictWithVirtualXIDs (waitlist=0x277c340, reason=reason@entry=PROCSIG_RECOVERY_CONFLICT_SNAPSHOT, wait_event_info=wait_event_info@entry=134217762, report_waiting=report_waiting@entry=true) at standby.c:276 #4 0x0000000000787b33 in ResolveRecoveryConflictWithVirtualXIDs (report_waiting=true, wait_event_info=134217762, reason=PROCSIG_RECOVERY_CONFLICT_SNAPSHOT, waitlist=) at standby.c:333 #5 ResolveRecoveryConflictWithSnapshot (latestRemovedXid=, node=…) at standby.c:329 #6 0x00000000004c8ffe in heap_xlog_clean (record=0x273a258) at heapam.c:7764

结论：只要查询产生，就会有快照，有快照就会有快照xmin，即使查询的表毫不相干，也可以发生查询冲突

测试：vacuum产生页内修剪
#

会修剪，会冲突。示例略，跟本案无关

测试：update产生页内修剪
#

--HOT，更新到页外defragment
--一个8k的heap page，存储的行数是4-2xx条。这里规划了行大小，生成4条数据保证HOT，下一条更新即触发页外更新
create table lzl(a char(2000));
create table idxlzl on lzl(a);
insert into lzl values('z');
update lzl set a='z'; --hot
update lzl set a='z'; --hot
update lzl set a='z'; --hot

--heap page 4条数据，且HOT:
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags | 
--------+----+-----------+----------+----------+-------+----------------------------------------------------------------------------------------------------------+----------------+----------
 (0,2) | 1 | LP_NORMAL | 34954161 | 34954162 | 0 | {HEAP_HASVARWIDTH,HEAP_XMIN_COMMITTED,HEAP_XMAX_COMMITTED,HEAP_HOT_UPDATED} | {} | \x501f000
 (0,3) | 2 | LP_NORMAL | 34954162 | 34954163 | 0 | {HEAP_HASVARWIDTH,HEAP_XMIN_COMMITTED,HEAP_XMAX_COMMITTED,HEAP_UPDATED,HEAP_HOT_UPDATED,HEAP_ONLY_TUPLE} | {} | \x501f000
 (0,4) | 3 | LP_NORMAL | 34954163 | 34954164 | 0 | {HEAP_HASVARWIDTH,HEAP_XMIN_COMMITTED,HEAP_UPDATED,HEAP_HOT_UPDATED,HEAP_ONLY_TUPLE} | {} | \x501f000
 (0,4) | 4 | LP_NORMAL | 34954164 | 0 | 0 | {HEAP_HASVARWIDTH,HEAP_XMAX_INVALID,HEAP_UPDATED,HEAP_ONLY_TUPLE} | {} | \x501f000
(4 rows)

--索引条目仅一个：
 itemoffset | ctid | itemlen | nulls | vars | dead | htid | some_tids 
------------+-------+---------+-------+------+------+-------+-----------
 1 | (0,1) | 48 | f | t | f | (0,1) | [null]

--再更新一条，触发页外更新
update lzl set a='z'; --page已满，hot不了了

--hot链改变。lp改变
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags | 
--------+----+-------------+----------+----------+--------+--------------------------------------------------------------------------------------+----------------+---------------------------
 [null] | 1 | LP_REDIRECT | [null] | [null] | [null] | [null] | [null] | [null]
 (0,2) | 2 | LP_NORMAL | 34954165 | 0 | 0 | {HEAP_HASVARWIDTH,HEAP_XMAX_INVALID,HEAP_UPDATED,HEAP_ONLY_TUPLE} | {} | \x501f00007a20202020202020
 [null] | 3 | 0:LP_UNUSED | [null] | [null] | [null] | [null] | [null] | [null]
 (0,2) | 4 | LP_NORMAL | 34954164 | 34954165 | 0 | {HEAP_HASVARWIDTH,HEAP_XMIN_COMMITTED,HEAP_UPDATED,HEAP_HOT_UPDATED,HEAP_ONLY_TUPLE} | {} | \x501f00007a20202020202020
(4 rows)

--索引条目仅一个，没变：
 itemoffset | ctid | itemlen | nulls | vars | dead | htid | some_tids 
------------+-------+---------+-------+------+------+-------+-----------
 1 | (0,1) | 48 | f | t | f | (0,1) | [null]

再次更新，row没有写到下个页，而是在本页发生页内修剪后写入本页，这样减少了一个页的访问。

wal产生CLEAN remxid ，也说明可以发生查询冲突：

rmgr: Heap2 len (rec/tot): 62/ 62, tx: 0, lsn: 3DB/F8017348, prev 3DB/F8017310, desc: CLEAN remxid 34954177, blkref #0: rel 1663/5893914/5893920 blk 0
rmgr: Heap len (rec/tot): 2070/ 2070, tx: 34954178, lsn: 3DB/F8017388, prev 3DB/F8017348, desc: HOT_UPDATE off 4 xmax 34954178 flags 0x10 ; new off 2 xmax 0, blkref #0: rel 1663/5893914/5893920 blk 0

结论：update语句可产生页内修剪，可产生查询冲突

测试：hintbit回写产生页内修剪？
#

primary	standby
wal_log_hints=on
truncate table lzl;
insert into lzl values(‘z’);
	BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;
	select * from lzl;
delete from lzl where a=‘z’;
checkpoint;
select * from lzl;
–wal中生成FPI_FOR_HINT
	–未发生查询冲突

standby的pageinspect：

 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags | substring 
--------+----+-----------+----------+----------+-------+------------------------------------------------------------------------------+----------------+-------------------------------------------------
 (0,1) | 1 | LP_NORMAL | 34954229 | 34954230 | 0 | {HEAP_HASVARWIDTH,HEAP_XMIN_COMMITTED,HEAP_XMAX_COMMITTED,HEAP_KEYS_UPDATED} | {} | \x501f00007a202020202020202020202020202020202020
(1 row)

结论：wal log hint只是同步hintbit，不会对xmin/xmax产生影响，wal也不会有CLEAN等东西的产生，所以hintbit回写不会查询冲突。

测试：查询产生页内修剪
#

查询正常不会修剪，但page被填满会：https://www.modb.pro/db/1683648157451362304

填满page测试pruning：

--还是刚才的表，4条记录且HOT，几乎填满
insert into lzl values('z');
update lzl set a='z'; 
update lzl set a='z'; 
update lzl set a='z'; 

--此时的page：
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags | 
--------+----+-----------+----------+----------+-------+----------------------------------------------------------------------------------------------------------+----------------+---------------------
 (0,2) | 1 | LP_NORMAL | 34954232 | 34954233 | 0 | {HEAP_HASVARWIDTH,HEAP_XMIN_COMMITTED,HEAP_XMAX_COMMITTED,HEAP_HOT_UPDATED} | {} | \x501f00007a20202020
 (0,3) | 2 | LP_NORMAL | 34954233 | 34954234 | 0 | {HEAP_HASVARWIDTH,HEAP_XMIN_COMMITTED,HEAP_XMAX_COMMITTED,HEAP_UPDATED,HEAP_HOT_UPDATED,HEAP_ONLY_TUPLE} | {} | \x501f00007a20202020
 (0,4) | 3 | LP_NORMAL | 34954234 | 34954235 | 0 | {HEAP_HASVARWIDTH,HEAP_XMIN_COMMITTED,HEAP_UPDATED,HEAP_HOT_UPDATED,HEAP_ONLY_TUPLE} | {} | \x501f00007a20202020
 (0,4) | 4 | LP_NORMAL | 34954235 | 0 | 0 | {HEAP_HASVARWIDTH,HEAP_XMAX_INVALID,HEAP_UPDATED,HEAP_ONLY_TUPLE} | {} | \x501f00007a20202020
(4 rows)

-- 一个查询
select * from lzl;

--此时的page产生页内修剪
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags | sub
--------+----+-------------+----------+--------+--------+---------------------------------------------------------------------------------------+----------------+---------------------------------------
 [null] | 1 | LP_REDIRECT | [null] | [null] | [null] | [null] | [null] | [null]
 [null] | 2 | 0:LP_UNUSED | [null] | [null] | [null] | [null] | [null] | [null]
 [null] | 3 | 0:LP_UNUSED | [null] | [null] | [null] | [null] | [null] | [null]
 (0,4) | 4 | LP_NORMAL | 34954235 | 0 | 0 | {HEAP_HASVARWIDTH,HEAP_XMIN_COMMITTED,HEAP_XMAX_INVALID,HEAP_UPDATED,HEAP_ONLY_TUPLE} | {} | \x501f00007a20202020202020202020202020

结论：查询可以产生页内修剪，可以产生查询冲突

测试：共享表多database查询冲突
#

共享表是global的，之前在GetConflictingVirtualXIDs中有看到global的会无脑冲突。所以可以测一把。

共享表信息如下：

源码定义：IsSharedRelation
源码判断：shared ? InvalidOid : MyDatabaseId;
表：pg_class.relisshared
目录： global/

直接查pg_class.relisshared要方便一点：

select relname,relkind,relisshared from pg_class where relisshared is true and relkind='r';
		relname | relkind | relisshared 
-----------------------+---------+-------------
 pg_authid | r | t
 pg_subscription | r | t
 pg_database | r | t
 pg_db_role_setting | r | t
 pg_tablespace | r | t
 pg_auth_members | r | t
 pg_shdepend | r | t
 pg_shdescription | r | t
 pg_replication_origin | r | t
 pg_shseclabel | r | t

pg_authid会保存角色/用户的信息。这里以改密来测试：

--测试，在primary库 非业务db跑
create user lzl;
alter user lzl with password '1'; --多跑几次

产生CLEAN remxid：

rmgr: Heap len (rec/tot): 76/ 76, tx: 34954264, lsn: 3DB/F808D0F8, prev 3DB/F808D0B8, desc: HOT_UPDATE off 67 xmax 34954264 flags 0x20 ; new off 66 xmax 0, blkref #0: rel 1664/0/1260 blk 0
rmgr: Transaction len (rec/tot): 82/ 82, tx: 34954264, lsn: 3DB/F808D148, prev 3DB/F808D0F8, desc: COMMIT 2025-09-12 14:40:56.680782 CST; inval msgs: catcache 11 catcache 10
rmgr: Heap2 len (rec/tot): 60/ 60, tx: 0, lsn: 3DB/F808D1A0, prev 3DB/F808D148, desc: CLEAN remxid 34954264, blkref #0: rel 1664/0/1260 blk 0
rmgr: Heap2 len (rec/tot): 60/ 60, tx: 34954265, lsn: 3DB/F808D1E0, 

从库业务db的SQLselect 1被掐掉。

结论：共享表可以发生跨db查询冲突。

不过这些共享表正常业务很难有大量更新。

结论
#

开发视野
#

查询冲突可以跟查询的表无关，也就是说完全静态的表是可以发生冲突的。

跨db意味着不同的业务和数据。跨db不会发生查询冲突。一个例外是共享表会，但是共享表只有几个系统表，一般不会有什么更新。

对于开发来说，可以关注以下点：

请求重试：从库的查询可能会被掐掉，重试查询是必要的，重试有可能会成功
SQL时长：SQL时间越长越容易被掐掉
其他从库：可能要选择其他容灾属性不高的从库

运维视野
#

因为查询冲突可以从“四面八方”来，一个简单的长时间单表查询，可能会被其他频繁更新的表的页内修剪给干掉，所有可以调大max_standby_streaming_delay以降低冲突的概率。

但是，max_standby_streaming_delay是以牺牲应用日志为代价的，相当于日志应用停止。这个参数的大小就代表了最大可能的从库复制延迟（限制不了网络延迟等其他因素造成的延迟）。

查询时效：长时间的日志应用停止，从库的数据会严重落后（可能wal已经在从库磁盘上），会影响从库其他查询的数据时效要求。
RTO：如果主库灾难发生需要切换到从库，从库需要日志应用的时间。如果apply延迟太长比如几个小时，可能不能满足分钟级切换要求，这直接会影响SLA RTO承诺。

所以，调整max_standby_streaming_delay是一个精细活，需要从从库的角色定义，查询时效要求，甚至地域等来综合考虑。

PostgreSQL DDL变更的坑和巧妙方案

Sat, 19 Jul 2025 00:00:00 +0000

自行保存，随便使用，不用问我

可能更新，也可能不会更新

欢迎交流，尽量挑刺

Linux内存进阶

Thu, 19 Jun 2025 00:00:00 +0000

（内存基础知识参考 linux内存浅析，本篇只有其上的内存知识）

内存基本概念
#

buddy
#

buddy系统申请和合并page的过程，略。

容易忽略的知识点：

buddy合并2个同大小块的前提它俩的物理地址连续
合并算法是迭代的，本级合并后会自行尝试合并更大的块。也就是说可以不依赖compactd来处理合并

page table & PTE
#

page table和PTE其实是两个不同的概念，十分容易混淆，因为他们总体还是在说页表。以下是page table和PTE的相关知识¹

PTE存储了页框的物理地址
“page table”和“Page Table”是不同的概念，“page table”指保持线性地址和物理地址之间映射的页，“Page Table”是上层页表中的页
pte_t、pmd_t、pud_t、pgd_t 分别描述页表项、页中间目录项、页上级目录项、页全局目录项
PTE是Page Table Entry

如果只是看MMU缓存虚拟内存到物理内存映射区pagetable大小，把pagetable和PTE混淆差别不大；如果要深入到页表目录，需要将两个概念分开。

TLB
#

每一级的页表是存储在内存里的，在完成一次虚拟内存地址转换的过程中，需要把当前虚拟地址对应的四个页表全部找出来，才能完成从虚拟地址到物理地址的转换。说明一次内存IO仅虚拟地址到物理地址的转换就要区内存查4次页表。Translation Lookaside Buffers，就是专门用于加速虚拟地址到物理地址转换速度的缓存。

关于TLB的位置，它通常位于L1缓存中（也有说在寄存器orL2的，应该跟cpu架构有关系，权且就当成cpu缓存，与主存区分）²：

在现代处理器中，L1缓存通常被划分为多个部分，包括数据缓存dTLB、指令缓存iTLB。频繁地修改页表会导致导致访问主存次数增加，这会使CPU频繁地刷新TLB缓存 ¹。TLB也是有大小的，提升TLB的命中率可以减少对主存pagetable的访问。使用大页可以降低PTE三个数量级，TLB Miss会大大降低。³。

TLB的信息：

#cpuid -l
 L1 TLB/cache information: 2M/4M pages & L1 TLB (0x80000005/eax):
 L1 TLB/cache information: 4K pages & L1 TLB (0x80000005/ebx):
...
 L2 TLB/cache information: 2M/4M pages & L2 TLB (0x80000006/eax):

观察TLB命中率:

perf stat -e dTLB-loads,dTLB-load-misses,iTLB-loads,iTLB-load-misses -I 10000 -p $PM_PID 

在内存回收时，观察TLB missing确实会上涨，但难以形成因果关系，TLB missing只是观察MMU的一种观测指标，TLB is part of MMU。

反向映射
#

PFRA（page fram reclaiming algorithm）页框回收算法总体原则¹：

首先释放“无害”页。先回收pagecache上的无害页，这些页没有被任何进程占用
用户态进程的所有页定位可回收页。FRPA将睡眠时间较长的用户态页可逐渐失去页框
取消一个共享页框的所有页表项的映射，然后就可以回收该共享页框
只回收“未用”页

PFRA目标之一就是能释放共享页框，能快速定位指向同一页框的所有页表项的过程就叫反向映射（reverse mapping）。

Reverse mappings for shared

Anonymous pages
File-mapping pages

Basic tricks of page frame reclaiming

LRU lists
Free cheapest pages first
Unmap all at once
Etc⁴

大页
#

开启大页对特定应用的负载有一定提升。在pg中，大内存库开启大页也有一定的性能提升，甚至有一些稳定性的好处。

为什么大页更好？[^ kernel.org, Page Table Management]：

减少TLB的压力
减少pagetable在主内存上的大小
大页在物理上是连续的。连续的物理内存访问比不连续的物理内存访问更优
When using these kinds of larger pages, higher level pages can directly map them, with no need to use lower level page entries[^ kernel.org,mm pagetables]

不过使用大页会带来管理上的挑战：

需要提前分配大页
需要提前计算大页大小，以避免内存浪费

进程使用大页的两种方式：

The first is by using shmget() to setup a shared region backed by huge pages
the second is the call mmap() on a file opened in the huge page filesystem

C库和系统调用
#

内核空间和用户空间之间的中间层就是系统调用层。应用编程接口（API)和系统调用是不同的。应用程序调用用户空间的实现的应用编程接口来编程，而不是直接执行系统调用。在UNIX的世界里，最通用的系统调用层是POSIX标准(Portable Operation System Interface of UNIX)。POSIX标准针对的是API而不是系统调用。Linux操作系统的API通常以C标准库方式提供，如libc库。C标准库提供了POSIX的绝大部分API的实现。⁵

C app->C lib->system calls->OS->hardware⁶:

常见C库和系统调用：

malloc,free=>C lib

mmap、brk、munmap=>系统调用

缺页异常
#

缺页异常（or缺页中断）需要区分两种情况：由编程错误所引起的异常；用虚拟地址空间但尚未分配物理页框所引起的分配物理页的行为。¹

异常的缺页：Segment Fault——每个虚拟内存区域具有相关权限。如果一个进程访问了不在有效范围内的内存区域，或者非法访问了内存区域，或者以不正确的方式访问了内存区域，那么处理器会报告缺页异常，严重的会报告“Segment Fault”段错误并终止进程⁵。
正常的缺页：mmap、brk等系统调用都是管理虚拟内存的，它们不直接分配物理内存。虚拟内存系统调用函数只建立进程地址空间，在用户空间里可以看到虚拟内存，但没有建立虚拟内存和物理内存直接的映射关系。当进程访问这些还没有建立映射关系的虚拟内存时，触发缺页中断。⁵

缺页类型也分两种

minor fault：没有阻塞当前进程的情况下处理了缺页，分配了页框
major fault：缺页迫使当前进程睡眠（很可能是用磁盘上的数据填充页框花费时间），阻塞当前进程缺页就是主缺页major fault¹

写时复制COW
#

当执行fork系统调用时，子进程和父进程拥有独立的进程地址空间，但是共享物理内存资源，包括进程上下文、进程栈、内存信息、文件描述符、目录、资源限制等。只需要复制父进程中页表给子进程。此时以只读方式共享，当需要写入时（运行各自的任务时），数据才会被复制，使父进程和子进程拥有各自的副本。⁵

对于PG多进程来说，fork本身不算重，可能只需要关心页表，但是fork之后到来的各种任务会发生写时复制创建子进程自己的资源副本。

注意区分写时复制和缺页异常：写时复制是说的fork时没有分配相应的资源给子进程；缺页异常是说的这个进程发生了物理内存分配，跟fork没有关系。

mmap、brk&共享内存映射区、堆区
#

mmap、brk的功能和所使用的内存地址区域是不同的：

mmap 用于管理共享内存，对应共享内存映射区
brk 用于管理私有内存，对应堆区

线性地址分区功能：

mmap ：映射区域至顶向下扩展，mmap 映射区域和堆相对扩展，直至耗尽虚拟地址空间中的剩余区域，这种结构便于C运行时库使用mmap 映射区域和堆进行内存分配。
栈区(Stack)：存储程序执行期间的本地变量和函数的参数，从高地址向低地址生长
堆区(Heap)：动态内存分配区域，通过 malloc、new、free 和delete 等函数管理
未初始化变量区(BSS)：存储未被初始化的全局变量和静态变量
数据区(Data)：存储在源代码中有预定义值的全局变量和静态变量
代码区(Text)：存储只读的程序执行代码，即机器指令。

共享内存映射区和堆区⁷ ：

真实的postmaster的堆区和共享内存映射：

cat /proc/1063005/smaps |grep -E "\-s|heap"
022a4000-022ee000 rw-p 00000000 00:00 0 [heap]
7fef6019e000-7fef601a5000 rw-s 00000000 00:17 21 /dev/shm/PostgreSQL.1291978332
7fef601a5000-7fef6098b000 rw-s 00000000 00:01 1052 /dev/zero (deleted) #这是shared buffers的
7fef6e238000-7fef6e239000 rw-s 00000000 00:01 10 /SYSV0011f702 (deleted)

可以看到heap和共享内存区的地址差不多能对上。

VM
#

linux内核virtual memory子系统

目录：cd /proc/sys/vm/

compact
#

concept & param
#

内存压缩（Compaction）是Linux内核用于解决内存碎片化问题的机制，通过合并空闲物理页，提升大块内存页的分配和压缩效率。

参数名	功能定位	默认值/范围
`compact_memory`	手动触发全局内存压缩操作	写入1触发
`compaction_proactiveness`	控制主动压缩的触发频率	4.x才有的参数。0-100（默认20）
`compact_unevictable_allowed`	是否允许压缩不可回收页（如`mlock`锁定的内存）	4.x才有的参数。0（禁止）或1（允许）
`defrag_mode`	控制内存碎片整理的触发策略	4.x才有的参数。0-3，0表示关闭自动compaction特性，只能手动压缩；1表示defer开启被动压缩。3.10默认1
`extfrag_threshold`	大块内存不足时，触发压缩的阈值	0-1000（默认500）

压缩有3种模式（跟内核版本是否支持相关）：

被动压缩：extfrag_threshold是进程申请大块内存发现已经不足是否压缩，解决“已发生”的碎片问题。
主动压缩：compaction_proactiveness是主动控制压缩的积极性，优化“未发生”但可能出现的碎片风险。
手动压缩：compact_memory。

extfrag_threshold是Linux内核中控制被动压缩的参数。当内核尝试分配高阶连续物理内存（如大页）失败时，会通过碎片化指数判断失败原因：

-1：分配成功（满足水位线）
0：因内存不足失败
1000：因碎片化失败

通过/sys/kernel/debug/extfrag/extfrag_index查看具体值，其输出为浮点数（如0.854），但实际范围被放大1000倍，例如0.854对应实际值854：

cat /sys/kernel/debug/extfrag/extfrag_index |grep Normal
Node 0, zone Normal -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 0.995 0.998 

若extfrag_threshold=600，则当碎片化指数>600时触发压缩。extfrag_index还是挺有用的，可以协助buddy观察碎片问题。

dirty
#

concept & param
#

刷脏跟内存回收有点类似，也分异步和同步：

异步刷脏：由pdflush/flush/kdmflush等后台线程执行，应用写入不受影响
同步刷脏：直接阻塞应用进程，由发起写操作的进程自己刷脏

参数名称	作用描述	默认值
dirty_background_bytes	后台异步刷脏阈值，字节	0（未启用）
dirty_background_ratio	后台异步刷脏阈值，百分比	10%
dirty_bytes	同步刷脏阈值，字节	0（未启用）
dirty_ratio	同步刷脏阈值，百分比	20-40%
dirty_expire_centisecs	脏页在内存中的最长存活时间	3000（30秒）
dirty_writeback_centisecs	内核周期性检查脏页状态的频率	500（5秒）

xxx_bytes和xxx_ratio参数互斥。

示例参数和流程图：

dirty_background_bytes 0
dirty_background_ratio 10
dirty_bytes 0
dirty_ratio 40
dirty_expire_centisecs 3000
dirty_writeback_centisecs 500

%% 整合时间参数的刷脏流程图
graph TD
 A[应用程序写入生成脏页] --> B{检查周期到达?<br>dirty_writeback_centisecs 每5秒}
 B -- 否 --> D{存在超时脏页?<br> dirty_expire_centisecs>30秒}
 B -- 是 --> C{脏页阈值检查}
 C --> E[脏页占比? dirty_background_ratio>10% ]
 C --> F[脏页占比? dirty_ratio> 40%]
 E -- 触发 --> G[后台异步刷脏]
 F -- 触发 --> H[同步刷脏]
 D -- 触发 --> G
 G --> I[脏页写入磁盘]
 H --> I[脏页写入磁盘] 
 I --> J[释放内存空间]

刷脏参数的设置跟pg刷脏参数的基本原理差不多，设置的过低刷脏过于频繁，同一个脏页可能多次写入磁盘浪费IO，过高可能会有IO风暴。

观察脏页
#

监控脏页

ps -eo pid,%cpu,%mem,wchan,args,state|grep kdmflush|grep -E -w -v "S" #观察异步刷脏进程状态
cat /proc/vmstat| grep -E -w "nr_dirty|nr_writeback" #vmstat dirty,页数
cat /proc/meminfo |grep -i dirty #meminfo dirty，kb

使用dd测试脏页

 grep -E "nr_dirty_threshold|nr_dirty_background_threshold" /proc/vmstat | awk '{printf "%s: %.2fGB\n", $1, ($2*4)/1048576}'
nr_dirty_threshold: 141.28GB
nr_dirty_background_threshold: 35.32GB

dd if=/dev/zero of=testfile bs=8k count=128000 # cache io

失败测试（测试多次仍然是这个结果）：

未见RUNNING kdmflush进程
没有满35GB，也没有满30S，脏页就被刷下去了

时间戳	nr_dirty	nr_dirty(GB)	趋势模拟
17:00:18	2,757	0.01052	▍
17:00:19	336,199	1.282	████▌
17:00:25	1,984,867	7.574	██████████████▍
17:00:32	4,252,177	16.22	████████████████████
17:00:33	3,699,227	14.11	█████████████████▊
17:00:38	170,865	0.652	▎
17:00:46	2,865,814	10.93	█████████▋
17:00:54	4,721,827	18.01	██████████████████████
17:00:55	3,876,509	14.79	██████████████████
17:01:03	835,097	3.186	██▊

os dirty !=pg dirty
#

pg fsync=on，数据写入是需要经过os pagecache然后再将指定块写入磁盘的。pg有自己的drity，os也有dirty，两者是什么关系？

## 观察语句
cat /proc/meminfo |grep -E -w "Dirty" # os脏页

select isdirty,pinning_backends,count(*) from pg_buffercache where isdirty is true group by isdirty,pinning_backends; # pg脏页

checkpoint;
begin;
--观察
insert into tlzl select generate_series(1,1000000);
--观察
commit;
--观察
checkpoint;
--观察

测试结果：

stage	dirty in pg	os dirty
干净状态	0	0.02-2M 浮动
insert完成	200M	上涨到1.7G，随后降落到20KB
commit提交	200M	0.02-2M 浮动
checkpoint刷脏	0	0.02-2M 浮动

将插入数据加大，insert时os dirty会上涨，涨到GB级再浮动。

pg dirty跟os dirty有点关系但又不全是相关的，pg插入数据时 os dirty确实会上升，不过os自己刷脏后，pg的脏页仍然是脏页。初步判断共享内存中的脏页与os dirty无关，os dirty上涨暂未判断是不是pg私有内存的脏页。

swappiness
#

控制系统从anonymous memory pool或 page cache 中回收内存的偏向性。其实是控制交换匿名页或者回收文件页，谁的代价对于上层应用来说更低。比如计算类的应用，动态分配或者私有内存使用更多，应该设置更低的swappiness，依赖数据的应用设置更高的swapiness以降低刷file page对数据访问的影响。不过这一切都建立在swap IO和filesystem IO的效率上⁸。一切都很美好，但是swap发生时很可能意味着性能降低。

swappiness=0
#

swappiness=0时，内核会直到内存到达high水位线时，才会做swap⁹。具体的策略跟内核版本和NUMA也有关系。可以确认的是swappiness=0不代表关闭了swap，swapoff -a才是关闭swap功能。

#查看是否打开了swap
swapon --show
free -h |grep Swap
cat /proc/swaps
grep -E 'swap|none' /etc/fstab
cat /proc/meminfo|grep Swap

#监控swapping是否发生
cat /proc/vmstat|grep swp
sar -W 1

inconsistent swap behavior
#

os层的 /proc/sys/vm/swappiness 对 cgroups v1 的系统的swap特性几乎没有影响（has little-to-no effect on the swap）。此问题可能导致不一致的swap行为¹⁰。

发生场景（且）：

vm.swappiness != cgroups memory.swappiness
cgroups v1

发生原因：

systemd在启动初期创建cgroups，早于sysctl.service加载/etc/sysctl.conf ，vm.swappiness 无法限制cgroup memory.swappiness。问题在于，当os的swap行为和cgroup不同时，到底哪个该生效的问题。

解决办法：

for cgroup v1，设置vm.swappiness = all cgroups memory.swappiness
for cgroup v1，很多解决办法，参考https://access.redhat.com/solutions/6785021
使用cgroup v2。v2新增vm.force_cgroup_v2_swappiness参数，使cgroup的memory.swappiness失效

memory overcommitment
#

concept & param
#

linux不是为每个虚拟地址预留物理内存，而是等到实际需要内存时才进行分配。overcommitment可以限制所有进程申请的总虚拟内存的大小，申请的内存超过限定的物理内存大小时，称为overcommit。

overcommit策略参数有三个：overcommit_memory，overcommit_ratio/overcommit_kbytes

overcommit_memory参数控制overcommitment策略：

0(默认): 启发式overcommitment策略，允许轻微的overcommit，CommitLimit=物理内存+swap 。
1: 无overcommit检查
2: 严格限制，禁止超过CommitLimit

graph TD
 A[内存分配请求] --> B{Overcommit模式}
 B -->|模式0:启发式| C["允许适度超分虚拟内存"]
 B -->|模式1:无限制| D["虚拟内存承诺无约束"]
 B -->|模式2:严格限制| E["虚拟内存总量≤CommitLimit"]
 C --> F[运行时按需分配物理页]
 D --> G[可能耗尽物理内存+Swap]
 E --> H[强制虚拟内存总量控制]

当overcommit_memory=2时，overcommit_ratio和overcommit_kbytes参数只有一个会生效，此时的CommitLlimit计算如下： $$ CommitLimit = (RAM - 大页内存) × \frac{overcommit_ratio}{100} + SwapTotal $$ or $$ CommitLimit = (RAM - 大页内存) + overcommit_kbytes + SwapTotal $$ 有点意思的overcommit accounting¹¹,mmap、brk、fork都计算在内，明显对pg是有影响的：

Status
------
o	We account mmap memory mappings
o	We account mprotect changes in commit
o	We account mremap changes in size
o	We account brk
o	We account munmap
o	We report the commit status in /proc
o	Account and check on fork
o	Review stack handling/building on exec
o	SHMfs accounting
o	Implement actual limit enforcement

reserve内存和overcommmit
#

user_reserve_kbytes ：在overcommit_memory=2时，为普通用户进程预留的物理内存，在系统内存严重不足时，确保普通用户仍能执行基本操作（如启动新进程、处理内存分配请求）。默认值为 min(3% of the current process size, 128M)。当设置为0时，单个进程可以分配（所有空闲内存-admin_reserve_kbytes）

admin_reserve_kbytes：为具备 CAP_SYS_ADMIN 权限的用户（通常是 root 用户）保留的物理内存，确保管理员恢复能力，确保系统管理员可以登陆并执行命令的保留物理内存。默认min(3%内存, 8MB)。严格限制overcommit模式时最好提高该参数。

$ cat user_reserve_kbytes 
131072
$ cat admin_reserve_kbytes 
8192

观察overcommit
#

grep -E 'CommitLimit|Committed_AS' /proc/meminfo
sar -r 1

$ grep -E 'CommitLimit|Committed_AS' /proc/meminfo
CommitLimit: 203103492 kB
Committed_AS: 252170700 kB

$ sar -r 1
07:32:35 PM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty
07:32:37 PM 25472180 370249056 93.56 14588 274485956 252242936 62.91 233866528 103568816 12924
07:32:38 PM 25471904 370249332 93.56 14588 274487888 252242740 62.91 233851748 103570136 11180

观测指标含义：

meminfo CommitLimit：由物理内存、Swap及overcommit参数共同计算得出的CommitLimit
meminfo Committed_AS：当前所有进程已申请的虚拟内存总量
sar -r kbcommit = Committed_AS
sar -r %commit =kbcommit/总物理内存

smaps或者status也可以查看总申请的虚拟内存，但直接算smaps/status的总计虚拟内存重复计算了共享库文件，映射文件（如mmap），而Committed_AS 仅统计mmap、brk、fork等申请的内存，且不会重复计算共享内存。两者计算口径不同，看总虚拟内存还是看Committed_AS或者kbcommit就行。

watermark
#

参数名称	作用描述	引入版本	默认值	单位/范围
min_free_kbytes	定义系统保留的最小空闲内存量，直接影响内存水位 `watermark[min]` 的计算，确保系统在内存紧张时保留足够内存供关键操作使用	早期内核版本		KB
watermark_scale_factor	全局调节内存水位线间距（`high-low` 和 `low-min`）	Linux 内核4.x（4.几未知）	`10`（ 0.1%物理内存）	最大`3000`（30%物理内存）
watermark_boost_factor	临时提升内存高水位线（`high`），触发积极内存回收以减少碎片化	Linux 内核4.x（4.几未知）	`15000`（即 1.5 倍原始高水位线）

min_free_kbytes
#

## 从zoneinfo中计算zone的总min等值
cat /proc/zoneinfo | grep -E -w "min|low|high"|grep -E -v "high:"| awk '
/min/ { total_min += $2 }
/low/ { total_low += $2 }
/high/ { total_high += $2 }
END {
 printf "总min: %d KB\n总low: %d KB\n总high: %d KB\n",
 total_min * 4, total_low * 4, total_high * 4;
}'
总min: 15828844 KB
总low: 19786048 KB
总high: 23743260 KB

#当前系统min值
cat min_free_kbytes
15828849

因为有其他zone，所有zone的总min加起来才差不多min_free_kbytes。Normal zone的min肯定比min_free_kbytes小一点点，只需要关注Normal zone就行了：

## Normal zone的min、low、high设置；page=4k
cat /proc/zoneinfo | grep -A 50 Normal | grep -E "min|low|high"
 min 3931615
 low 4914518
 high 5897422

在Linux 内核4.6前，min、low、high是固定比例，只能通过设置min_free_kbytes来改变low、high的值，min：low：high=1：1.25：1.5。

固定比例的问题：

本身应该提高low积极触发kswapd异步回收，降低min减少direct reclaim。在4.6前只能通过调整min来间接调整low/high，通过调整min来调整kswapd的delta工作缓冲。例如

	kswapd异步回收工作缓冲（low-min）	kswapd异步回收工作量（high-low）
min=1GB，low=1.25GB，high=1.5GB	0.25GB	0.25GB
min=10GB，low=12.5GB，high=15GB	2.5GB	2.5GB

提高min是为了提高low和high。

过低的min值，会导致kswapd还没来得及异步回收更多的内存，direct reclaim就触发了。过高的min，不仅浪费了内存，也会导致内存回收动作更频繁，sys cpu会更多。Linux中默认的low与min之间的差值确实显得小了点。

watermark_scale_factor
#

如果可以直接调整min、low、high不是美滋滋吗？抱歉，linux内核没有（安卓有extra_free_kbytes）。但是，

linux4.x内核以后新增watermark_scale_factor参数可以调节参数之间的比例，比例不再是固定的了。其默认值为10，对应内存占比0.1%(10/10000)，最大为3000。当它的值被设定为1000时，意味着"low"与"min"之间的差值，以及"high"与"low"之间的差值都将是内存大小的10%(1000/10000)。

0.1%明显是小了，1T的内存，scale才1GB。

watermark_boost_factor
#

watermark_boost_factor 用于优化内存外碎片化。它临时提高内存管理区的水位，即 zone->watermark_boost 从而提高内存管理区的高水位（ WMARK_HIGH），这样 kswapd 可以回收更多内存，内存规整模块（ compactd 内核线程）就比较容易合并大块的连续物理内存。 watermark_boost_factor 的默认值是 15000，表示会临时把原来的高水位提升到 150%。若把这个值设置为 0，则关闭临时提高内存管理区水位的机制¹²

oom
#

OOM Killer 是内核模块不是一个进程。

参数名称	作用描述	默认值
panic_on_oom	控制OOM发生时系统行为： 0: 不触发panic，启动OOM Killer 1: 触发panic并停机 2: 触发panic后尝试内存释放	0
oom_kill_allocating_task	是否优先杀死触发OOM的进程（而非遍历进程树选择最优目标）： 0: 禁用 1: 启用	0
oom_dump_tasks	OOM发生时是否转储所有任务信息（用于事后分析）： 0: 禁用 1: 启用	1

oom_score
#

oom发生时，系统需要通过oom score决定要kill哪个进程。每个用户进程都有3个oom score接口文件

-rw-r--r-- 1 postgres postgres 0 May 24 16:39 /proc/63766/oom_adj
-r--r--r-- 1 postgres postgres 0 May 24 16:39 /proc/63766/oom_score
-rw-r--r-- 1 postgres postgres 0 May 24 16:39 /proc/63766/oom_score_adj

oom_score是系统自动计算的动态oom分数，至少受以下影响：

很多子进程的 +分
运行很长时间的 -分
low nice value +分 (nice value代表进程的cpu时间片优先级。nice值越低，优先级越高，CPU时间片分配更多)
直接访问硬件的 -分¹³

除了linux自己算的oom分数，还可以自行调整（adj）oom分数。oom_adj是linux内核早期版本的，最好通过调整oom_score_adj接口文件来调整adj score。

参数/文件	作用	示例值
oom_score	内核计算的原始评分（动态变化）	0~1000
oom_score_adj	用户自定义调整值，直接影响最终评分	-1000~1000；-1000等价于禁用OOM
oom_adj（旧版）	旧版调整参数，范围-17~15	-17~15

lowmem_reserve_ratio
#

除了min_free_kbytes，还有一个最低内存保留参数，会可能导致进程申请内存失败，但他们功能有较大差别。

lowmem_reserve_ratio 是一个用于保护低端内存（DMA、DMA32）不被高端内存分配请求过度占用键内核参数。lowmem_reserve_ratio只是一个系数，并不是直接可用的数，内核会计算每个zone的保留页数。

#下面默认值
cat /proc/sys/vm/lowmem_reserve_ratio 
256 256 32

内存区域（zone）按优先级从低到高排列：DMA → DMA32 → Normal → HighMem。高优先级区域的分配请求可“借用”低优先级区域的内存，但需按比例保留一定内存供低优先级区域使用。

cat /proc/zoneinfo |grep -Ew "Node 0|protection|free"
Node 0, zone DMA
 pages free 3976
 protection: (0, 2484, 386430, 386430)
Node 0, zone DMA32
 pages free 415741
 protection: (0, 0, 383946, 383946)
Node 0, zone Normal
 pages free 5658528
 protection: (0, 0, 0, 0)

例如DMA的 protection 表示：

0:本区分配，没有跨区分配的限制
2484：DMA为来自DMA32区域保留的页数。
386430：DMA为来自Normal区域保留的页数
386430：保留扩展字段，此场景中无意义

以上设置

当DMA32区申请DMA区的内存时，3976>2484，是有可能成功的
当Normal区申请DMA区的内存时，3976<386430，是不会成功的
地区向高区申请内存，不会受到该限制

misc
#

还有一丢丢相关的参数，关系不大的没有列举

参数	作用
nr_hugepages	大页数
~~nr_overcommit_hugepages~~	大页的overcommit；The maximum is nr_hugepages + nr_overcommit_hugepages
~~nr_hugepages_mempolicy~~	NUMA本地化大页分配
~~hugetlb_shm_group~~	共享内存权限控制
~~hugetlb_optimize_vmemmap~~	重构大页元数据管理模型，减少大页元数据（struct page）的内存占用。linux 内核5.13开始支持
max_map_count	限制单个进程可拥有的内存映射区域（VMA）的最大数量，默认65530
zone_reclaim_mode	NUMA下内存回收策略，例如从其他节点分配内存
stat_interval	vm stat刷新频率，默认1秒
vfs_cache_pressure	虚拟文件系统（VFS）缓存回收压力的参数，主要影响内核回收dentry、inode缓存的积极性
page-cluster	swap readahead，一次交换多个page到swap分区。默认3，即一次8个pages

OS内存的观测和计算
#

/proc/meminfo，/proc/vmstat，/proc/zoneinfo中都有内存信息，很多信息还是重复的。差异就不列举了没啥意思，看一眼就知道了。

free available的计算（未完成）
#

大体方向：(NR_FREE_PAGES+NR_FILE_PAGES-NR_SHMEM+NR_SWAP_PAGES+NR_SLBA_RECLAIMABLE-TOTALRESERVE_PAGES-root预留内存)

内核有估算可用内存，直接用公式计算available有点难计算出准确的值：

## 不太准确，别用
cat /proc/meminfo |grep -Ew "MemFree|Active\(file\)|Inactive\(file\)|SwapFree|SReclaimable|nr_shmem|Shmem" |awk 'NR==1 {a=$2} NR==2 {b=$2} NR==3 {c=$2} NR==4 {d=$2} NR==5 {e=$2} NR==6 {f=$2 ;print (a+b+c+d-e+f)}' ;
cat /proc/meminfo |grep -Ew "MemAvailable";

inactive_anon+active_anon != anon
#

why？

主要：Shmem 会单独统计共享内存的页数。nr_anon_pages 未包含共享内存页，而 nr_inactive_anon 和 nr_active_anon包含匿名共享内存页
次要：anon包含部分Unevictable （Mlocked又是Unevictable的子集）
其他统计口径差异影响不大

粗糙但比较准确的算法：nr_inactive_anon +nr_active_anon +nr_unevictable -nr_shmem

## 大页下适用；numa下不适用
## /proc/meminfo,/proc/zoneinfo,/proc/vmstat都可以计算

#/proc/vmstat
echo -n "anon_computed : ";cat /proc/vmstat|egrep -w "nr_inactive_anon|nr_active_anon|nr_unevictable|nr_shmem"| awk 'NR==1 {a=$2} NR==2 {b=$2} NR==3 {c=$2} NR==4 {d=$2; print (a+b+c-d)}' ;\
echo -n "anon_real : ";cat /proc/vmstat|egrep -w "nr_anon_pages"|awk '{print $2}'
anon_computed : 15776924
anon_real : 15772671

##/proc/zoneinfo Normal
echo -n "anon_normal_computed : "; cat /proc/zoneinfo |grep Normal -A 50|egrep -w "nr_inactive_anon|nr_active_anon|nr_unevictable|nr_shmem"| awk 'NR==1 {a=$2} NR==2 {b=$2} NR==3 {c=$2} NR==4 {d=$2; print (a+b+c-d)}' ;\
echo -n "anon_normal_real : "; cat /proc/zoneinfo |grep Normal -A 50|egrep -w "nr_anon_pages"|awk '{print $2}'
anon_normal_computed : 15711170
anon_normal_real : 15707402

cache的计算
#

free命令中的buff/cache，可以通过文件页或者cache本身计算出来

echo -n "filepage+shmem: ";cat /proc/meminfo |grep -Ew "Buffers|Active\(file\)|Inactive\(file\)|Shmem|SReclaimable"| awk 'NR==1 {a=$2} NR==2 {b=$2} NR==3 {c=$2} NR==4 {d=$2} NR==5 {e=$2 ;print (a+b+c+d+e)}';\
echo -n "cached: ";cat /proc/meminfo |grep -Ew "Buffers|Cached|SReclaimable" | awk 'NR==1 {a=$2} NR==2 {b=$2} NR==3 {c=$2 ;print (a+b+c)}';\
free -k;

#执行结果：
filepage+shmem: 289417584
cached: 289419156
 total used free shared buff/cache available
Mem: 395721236 79633516 26668564 84704912 289419156 178501152
Swap: 5242876 0 5242876

争议：shmem算不算cache？
#

很明显，上面在计算cache的时候，把shmem也算进去了。shmem理论上应该不属于cache的部分

实际上内核社区也讨论过这个事情Why is Shmem included in Cached in /proc/meminfo?，想把共享内存从cache中抛出去：

> -	cached = global_node_page_state(NR_FILE_PAGES) -
> -			total_swapcache_pages() - i.bufferram;
> +	cached = global_node_page_state(NR_FILE_PAGES) -
> +			total_swapcache_pages()
> +			- i.bufferram - i.sharedram;

但是修改这个东西涉及向前兼容，问题就归结于向前兼容和修改一个信息表达的准确性谁更重要？

目前来看没有一个好的解决，反正现状就是这样了。

这个邮件还讨论到一些有意思的东西：

Another point of view is that everything in tmpfs is part of the page
cache and can be written out to swap

- Dirty: total amount of RAM used to buffer data to be written on
permanent storage (dirty). Gets converted to Cached when write is
complete. (Actually I would call this "Buffers" but Dirty is okay, too.)
- Cached: total amount of RAM used to improve *performance* that can be
*immediately dropped* without any data-loss – note that this includes
all untouched RAM backed by swap.
- Shared: total amount of RAM shared between multiple process that
cannot be freed even if any single process gets killed. (If this is even
possible to know - note that this would *only* contain COW pages in
practice. We already have Committed_AS which is about as good for real
world heuristics.)

cache是不包含dirty的，可以直接drop不会造成数据丢失
tmpfs是swapout

共享内存看上去是swapout，明显跟cache page可以直接drop的性质是不同的。pg的共享内存明显不可以直接drop。

所以对于pg来说，cache有共享内存一点，还是很重要的，不要默认以为没有。

内存页统计数据老对不上
#

计算内存页的时候，有些计算对不上，汇总原因如下：

shmem算到cache中
看不到shmem中的文件映射和匿名映射pages
nr_anon_pages 未包含共享内存页，而 nr_inactive_anon 和 nr_active_anon包含匿名共享内存页
vm和cgroup的统计口径略有差别

cgroup v1
#

cgroup 内存管理
#

cgroup可以观察和限制匿名页，文件页，swap cache，kernel mem的使用情况。每个memcg都有独立的LRU，没有GLOBAL LRU的概念。

cgroup内存管理不同于cgroup cpu管理，1个任务可以申请很多cpu工作，达到cg cpu上线可延长执行时间来处理，但是这个任务占用的内存是工作内存，一个任务使用相同的物理内存。

cgroup管理cpu和内存的重要区别：

内存必须通过复用和回收来管理，一个任务的工作内存是真实占用的不可被其他任务使用的；CPU通过时间分配来管理，其他任务或cg组可以用到
内存需要即时可用，CPU通过时间片轮转，时间可以分散
CPU control的核心是时间分配；Memory Control的核心是page计数

The core of the design is a counter called the page_counter. The page_counter tracks the current memory usage and limit of the group of processes associated with the controller

Memory Control的核心是page计数，也就是说不是物理page分这些就是这些，这次申请的内存使用完后释放回free，下次申请基本上不会是同一个物理page¹⁴。

物理page知道自己属于哪个cgroup：

				+--------------------+
				| mem_cgroup |
				| (page_counter) |
				+--------------------+
				 / ^ \
				/ | \
 +---------------+ | +---------------+
 | mm_struct | |.... | mm_struct |
 | | | | |
 +---------------+ | +---------------+
 |
 + --------------+
 |
 +---------------+ +------+--------+
 | page +----------> page_cgroup|
 | | | |
 +---------------+ +---------------+

mm_struct代表虚拟内存。每个虚拟内存都知道自己属于哪个cgroup；每个物理page都可以指向page_cgroup，即知道这个物理内存属于哪个cgroup¹⁴。

cgroup 参数和指标
#

cgroup通过接口文件配置和查看内存使用情况。

目录：cd /sys/fs/cgroup/memory/xxx/

内核内存和mem+swap可以单独设置或查看使用上限和使用情况：

memory.kmem.xxx #kernel mem
memory.memsw.xxx #mem+swap

以下只看mem相关的。

接口文件可分为三类：

只读-显示使用情况，权限:-r--r--r--
读写-控制参数，权限:-rw-r--r--
其他-特殊设置，权限:其他

具体含义如下，重要参数标出：

type	接口文件	含义
只读	`memory.numa_stat`	numa维度mem stat
只读	`memory.stat`	重要，是主要的内存使用情况接口文件，有很多指标，下面单独分析
只读	`memory.usage_in_bytes`	usage_in_bytes is affected by the method and doesn’t show ’exact’ value of memory。不建议使用该文件查看cgroup的内存使用情况
只读	`memory.failcnt`	内存使用量超过`memory.limit_in_bytes`的次数，累计值
读写	`cgroup.clone_children`	控制子 cgroup 是否继承父级配置
读写	`cgroup.procs`	用于管理当前 cgroup 中的进程组（进程 ID，PID）。对于多进程的pg来说，就是把pg的所有进程，包括管理进程和backend都写入`procs`文件
读写	`tasks`	用于管理当前 cgroup 中的线程（线程 ID，TID）。将进程 PID 写入 `cgroup.procs` 时，其所有线程 TID 会自动添加到 `tasks`
读写	`notify_on_release`	控制当 cgroup 中的最后一个任务（进程或线程）退出时，是否触发释放操作。容器管理才有可能打开，传统的cgroup管理默认都是关闭，数据库重启cgroup还是要保留的
读写	memory.move_charge_at_immigrate	v2已启用该参数。迁移croup时charge归属规则
读写	memory.use_hierarchy	父cgroup是否限制子cgroup
读写	memory.limit_in_bytes	cgroup内存上限
读写	memory.soft_limit_in_bytes	内存超限时回收超限的部分
读写	memory.max_usage_in_bytes	cgroup使用峰值，属于观察指标
读写	memory.oom_control	oom_kill_disable 1–禁用oom under_oom 0是否处于OOM状态
读写	memory.swappiness	cg级别的swappiness
其他	memory.force_empty	仅写入，写入 `0` 强制释放cgroup所有内存
其他	cgroup.event_control	事件通知接口，监听内存压力事件，需编程实现。常与memory.pressure_level配合使用
其他	memory.pressure_level	内存压力通知级别

通过一个pg实例来看memory.stat中各个指标的含义。

这个pg实例配置为：

shared_memory_type=mmap
shared_buffers=64GB
clients 800个左右，running

cat memory.stat

cache 345587761152 						 #page cache！！！
rss 27332608 #匿名和swap cache内存大小，注意，跟OS的进程rss不同，这里明显不包含PG的共享内存
rss_huge 0 #of bytes of anonymous transparent hugepages，注意是匿名大页
mapped_file 61491769344 # 文件共享内存大小，这里包含pg的共享内存
swap 0 # swap分区上的
pgpgin 389395357 # rss+cache的charge pages
pgpgout 305016672 # rss+cache的uncharge pages
pgfault 1954040341 # 略
pgmajfault 17 # 略
inactive_anon 165728256 # anonymous and swap cache memory on inactive LRU
active_anon 61549518848 # anonymous and swap cache memory on active LRU list
inactive_file 138240962560 # file-backed on inactive LRU list
active_file 145658613760 # file-backed memory on active LRU list
unevictable 0 # 无法回收的内存
hierarchical_memory_limit 408021893120 #
hierarchical_memsw_limit 9223372036854771712 #
total_xxx # hierarchical 

粗略来看（不看swap）cache+rss=inactive_anon+active_anon+inactive_file+active_file。

这上面的值还挺绕的，cache+rss跟[in]active_anon/file也难有直接对应关系，再加上mapped_file这个共享内存不知道该算到哪去，容易算晕。结合各种文档和测试，手搓脚本如下：

#cginfo_lzl
echo -n "shared_mem_mapped : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.stat|egrep -w "mapped_file"| awk '{print $2 / 1024 / 1024 /1024 }' ;\
echo -n "shared_mem_anon : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.stat|egrep -w "rss|inactive_anon|active_anon"| awk 'NR==1 {a=$2} NR==2 {b=$2} NR==3 {c=$2; print (b + c -a)/1024/1024/1024}' ;\
echo -n "pagecache : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.stat|egrep -w "cache"| awk '{print $2 / 1024 / 1024 /1024 }' ;\
echo -n "pagecache_cache-share : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.stat|egrep -w "cache|mapped_file"| awk 'NR==1 {a=$2} NR==2 {b=$2; print (a - b)/1024/1024/1024}';\
echo -n "file_total : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.stat|egrep -w "inactive_file|active_file"| awk '{sum += $2} END {print sum /1024/1024/1024}';\
echo -n "anon_total : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.stat|egrep -w "inactive_anon|active_anon"| awk '{sum += $2} END {print sum /1024/1024/1024}';\
echo -n "total_used_rss+map : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.stat|egrep -w "rss|mapped_file"| awk '{sum += $2} END {print sum /1024/1024/1024}';\
echo -n "total_mem_file+rss+map : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.stat|egrep -w "inactive_file|active_file|rss|mapped_file"| awk '{sum += $2} END {print sum /1024/1024/1024}';\
echo -n "total_mem_rss+cache : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.stat|egrep -w "rss|cache"| awk '{sum += $2} END {print sum /1024/1024/1024}';\
echo -n "total_mem_anon+file : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.stat|egrep -w "inactive_file|active_file|inactive_anon|active_anon"| awk '{sum += $2} END {print sum /1024/1024/1024}';\
echo -n "total_memsw : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.stat|egrep -w "rss|cache|swap"| awk '{sum += $2} END {print sum /1024/1024/1024}';\
echo -n "hard_limit : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.limit_in_bytes| awk '{print $1 / 1024 / 1024 /1024 }'

#shared_buffers=2GB的库
shared_mem_mapped : 1.69063
shared_mem_anon : 1.69828
pagecache : 5.94717
pagecache_cache-share : 4.25654
file_cache : 4.24889
anon_cache : 3.23096
total_used_rss+map : 3.2233
total_mem_file+rss+map : 7.47219
total_mem_rss+cache : 7.47984
total_mem_anon+file : 7.47984
total_memsw : 7.47984
hard_limit : 8

cgroup rss和process rss的差异
#

#shared_buffers= 64GB,所有pg进程的rss排序
ps -eo pid,ppid,rss,args |grep `cat $PGDATA/postmaster.pid|head -1`|sort -k3 -rn
 97632 97627 61103720 postgres: lzlinst: checkpointer 
 97633 97627 59045152 postgres: lzlinst: background writer 
 97627 1 2322820 /paic/postgres/base/11.3/bin/postgres -D /paic/pg6888/data
 97637 97627 85116 postgres: lzlinst: pgsentinel 
 97697 97627 19620 postgres: lzlinst: dbmgr users [local] idle
 97634 97627 17932 postgres: lzlinst: walwriter 
250063 97627 14508 postgres: lzlinst: dbmon postgres [local] idle
 97636 97627 13220 postgres: lzlinst: stats collector 
248777 97627 11576 postgres: lzlinst: dbmon postgres [local] idle
 97635 97627 2980 postgres: lzlinst: autovacuum launcher 
 97638 97627 2376 postgres: lzlinst: logical replication launcher 
 97630 97627 1592 postgres: lzlinst: logger 
250185 39130 972 grep --color=auto 97627

一般来说，pg rss值最多的是checkpointer和bgwriter进程，因为rss代表的真实使用的内存，含共享内存部分，这2个要刷shared buffer脏页的进程占用最多。也有查数据过多的backend也可能rss值较高，不过一般是抽数或者全表扫的慢sql导致。

postmaster为什么很少？因为postmaster本身不需要做太多shared_buffer的操作，它只需要把共享内存的虚拟地址开辟下来，fork给其他进程用即可。

pm的子进程的共享内存地址是相同的，rss就不一定了：

$ cat /proc/97632/smaps |grep -A 3 "zero" #checkpointer
2b4fd87cf000-2b60a2143000 rw-s 00000000 00:04 15925397 /dev/zero (deleted)
Size: 70411728 kB
Rss: 61087812 kB
Pss: 31429895 kB
$ cat /proc/97633/smaps |grep -A 3 "zero" #bgwriter
2b4fd87cf000-2b60a2143000 rw-s 00000000 00:04 15925397 /dev/zero (deleted)
Size: 70411728 kB
Rss: 59043388 kB
Pss: 29394787 kB
$ cat /proc/97627/smaps |grep -A 3 "zero" #postmaster
2b4fd87cf000-2b60a2143000 rw-s 00000000 00:04 15925397 /dev/zero (deleted)
Size: 70411728 kB
Rss: 2318408 kB
Pss: 1741764 kB

以上checkpointer和bgwriter占用最多的rss，且rss中大部分是共享内存。它们两个进程几乎平分了整个真实使用的共享内存，postmaster反倒使用不多。pm及其fork的所有子进程的共享内存的虚拟地址是相同的。

但是，cgroup中的rss只有几十MB，远小于进程的rss

cat /sys/fs/cgroup/memory/lzlinst/memory.stat |egrep -w "rss|mapped_file"
rss 88997888
mapped_file 52963262464

可以看出来，pg共享内存没有在cgroup stat rss的统计中。cgroup的rss没有计算file page以及shared file page。

linux kernel¹⁴:

Only anonymous and swap cache memory is listed as part of ‘rss’ stat. This should not be confused with the true ‘resident set size’ or the amount of physical memory used by the cgroup.

进程和cgroup内存统计差异¹⁵：

内存	单进程	进程`cgroup(memcg)`
`cache`	无	`PageCache`
`mapped_file`	无	`file_rss + shmem_rss`
`RSS`	`anon_rss + file_rss ＋ shmem_rss`	`anon_rss`

对于pg来说，stat中的rss不包含file map共享内存。pg官网把mmap描述为anonymous shared mem：

Possible values are mmap (for anonymous shared memory allocated using mmap), sysv (for System V shared memory allocated via shmget)

cg把pg mmap的内存算成mapped_file。

观察sysv和大页的情况，pg的memory.stat相关指标总结：

stat中的rss不包含file map共享内存。观察来看，无论是mmap还是sysv，rss都不含pg的共享内存
同理，rss_huge也不含file map共享大页内存。观察来看，即便开启大页，stat也不含pg的共享内存
无大页时，pg的共享内存（mmap or sysv）均统计在memory.stat mapped_file下；有大页时，不在stat中的任何指标中，包括rss_huge

mapped_file到底在哪里？
#

mapped_file在cache中，也在inactive_anon+active_anon中
mapped_file也可以是匿名的，mmap/sysv都算在这里

#shared_buffers=2GB的库
shared_mem_mapped : 1.69063
shared_mem_anon : 1.69828
pagecache : 5.94717
pagecache_cache-share : 4.25654
file_cache : 4.24889
anon_cache : 3.23096
total_used_rss+map : 3.2233
total_mem_file+rss+map : 7.47219
total_mem_rss+cache : 7.47984
total_mem_anon+file : 7.47984
total_memsw : 7.47984
hard_limit : 8

soft_limit_in_bytes
#

软限制（memory.soft_limit_in_bytes）是 cgroup 内存管理中的一种非强制约束。当 cgroup 的内存使用量超过软限制时，系统不会立即强制回收内存，而是会在 全局内存压力较大时（例如系统整体内存紧张）优先回收该 cgroup 的超额内存。

触发条件：全局内存压力（例如系统空闲内存不足）。
调用路径：kswapd → balance_pgdat → 检查 cgroup 软限制 → 触发回收。
回收目标：优先回收超出软限制的 cgroup 的内存页面。

+-------------------+ 全局内存压力检测 +-------------------+
| kswapd 线程 | ---------------------> | balance_pgdat |
+-------------------+ +-------------------+
 |
 | 遍历内存区域并检查
 v
 +---------------------------+
 | 检查各 cgroup 的软限制使用情况 |
 +---------------------------+
 |
 | 对超限 cgroup 触发回收
 v
 +---------------------------+
 | 页面回收（LRU 链表扫描等） |
 +---------------------------+

soft_limit_in_bytes机制很像high，v2的soft_limit_in_bytes已过期，新增min、low、high三个参数。

超卖对pagecache的影响
#

再说

cg oom
#

正常来说，sharedbuffer=1/4的cg mem，那么在不计算私有内存的情况下，pagecache最大可以到3/4的cg mem。一般来说，正常的业务私有内存占用不会很多，如果cg mem打满是可以从cg pagecache中回收内存的（是直接内存回收，aliOS做了异步后台回收：Memcg后台异步回收内存）。所以测试cg oom最好的办法是用占用很多私有内存的会话而不是加压。

测试用例：

#观察score
-r--r--r-- 1 postgres postgres 0 May 24 16:39 /proc/63766/oom_score
rss # 随便哪个命令啦

## 一个可以占用很多私有内存的sql，很多union all有很多plan node
psql -d lzldb -tX -c "create table lzl1(col1 varchar(1));"
psql -tX -c "\o sqltext.sql" -c "
SELECT 'select col1 from lzl1' || ' union all'
FROM generate_series(1, 100000)
UNION ALL
SELECT 'select col1 from lzl1;'
FROM generate_series(1, 1);
" 

#调整stack参数不然sql会被掐掉
psql -d lzldb -c "set max_stack_depth=1024000" -f sqltext.sql

cg oom off:

wchan有oom信息，甚至有oom score，但不会被OOM killer干掉

## vm oom打开; 0:不触发panic，启动OOM Killer
$ cat /proc/sys/vm/panic_on_oom 
0

## cg oom关闭;1:禁用oom
$ cat /sys/fs/cgroup/memory/$PGNAME/memory.oom_control
oom_kill_disable 1
under_oom 0


$ ps -eo user,ppid,pid,state,%cpu,%mem,stime,wchan:14,args,rss,vsz,sig_block |grep `head -1 $PGDATA/postmaster.pid` |grep -v grep 
postgres 19005 870 D 0.0 0.0 10:54 mem_cgroup_oom postgres: pg3ymhp2: lzluser 7216 2807460 0000000000000000
postgres 19005 3417 S 0.0 0.0 10:55 pipe_wait postgres: pg3ymhp2: lzluser 22944 2808540 0000000000000000
postgres 19005 13069 D 0.0 0.0 11:10 mem_cgroup_oom postgres: pg3ymhp2: lzluser 11944 2808348 0000000000000000
postgres 19005 13104 D 0.0 0.0 11:10 mem_cgroup_oom postgres: pg3ymhp2: lzluser 12224 2808348 0000000000000000
postgres 19005 14352 D 0.0 0.0 11:10 mem_cgroup_oom postgres: pg3ymhp2: lzluser 11680 2808348 0000000000000000

cat /sys/fs/cgroup/memory/$PGNAME/memory.oom_control
oom_kill_disable 1
under_oom 1

cat /proc/97994/oom_score
11

shared_mem_mapped : 2.00019
shared_mem_anon : 2.0023
pagecache : 2.0023
pagecache_cache-share : 0.00211334
file_cache : 0
anon_cache : 8
total_used_rss+map : 7.99789
total_mem_file+rss+map : 7.99789
total_mem_rss+cache : 8
total_mem_anon+file : 8
total_memsw : 8
hard_limit : 8

目前看来，PG的进程在分配不到内存的时候也有可能跑崩，例如walwriter跑奔溃会导致其他进程都崩溃。

cg oom on：

用户进程因为oom score高而被kill，发送的是kill -9，pg绝大部分进程奔溃，postmaster reset_shared()后自动拉起其他进程。mesage和dmesg都有out of memory相关信息：

#cg oom打开
oom_kill_disable 0

pg log:
2025-05-29 19:10:45.945 CST,,,198877,,6838374d.308dd,4,,2025-05-29 18:30:37 CST,,0,LOG,00000,"server process (PID 236413) was terminated by signal 9: Killed","Failed process was running: select col1 from lzl1 union all

message:
May 29 19:10:45 lzlhost kernel: Memory cgroup stats for /t1lzldb: cache:8392988KB rss:8384228KB rss_huge:0KB mapped_file:7458316KB swap:0KB inactive_anon:1310184KB active_anon:15467032KB inactive_file:0KB active_file:0KB unevictable:0KB
May 29 19:10:45 lzlhost kernel: Memory cgroup out of memory: Kill process 236413 (postgres) score 497 or sacrifice child

dmesg:
[Thu May 29 18:26:27 2025] Memory cgroup stats for /t1lzldb: cache:8392988KB rss:8384228KB rss_huge:0KB mapped_file:7458316KB swap:0KB inactive_anon:1310184KB active_anon:15467032KB inactive_file:0KB active_file:0KB unevictable:0KB
[Thu May 29 18:26:27 2025] Memory cgroup out of memory: Kill process 236413 (postgres) score 497 or sacrifice child
[Thu May 29 18:26:27 2025] Killed process 236413 (postgres) total-vm:18828736kB, anon-rss:8328252kB, file-rss:2328kB, shmem-rss:1832kB

cg oom on和off对于pg库管理上的区别：

on，cg oom killer会kill oom score高的进程，一般来说是用户进程
off，cg oom killer不会启动。pg进程会hang，当然也可能自己恢复，但pg的关键进程（如walwriter）可能因内存不足而跑崩，实例一样可能挂掉。

注意这里说的cg oom，不是vm oom。系统级的vm oom由系统级的vm overcommit机制来判断。

cg v1的问题
#

没有统计cg pagetable
没有统计cg slab
没有统计cg hugepage（hugepage是没有charge，还不是没有算进去）
没有统计cg异步、同步回收pages
cg rss与process rss统计口径不统一
shmem统计口径比较乱

what’ new in V2
#

V2 Officially released in Linux 4.5 (March 2016)¹⁶。

cgroup v2内存管理的提升和改变：¹⁷

cg mem接口文件	对比v1	含义
memory.current	重修	当前使用内存大小。移除没什么用的usage_in_bytes
memory.min	新增	跟vm的min/low/high不同。vm的水位线是操作系统剩的内存，cg v2的水位线是cg mem使用的内存。memory.min为硬保护内存保护值，默认值为0。系统没有可回收内存的时候，也不会回收在该值边界及以下的内存¹⁸
memory.low	新增	尽力而为的内存保护值，默认值为0。系统优先回收未被保护的cgroup组的内存。如果内存还不足，再回收memory.min到memory.low之间的内存。
memory.high	新增	内存回收警示值，默认为max。当cgroup组内存使用量达到high值，会触发对该cgroup及子节点的同步内存回收任务，将内存尽量限制在high之下
memory.max	重修	等价memory.limit_in_bytes
memory.reclaim	重修	主动回收接口文件，v1只有memory.force_empty强制清空
memory.peak	重修	等价max_usage_in_bytes；超过peak会触发cg oom killer
memory.oom.group	新增	控制 cg OOM killer时是否终止整个 cgroup（1）或仅单个进程（0）。默认为0.如果oom_score_adj=-1000，不会被kill
memory.events	新增	报告内存相关事件
memory.stat	重修	改变较多，单独分析
memory.zswap.current，memory.zswap.max，memory.zswap.writeback	新增	Zswap 是 Linux 内核中的一种内存压缩交换机制，通过压缩待交换的内存页，减少对磁盘的 I/O 操作，从而提升系统性能。其核心思想是将原本需要写入磁盘的交换数据压缩后暂存于内存中，仅在必要时才将数据写入物理交换设备（如 Swap 分区或文件）
soft_limit_in_bytes	移除
memory.oom_control	移除	代表v2无法直接关闭cg oom killer；不过可以通过设置min/low/high和设置event内存事件通知等来精细化管理内存

v2 cg mem在管理上有如下优势：

相对v1，v2有更简单明了的层级管理
v1只有OOM kill or freeze，v2有更多手段控制内存大小(如memory.min/low/high)
v2更容易控制突刺负载¹⁹
移除直接关闭cg oom killer的接口文件
增加memory_hugetlb_accounting

memory.stat：

参数	含义	v1 对应项
anon	匿名页	active_anon+inactive_anon
file	文件页，含 tmpfs	active_file+inactive_file
kernel (npn)	总内核内存，包括kernel_stack, pagetables, percpu, vmalloc, slab以及其他内核内存的使用情况。	新增
kernel_stack	kernel stacks占用的内存量。	新增
pagetables	page tables	新增
sec_pagetables	二级页表，适合虚拟机、GPU 设备、网络加速卡等硬件资源隔离场景	新增
percpu (npn)	存储per-cpu内核数据结构的内存大小	新增
sock (npn)	network transmission buffers	新增
vmalloc (npn)	vmalloc	新增
shmem	b包括tmpfs, shm , shared anonymous mmap	新增
zswap	zswap压缩本身消耗的内存	新增
zswapped	zswap了多少用户内存	新增
file_mapped	mmap()大小	有点类似v1 mapped_file，不过mapped_file包含tmpfs、shm
file_dirty		同v1 dirty
file_writeback		同v1 writeback
swapcached		同v1 swapcached
anon_thp	透明大页中的匿名页	新增
file_thp	透明大页中的文件页	新增
shmem_thp	透明大页的shm、tpfs、匿名mmap	新增
inactive_anon, active_anon, inactive_file, active_file, unevictable		同v1
slab_reclaimable	意如其名	新增
slab_unreclaimable	意如其名	新增
slab (npn)	意如其名	新增
workingset_refault_anon，workingset_refault_file，workingset_activate_anon，workingset_activate_file，workingset_restore_anon，workingset_restore_file，workingset_nodereclaim	refaulted相关page统计	新增
pswpin (npn)	swap in	同v1 pgpgin
pswpout (npn)	swap out	同v1 pgpgout
pgscan (npn)	scanned pages (in an inactive LRU list)	新增
pgsteal (npn)	回收的内存	新增
pgscan_kswapd (npn)	意如其名	新增
pgscan_direct (npn)	意如其名	新增
pgscan_khugepaged (npn)	透明大页守护进程扫描的pages	新增
pgscan_proactive (npn)	proactive主动扫描的pages	新增
pgsteal_kswapd (npn)，pgsteal_direct (npn)，pgsteal_khugepaged (npn)，pgsteal_proactive (npn)	意如其名，pgsteal对应pgscan	新增
pgfault (npn)	意如其名	同v1 pgfault
pgmajfault (npn)	意如其名	同v1 pgmajfault
pgrefill (npn)	在active LRU中扫描的pages	新增
pgactivate (npn)	移动到active LRU中的pages	新增
pgdeactivate (npn)	移动到inactive LRU中的pages	新增
pglazyfree (npn)	有内存压力时，推迟释放的pages	新增
pglazyfreed (npn)	已回收的lazyfree pages	新增
swpin_zero,swpout_zero	zero-filled pages；在Swap In 阶段，内核检测到页面内容全为零（Zero-filled），标记该页为“零页”并记录在元数据中，跳过磁盘 I/O 操作	新增
zswpin,zswpout,zswpwb	zswap相关pages	新增
thp_fault_alloc (npn)，thp_collapse_alloc (npn)，thp_swpout (npn)，thp_swpout_fallback (npn)	透明大页相关pages	新增
numa_pages_migrated (npn)，numa_pte_updates (npn)，numa_hint_faults (npn)	numa相关pages，其实还有memory.numa_stat	新增
pgdemote_kswapd，pgdemote_direct，pgdemote_khugepaged，pgdemote_proactive	没懂demote	新增
hugetlb	大页	新增

v2 cg mem在观测上有如下优势：

新增slab、pagetable、pgscank/pgsand/pgsteal、大页信息，这些都是v1没有的
更多具体特性相关的观测指标，比如sock 、vmalloc、透明大页、zswap压缩交互、swap_zero全零交互等
共享内存shmem和file_mapped指标分开

wchan
#

Waiting Channel，name of the kernel function in which the process is sleeping

一般来说要检查D状态的进程的wchan，看看进程在等待什么内核函数。

-：Running tasks will display a dash (’-’) in this column

poll_schedule_timeout: PM常见，-一般在运行状态

zz ***Fri May 2 04:50:10 CST 2025
postgres 141378 1 19 0.5 0.4 70585180 2322876 poll_schedule_timeout S 21:06:18 00:02:40 /paic/postgres/base/11.3/bin/postgres -D /paic/pg6888/data
zzz ***Fri May 2 04:50:43 CST 2025
postgres 141378 1 19 0.5 0.4 70585180 2322876 - R 21:06:18 00:02:42 /paic/postgres/base/11.3/bin/postgres -D /paic/pg6888/data

futex_wait_queue_me: SLEEP进程常见。偶现D

postgres 455358 141378 19 4.7 1.0 70590684 5349576 futex_wait_queue_me S 03:01:12 00:02:47 postgres: t1lzldb: lzl test3 30.181.32.3(39801) COMMIT

hugetlb_fault：只见过hugepage刚加载，刚起负载时

do_last：虚拟文件系统（VFS）路径解析逻辑中的函数，负责处理文件路径的最后一个分量（如文件名或符号链接），并触发实际的文件操作

lock_page_killable：以可中断方式锁定物理内存页；可中断性是说允许进程在等待页面锁时响应致命信号，如SIGKILL

rpc_wait_bit_killable：该函数与远程过程调用（RPC）机制相关，用于在内核中等待某个位标志的变更

wait_on_page_bit：等待页面标志位的状态变更（如PG_locked、PG_writeback）

blkdev_issue_flush：块设备层的刷新缓存函数；可能的调用链：用户调用fsync() → 文件系统（如ext4）将相关脏页提交至块设备层 → 调用blkdev_issue_flush()确保设备缓存刷新

on_proc_exit：注册进程退出时的清理函数

ima_file_check：属于IMA（Integrity Measurement Architecture）子系统，用于在文件访问时验证其完整性；典型的有open()调用

flush_work：等待任务完成

call_rwsem_down_write_failed：当尝试获取写锁（down_write()）失败时，此函数处理写锁竞争与等待逻辑。它通过自旋或睡眠机制让当前进程等待锁释放（rwsem（读写信号量））

get_request ：iowait高时出现；从块设备请求队列中获取空闲的请求结构体（struct request）。若队列已满（设备处理速度不足），线程将等待直至有可用请求

lookup_slow：VFS（虚拟文件系统）路径解析的慢速路径

/**
 * lookup_fast - do fast lockless (but racy) lookup of a dentry
 * @nd: current nameidata
 *
 * Do a fast, but racy lookup in the dcache for the given dentry, and
 * revalidate it. Returns a valid dentry pointer or NULL if one wasn't
 * found. On error, an ERR_PTR will be returned.
 */
 static struct dentry *lookup_fast(struct nameidata *nd)

/* Fast lookup failed, do it the slow way */
static struct dentry *__lookup_slow(const struct qstr *name,
				 struct dentry *dir,
				 unsigned int flags)

static struct dentry *lookup_slow(const struct qstr *name,
				 struct dentry *dir,
				 unsigned int flags)
{
	struct inode *inode = dir->d_inode;
	struct dentry *res;
	inode_lock_shared(inode);
	res = __lookup_slow(name, dir, flags);
	inode_unlock_shared(inode);
	return res;
}

lookup_fast和lookup_slow都是在找dentry并返回dentry，lookup_fast会在dentry cache中寻找，如果失败会通过lookup_slow查找。

开大页压测，无直接内存回收，出现以下事件：

lock_page：iowait高时出现；内核尝试锁定一个内存页时，若页面已被其他线程/进程锁定，当前线程会进入等待状态。

vx_svar_sleep_unlock，vx_ilock，vx_bc_biowait，vx_dio_physio，vx_rwsleep_lock：

vx是Veritas 公司开发的日志型文件系统（现归属于 Symantec 及后续拆分后的 Veritas Technologies），设计目标为高性能、高可用性的大规模数据存储，主要面向企业级应用场景。跟xfs、ext4一样是一种文件系统。

pipe_wait：当进程尝试从管道（Pipe）读取数据或向管道写入数据时，若管道缓冲区已满（写操作）或已空（读操作），当前线程会进入休眠状态，等待缓冲区状态变化

pipe_write：管道写操作的入口函数，当缓冲区满时，线程在此函数中休眠，等待可写空间

congestion_wait：当块设备 I/O 队列拥塞时（如请求队列已满或设备处理延迟），内核通过此函数让线程短暂休眠

wait_iff_congested：检查块设备队列是否拥塞，若拥塞则进入短暂休眠。与 congestion_wait 类似，但更轻量级，通常用于内存回收或脏页回写路径

mem_cgroup_oom_synchronize：usage_in_bytes达到limit_in_bytes时，标记oom_control.under_oom=1，是否启用OOM killer内核模块取决于oom_control.oom_kill_disable

mem_cgroup_oom:同mem_cgroup_oom_synchronize

rmap_walk
#

PFRA目标之一是为了回收共享页框，为了达到这个目的，Linux 2.6内核能够快速定位指向同一页框的所有页表项，这个过程叫反向映射（reverse mapping）¹。

当已被一个进程引用的页框插入另一个进程的页表项（fork）时，应该也会发生rmap_walk

zcat hostlzl_ps_25.04.08.0900.dat.gz|egrep "\-D /dirlzl/pg5998/data|zzz"|less
zzz ***Tue Apr 8 09:10:50 CST 2025
postgres 209987 1 19 0.2 0.5 70247548 2117844 poll_schedule_timeout S 22:17:21 00:01:56 /dirlzl/postgres/base/postgressql/bin/postgresdb -D /dirlzl/pg5998/data
zzz ***Tue Apr 8 09:11:20 CST 2025
postgres 209987 1 19 0.2 0.5 70247548 2117844 poll_schedule_timeout S 22:17:21 00:01:56 /dirlzl/postgres/base/postgressql/bin/postgresdb -D /dirlzl/pg5998/data
zzz ***Tue Apr 8 09:13:08 CST 2025
postgres 209987 1 19 0.2 0.5 70247548 2117844 - D 22:17:21 00:01:57 /dirlzl/postgres/base/postgressql/bin/postgresdb -D /dirlzl/pg5998/data
postgres 225076 209987 19 1.6 0.0 70247548 1720 rmap_walk D 09:11:51 00:00:01 /dirlzl/postgres/base/postgressql/bin/postgresdb -D /dirlzl/pg5998/data
postgres 224924 209987 19 0.7 0.0 70247548 1728 rmap_walk D 09:11:46 00:00:00 /dirlzl/postgres/base/postgressql/bin/postgresdb -D /dirlzl/pg5998/data
postgres 224817 209987 19 0.5 0.0 70247548 1720 try_to_unmap_file D 09:11:44 00:00:00 /dirlzl/postgres/base/postgressql/bin/postgresdb -D /dirlzl/pg5998/data
zzz ***Tue Apr 8 09:19:16 CST 2025
postgres 209987 1 19 0.3 0.5 70247548 2117884 poll_schedule_timeout S 22:17:21 00:02:00 /dirlzl/postgres/base/postgressql/bin/postgresdb -D /dirlzl/pg5998/data
postgres 250875 209987 19 0.0 0.0 70247548 2208 - R 09:19:17 00:00:00 /dirlzl/postgres/base/postgressqlbin/postgresdb -D /dirlzl/pg5998/data
zzz ***Tue Apr 8 09:19:48 CST 2025
postgres 209987 1 19 0.3 0.5 70247548 2117884 poll_schedule_timeout S 22:17:21 00:02:01 /dirlzl/postgres/base/postgressql/bin/postgresdb -D /dirlzl/pg5998/data

try_to_unmap_file
#

try_to_unmap_file()函数调用try_to_unmap_cluster()，而try_to_unmap_cluster()函数会扫描该线性区线性地址所对应的所有页表项，并尝试将他们清理¹。try_to_unmap_file()执行映射页的反向映射。注意，反向映射即通过pagetable反向寻找所有vma，并将共享物理页框回收。

page_referenced
#

refenced和active用于控制page的活跃度，在页面回收中使用。refcount=0时表示空闲或即将要被释放的页面⁵。

在kernel.org doc的Object-Based Reverse Mapping中有对page_referenced()函数的描述[^ kernel.org, Page Table Management]：

page_referenced() which checks all PTEs that map a page to see if the page has been referenced recently

page_referenced() calls page_referenced_obj() which is the top level function for finding all PTEs within VMAs that map the page.

If a page is mapped and it is referenced through the mapping, index hash table, this bit is set. It is used during page replacement for moving the page around the LRU lists

简言之，page_referenced()通过页框找到map的所有PTEs上的VMAs。这也是一个rmap的过程。

Linux 引入了两个页面标志符 PG_active 和 PG_referenced 用于标识页面的活跃程度，从而决定如何在两个链表（active LRU和inactive LRU）之间移动页面。

PG_active 用于表示页面当前是否是活跃的，如果该位被置位，则表示该页面是活跃的。PG_referenced 用于表示页面最近是否被访问过，每次页面被访问，该位都会被置位。

page_referenced()：当操作系统进行页面回收时，每扫描到一个页面，就会调用该函数设置页面的 PG_referenced 位。如果一个页面的 PG_referenced 位被置位，但是在一定时间内该页面没有被再次访问，那么该页面的 PG_referenced 位会被清除。²⁰。

内存观察指标
#

查看基本内存设置：

观察内存指标：

一些问题
#

kswapd和直接内存回收是否会一起执行？
#

会。如果是水位线触发的内存回收，有pgscand时经常伴随pgscank，反之则不然。如果pgscank、pgscand均频繁，那么可以考虑调整内存回收水位线，调大delta，防止delta被快速冲破。

不过还有一种情况，碎片率较高的时候，free还有很多，也有可能直接触发阻塞式内存压缩，有pgscand，完全没有pgscank。此时调整水位线就没有什么用了，可以考虑开启大页内存并提升一定的sharedbuffer命中率，减少pagecache频繁分配切碎内存。

pagetable过大对内存回收的影响
#

pagetable过大，会增加反向映射的代价和时间。在直接内存回收时需要通过反向映射，找到所有进程的虚拟地址空间VMA，然后取消所有进程的VMA页表映射。也就说进程数越多，pagetable越大，内存回收也就越慢。

postgres的进程数越多，pagetable越大；shared buffer越大，pagetable也越大。

开启大页内存可以减少500倍（4k=>2M）pagetable大小，不仅可以空出一定内存，也可以提升内存回收效率。

shared buffers多大合适
#

sharedbuffers=1/4 cgmem 似乎以成为行业标准，但是实际情况要复杂的多。理论上，把sharedbuffers调小可以增加一点pagecache，实际上略微增大了整个缓存大小，把sharedbuffers调大略微减少了减少了整个缓存大小，但是提升了一定的sharedbuffer命中率。很明显，sharedbuffers调大了不好，调小了也不好。sharedbuffers调太小，pg自己能工作的内存就太小了，相当于把内存管理工作扔给了OS，OS回收pagecache时对性能也会有影响；sharedbuffers调太大，不仅pagecache被挤占，还需要考虑pg刷脏的影响，特别是写入较多的情况需要调整相应的bgwriter参数。

从粗糙的压测来看

不开大页，shared buffers=min(1/4 MEM,20GB)
开大页，shared buffers=min(1/4 MEM,60GB)

进程和线程的差别真的不大吗？
#

在任何linux内核资料中，都会说进程和线程的差别不大。无论是创建进程还是线程，内核中都是用同一个函数kernel_clone来实现的，唯一区别在于传入的参数不同，fork和clone的系统调用差不多³：

维度	进程	线程
childID	每个进程都有独立的 `pid`（进程 ID）	每个线程有 `tid`（线程 ID），但线程的 pid`与所属进程的`pid` 一致。
地址空间	每个进程拥有独立的地址空间（`mm_struct`），包括内存、堆栈等。	线程共享所属进程的地址空间，所有线程的 `mm_struct` 指向同一个地址空间。
文件系统	每个进程有自己的 `fs_struct`，包含文件描述符、挂载点等。	线程共享所属进程的 `fs_struct`，所有线程的文件描述符和挂载点与进程一致。

线程跟进程相比，只是稍微“轻量”了一点，总体来说进程和线程的相同点大于他们的不同点。

但是，进程多了以后区别可就大了，特别是像pg这样的多进程应用：

每个进程都有自己的VMA，所以要维护更多的地址空间
每个进程都有自己的pagetable，所以pagetable要占用更多的内存
多进程会增加TLB的刷新负担，而线程不会
进程切换需要更多的上下文开销，而线程不会
进程间通信IPC效率更低，而线程直接共享内存不会有IPC通信问题

可以这么说，进程和线程在创建的时候差别不大，但是多进程管理和多线程管理差别很大。

为什么从库会有pg层脏页？
#

从库日志回放机制本身会产生脏页，从库也会刷脏。可通过pg_buffercache查看从库脏页，从库的脏页跟主库不一样，从库脏数据也是一般的relation；同时可以观察到从库的checkpoint/bgwriter/backend刷脏都跟主库不一样。

为什么file cache有些库高有些低
#

一般来说是离散度多的库file cache比较多，简单的慢sql是比较难把file cache长期维持在较高水平的。一个慢sql访问较多数据，可能会短暂的升高filecache，但是过一会这些file page的reference下降，并成为inactive file pages后，内存可以回收这一部分内存。但是频繁的离散度，比如索引的correlation接近0，如UUID主键，其SQL性能较好但reads高，可能产生频繁物理IO，加载了太多的page到filecache中。甚至业务模型的转变会导致shared buffer的大量换入换出，对性能影响较大。

pg进程和共享内存映射
#

#未开大页时，是/dev/zero （deleted）
cat /proc/102208/smaps |egrep "rw\-s" -A 1
2aefd8901000-2aefd8902000 rw-s 00000000 00:04 1202061313 /SYSV00001000 (deleted)
Size: 4 kB
--
2aefd8918000-2aefd898f000 rw-s 00000000 00:13 4084862058 /dev/shm/PostgreSQL.1008001451
Size: 476 kB
--
2aefe2605000-2b00ad129000 rw-s 00000000 00:04 4084864418 /dev/zero (deleted)

#开启大页时，是/anon_hugepage (deleted)
cat /proc/29091/smaps |egrep "rw\-s" -A 1
2aaaaac00000-2ac3a2c00000 rw-s 00000000 00:0e 215471503 /anon_hugepage (deleted)
Size: 104726528 kB
--
2b48dfe93000-2b48dfe94000 rw-s 00000000 00:04 88604727 /SYSV00001000 (deleted)
Size: 4 kB
--
2b48dfeab000-2b48dff22000 rw-s 00000000 00:12 215515747 /dev/shm/PostgreSQL.1123685558
Size: 476 kB

子进程页表都是从父进程中复制过来的，父子进程因此共享同一页框¹。所以无论是postmaster还是backend进程（任何postmaster fork出来的进程），在虚拟内存地址中都会映射相同的共享内存地址，他们在smaps中的地址和Size是相等的。

为什么pg的所有的进程的虚拟内存都是/dev/zero段占用多
#

mmap实现匿名页映射主要有两种方式：一种是通过设置MAP_ANONYMOUS标志并传入fd=-1，另一种是打开/dev/zero设备文件并将得到的文件描述符传递给mmap。这两种方法在功能上是等效的。

pg sharebuffer使用的/dev/zero设备映射来实现的匿名共享页，所以一般能看到pg进程的/dev/zero的虚拟内存地址占用是比较多。

References
#

[《深入理解Linux内核》]: 《深入理解Linux内核》：内存寻址、内存管理、地址空间管理、回收页框

[《深入理解Linux进程和内存》]: 《深入理解Linux进程和内存》 CPU硬件原理、进程、线程的对比

[《奔跑吧 Linux内核入门篇（第2版）》]: 《奔跑吧Linux内核入门篇（第2版）》系统调用、内存管理

《深入理解Linux内核》：内存寻址、内存管理、地址空间管理、回收页框 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
https://www.cs.oslomet.no/~haugerud/os/Forelesning/os7.pdf ↩︎
《深入理解Linux进程和内存》CPU硬件原理、进程、线程的对比 ↩︎ ↩︎
https://www.cs.unc.edu/~porter/courses/comp630/s24/slides/pfra.pdf ↩︎
《奔跑吧Linux内核入门篇（第2版）》系统调用、内存管理 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
https://courses.cs.washington.edu/courses/cse333/20wi/lectures/07/CSE333-L07-posix_20wi.pdf ↩︎
https://www.sohu.com/a/392831824_467784 ↩︎
redhat,Configuringanoperatingsystemtooptimizememoryaccess ↩︎
https://www.kernel.org/doc/html/latest/admin-guide/sysctl/vm.html#swappiness ↩︎
https://access.redhat.com/solutions/6785021 ↩︎
https://www.kernel.org/doc/Documentation/vm/overcommit-accounting ↩︎
https://carlyleliu.github.io/LinuxKernel/LinuxMemoryOptimization/ ↩︎
https://www.man7.org/linux/man-pages/man5/proc_pid_oom_score.5.html ↩︎
https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/memory.html ↩︎ ↩︎ ↩︎
https://wiki.goframe.org/pages/viewpage.action?pageId=157646868 ↩︎
https://www.man7.org/conf/lca2019/cgroups_v2-LCA2019-Kerrisk.pdf ↩︎
https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html ↩︎
https://support.huaweicloud.com/usermanual-hce/hce_02_0072.html ↩︎
https://chrisdown.name/talks/cgroupv2/cgroupv2-fosdem.pdf ↩︎
https://www.cnblogs.com/muahao/p/10109712.html ↩︎

PostgreSQL CLOG文件及其从库同步解析

Tue, 03 Sep 2024 00:00:00 +0000

放眼所有关系型数据库，PostgreSQL的clog也是很特殊的日志。CLOG的存在跟PG的MVCC机制不无关系。一些事务ID、clog的基础知识本篇不会涉及，感谢兴趣的可参考clog和hintbits。本篇主要讲clog文件的构成、手工定位事务状态、clog的wal日志同步机制，以进一步理解PostgreSQL的clog。

clog segment
#

clog目录
#

为了区别普通日志，PG 10对clog和wal的目录进行了重命名¹：

pg9.6	pg10
pg_clog	pg_xact
pg_xlog	pg_wal

别搞错了，我也有段时间被pg_xlog和pg_xact给困扰···

clog segment name
#

clog也是由slru管理，clog文件命名也在slru.c中

#define SlruFileName(ctl, path, seg) \
	snprintf(path, MAXPGPATH, "%s/%04X", (ctl)->Dir, seg)

%04X表示十六进制（X），宽度为4、不足前面补0（04）。 clog文件名示例如下：

[pg_xact]$ ll
-rw------- 1 postgres postgres 262144 Aug 15 16:29 03C0
-rw------- 1 postgres postgres 262144 Aug 19 23:04 03C1
...

TransactionID与clog位置的转换
#

clog只存储事务ID的状态，不存事务ID本身。通过TransactionID本身是可以直接定位到clog文件及文件中的位置的。在此之前我们需要了解一些基础知识。

CLOG保存的事务状态
#

事务的状态只有4种：

typedef int XidStatus;

#define TRANSACTION_STATUS_IN_PROGRESS		0x00
#define TRANSACTION_STATUS_COMMITTED		0x01
#define TRANSACTION_STATUS_ABORTED		0x02
#define TRANSACTION_STATUS_SUB_COMMITTED	0x03

事务状态只有进行中、已提交、回滚、子事务已提交。注意事务id没有“未开始”这个状态，只要数据库中分配了事务ID，那么这个事务肯定是已经开始了。相反，库中还没有分配的事务ID（实际是少许，参考下面的extend clog章节），在clog中对应in_progress状态。 4个事务状态实际上2个bit位即可存储。那么1个字节（8 bits）可存储4个事务状态，1个页（8k）能放8KB*4=32768个事务状态。这些都在源码中定义了：

 * Defines for CLOG page sizes. A page is the same BLCKSZ as is used
 * everywhere else in Postgres.
//clog页大小=BLCKSZ=8k（默认） 
#define CLOG_BITS_PER_XACT	2 								 //一个事务状态占2个bit
#define CLOG_XACTS_PER_BYTE 4 								 //1个字节可存放4个事务状态
#define CLOG_XACTS_PER_PAGE (BLCKSZ * CLOG_XACTS_PER_BYTE) //1个页可存放32768个事务状态，8KB*4=32768
#define CLOG_XACT_BITMASK ((1 << CLOG_BITS_PER_XACT) - 1) //事务状态的bitmask位=((1<<2)-1)=3，用二进制表达为11

#define SLRU_PAGES_PER_SEGMENT	32 //1个segment有32个pages

汇总：

1个clog segment有32个page
1个clog page有8k（一般）
1个bytes有4个事务状态
1个事务状态占2 bit

clog segment/page/bytes的转换
#

事务id对应在哪个CLOG段不太好找，它藏在注释里：

 * Note: because TransactionIds are 32 bits and wrap around at 0xFFFFFFFF,
 * CLOG page numbering also wraps around at 0xFFFFFFFF/CLOG_XACTS_PER_PAGE,
 * and CLOG segment numbering at
 * 0xFFFFFFFF/CLOG_XACTS_PER_PAGE/SLRU_PAGES_PER_SEGMENT
//segment number=xid/CLOG_XACTS_PER_PAGE/SLRU_PAGES_PER_SEGMENT=xid/32768/32 //事务id对应在哪个CLOG段，xid/32768/32,需要转成16进制

事务id对应对应到page、byte等比较清晰²：

#define TransactionIdToPage(xid)	((xid) / (TransactionId) CLOG_XACTS_PER_PAGE) //事务id对应在哪个CLOG page,xid/32768
#define TransactionIdToPgIndex(xid) ((xid) % (TransactionId) CLOG_XACTS_PER_PAGE) //事务id对应在上面page中的偏移量,xid%32768
#define TransactionIdToByte(xid)	(TransactionIdToPgIndex(xid) / CLOG_XACTS_PER_BYTE) //事务id对应在page中的第几个字节,(xid%32768)/4
#define TransactionIdToBIndex(xid)	((xid) % (TransactionId) CLOG_XACTS_PER_BYTE)		//事务id对应在上面字节中的哪个bit index（注意是bit index不是bit本身）,xid%4

一般来说（8k的BLCKSZ），1个CLOG段有32个页面；1个CLOG段有32*8k字节，即CLOG文件大小固定256K；1个CLOG段可存放4*32*8k个事务状态。

[pg_xact]$ ll # 256k的clog segment
-rw------- 1 postgres postgres 262144 Aug 15 16:29 03C0
-rw------- 1 postgres postgres 262144 Aug 19 23:04 03C1
...

clog bit位的转换
#

设置clog bit和获取clog bit的函数（对应TransactionIdSetStatusBit和TransactionIdGetStatus）都有以下代码以获取事务id对应到clog中的哪两位bit：

	int			bshift = TransactionIdToBIndex(xid) * CLOG_BITS_PER_XACT;
	char	 *byteptr;
...
	byteptr = XactCtl->shared->page_buffer[slotno] + byteno;
	curval = (*byteptr >> bshift) & CLOG_XACT_BITMASK;

bshift表示右移的位置，其中TransactionIdToBIndex=xid%4，CLOG_BITS_PER_XACT=2，CLOG_XACT_BITMASK=3（二进制为11）。 clog bit获取的关键代码curval = (*byteptr >> bshift) & CLOG_XACT_BITMASK分两段来看：

*byteptr >> bshift表示指针右移0、2、4、6位
& CLOG_XACT_BITMASK其实就是右移后取后两位（00&11=00、01&11=01、10&11=10、11&11=11）

so，计算在一个byte中事务id状态的位置：

xid%4=0时，取第7、8位
xid%4=1时，取第5、6位
xid%4=2时，取第3、4位
xid%4=3时，取第1、2位

注意，事务id状态在byte中的bit位是反着取的，不是正着顺序取。byte、page位这些是顺序递增的取的。

手动计算事务id在clog文件中的位置
#

如果我们要手工通过hexdump定位CLOG中的事务，需要计算出三个元素<CLOG的段号、段中的偏移量in bytes、byte上的偏移量in bitindex>。（这里参考了《PostgreSQL数据库内核分析》的说法，不过有一些区别³）

计算之前还需要了解：

clog段文件号是16进制的
hexdump是16进制的，每行存放16个字节，即每行存放16*CLOG_XACTS_PER_BYTE=16*4=64个事务状态
hexdump -s xxx是以byte为单位

下面sql可以计算transactionid对应clog中的位置：

--CLOG的段号
--%4294967296代表事务id回卷，/(8192*4*32)代表一个段文件能包含的最大事务数，to_hex转为文件名的16进制，lpad左补全4位
select lpad(upper(to_hex(txid_current()%4294967296/(8192*4*32))),4,'0') as clog_segmentno;

--段中的偏移量in bytes 
--%4294967296代表事务id回卷，%(8192*32*4)取余下的事务id，/4计算成byte单位
select txid_current()%4294967296%(8192*32*4)/4 as in_clog_offset_bytes;

--byte上的偏移量in bitindex
--%4294967296代表事务id回卷，%4取byte中的bitindex
select txid_current()%4294967296%4 as in_byte_offset_bitindex;


--或者一条sql
select lpad(upper(to_hex(txid_current()%4294967296/(8192*4*32))),4,'0') as clog_segmentno,txid_current()%4294967296%(8192*32*4)/4 as in_clog_offset_bytes,txid_current()%4294967296%4 as in_byte_offset_bitindex;

实操模拟计算一个事务id在clog中的状态

begin;
 select lpad(upper(to_hex(txid_current()%4294967296/(8192*4*32))),4,'0') as clog_segmentno,txid_current()%4294967296%(8192*32*4)/4 as in_clog_offset_bytes,txid_current()%4294967296%4 as in_byte_offset_bitindex;
 clog_segmentno | in_clog_offset_bytes | in_byte_offset_bitindex 
----------------+----------------------+-------------------------
 0002 | 63196 | 3
rollback;
checkpoint; 

rollback把事务回滚，主要是方便观察，因为大部分事务都是提交的。 checkpoint是未来保证clog page刷脏，不然clog page在clog buffer中还没写到clog segment文件。

cd pg_xact/
 hexdump -C 0002 -s 63196 -n 1 -v
0000f6dc 95 |.|
0000f6dd

--十六进制转二进制
> select 'x96'::bit(8);
 bit 
----------
 10010110

xid%4=3时，取第1、2位，所以这个回滚的事务的bit位取10，10代表TRANSACTION_STATUS_ABORTED

为什么clog中一般有很多55和U？
#

一般的业务事务库clog文件，直接hexdump的话结果就像下面这样：

hexdump -C 0001 -v|head -10
00000000 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU|
00000010 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU|
00000020 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU|
00000030 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU|
00000040 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU|
00000050 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU|
00000060 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU|
00000070 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU|
00000080 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU|
00000090 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU|

因为事务提交的状态=01=TRANSACTION_STATUS_COMMITTED，一个byte中4个连续的事务都是提交的，那么就是01010101。

二进制为01010101，十六进制为55
十六进制55在ASCII中为U，所以在肉眼看CLOG文件一般可以看到很多U
偶尔有些数组不是55或U，因为生产环境中偶尔有些事务没有完成或者使用了子事务。子事务在clog中的提交状态是x03。

shared clog buffer
#

clog shared buffers的个数很容易理解：

/*
 * Number of shared CLOG buffers.
 *
 * On larger multi-processor systems, it is possible to have many CLOG page
 * requests in flight at one time which could lead to disk access for CLOG
 * page if the required page is not found in memory. Testing revealed that we
 * can get the best performance by having 128 CLOG buffers, more than that it
 * doesn't improve performance.
 *
 * Unconditionally keeping the number of CLOG buffers to 128 did not seem like
 * a good idea, because it would increase the minimum amount of shared memory
 * required to start, which could be a problem for people running very small
 * configurations. The following formula seems to represent a reasonable
 * compromise: people with very low values for shared_buffers will get fewer
 * CLOG buffers as well, and everyone else will get 128.
 */
Size
CLOGShmemBuffers(void)
{
	return Min(128, Max(4, NBuffers / 512));
}

翻译：经过测试128个clog buffers性能是最好的，再多也提升不了性能。但是由于有些库的配置实在是太小了，128个clog buffers显得有点大，所以取shared buffers个数的1/512。也就是说： clog buffers的个数=1/512 shared buffer，最小是4，最大是128。注意这里都是buffer的个数，不是大小！那么单个buffer有多大呢？ clog buffer是slru管理的，slru每个page都是8k：

A page is the same BLCKSZ as is used everywhere

我们可以从clog slru初始化的角度窥探shared clog buffer的大小：

/*
 * Initialization of shared memory for CLOG
 */
Size
CLOGShmemSize(void)
{
	return SimpleLruShmemSize(CLOGShmemBuffers(), CLOG_LSNS_PER_PAGE);
}

传入的CLOGShmemBuffers()是4~128，传入的CLOG_LSNS_PER_PAGE=1024 byte（8k page时）。 SimpleLruShmemSize初始化slru shmem：

Size
SimpleLruShmemSize(int nslots, int nlsns)
{
	Size		sz;

	/* we assume nslots isn't so large as to risk overflow */
	sz = MAXALIGN(sizeof(SlruSharedData));
	sz += MAXALIGN(nslots * sizeof(char *));	/* page_buffer[] */
	sz += MAXALIGN(nslots * sizeof(SlruPageStatus));	/* page_status[] */
	sz += MAXALIGN(nslots * sizeof(bool));	/* page_dirty[] */
	sz += MAXALIGN(nslots * sizeof(int));	/* page_number[] */
	sz += MAXALIGN(nslots * sizeof(int));	/* page_lru_count[] */
	sz += MAXALIGN(nslots * sizeof(LWLockPadded));	/* buffer_locks[] */

	if (nlsns > 0)
		sz += MAXALIGN(nslots * nlsns * sizeof(XLogRecPtr));	/* group_lsn[] */

	return BUFFERALIGN(sz) + BLCKSZ * nslots;
}

slrus用一些数组保存slru的元数据和控制信息，sz大小都是数据类型*buffer个数，这些大致估算都不是特别不大。主要初始化的内存还是BLCKSZ * nslots，也就是8k * (4~128)=(32k~1M)大小。所以可以粗略的认为，shared clog buffer的大小为1M左右。

CLOG的wal：类型、写入和redo
#

写clog的时候会写clog的wal日志吗？如果写了那不是clog丢了也可以通过wal日志再次应用就应该找回了事务状态？我们带着问题来看clog写wal和redo的源码。

extend clog
#

ZeroCLOGPage会写wal，ZeroCLOGPage(pageno, true)实际上仅由ExtendCLOG调用：

/*
 * Make sure that CLOG has room for a newly-allocated XID.
 *
 * NB: this is called while holding XidGenLock. We want it to be very fast
 * most of the time; even when it's not so fast, no actual I/O need happen
 * unless we're forced to write out a dirty clog or xlog page to make room
 * in shared memory.
 */
void
ExtendCLOG(TransactionId newestXact)
{
	int			pageno;

	/*
	 * No work except at first XID of a page. But beware: just after
	 * wraparound, the first XID of page zero is FirstNormalTransactionId.
	 */
	if (TransactionIdToPgIndex(newestXact) != 0 &&
		!TransactionIdEquals(newestXact, FirstNormalTransactionId))
		return;

	pageno = TransactionIdToPage(newestXact); //由TransactionId换算的clog page号

	LWLockAcquire(XactSLRULock, LW_EXCLUSIVE);

	/* Zero the page and make an XLOG entry about it */
	ZeroCLOGPage(pageno, true);

	LWLockRelease(XactSLRULock);
}

ZeroCLOGPage主要调用WriteZeroPageXlogRec：

/*
 * Write a ZEROPAGE xlog record
 */
static void
WriteZeroPageXlogRec(int pageno)
{
	XLogBeginInsert();
	XLogRegisterData((char *) (&pageno), sizeof(int));
	(void) XLogInsert(RM_CLOG_ID, CLOG_ZEROPAGE);
}

WriteZeroPageXlogRec就是在写wal record了，写入的类型是“RM_CLOG_ID, CLOG_ZEROPAGE”。通过waldump可以查看到CLOG_ZEROPAGE，它的占比一般都是非常少的：

pg_waldump -z 000000010000056B00000018 --stat=record
Type N (%) Record size (%) FPI size (%) Combined size (%)
---- - --- ----------- --- -------- --- ------------- ---
...
CLOG/ZEROPAGE 1 ( 0.00) 30 ( 0.00) 0 ( 0.00) 30 ( 0.00)
...

extend clog page时都是以page为单位，实际上在clog segment的末尾可以很容易看到00

hexdump 03C2
0000000 5555 5555 5555 5555 5555 5555 5555 5555
*
001bb30 5555 5555 0055 0000 0000 0000 0000 0000
001bb40 0000 0000 0000 0000 0000 0000 0000 0000 
* ##clog文件后面的都是0
001c000

truncate clog
#

除了extend clog外，还有truncate clog，truncate clog会在vacuum期间被调用，调用时会写truncate clog的wal record，并将wal record flush到磁盘

/*
 * Remove all CLOG segments before the one holding the passed transaction ID
 *
 * Before removing any CLOG data, we must flush XLOG to disk, to ensure
 * that any recently-emitted FREEZE_PAGE records have reached disk; otherwise
 * a crash and restart might leave us with some unfrozen tuples referencing
 * removed CLOG data. We choose to emit a special TRUNCATE XLOG record too.
 * Replaying the deletion from XLOG is not critical, since the files could
 * just as well be removed later, but doing so prevents a long-running hot
 * standby server from acquiring an unreasonably bloated CLOG directory.
 *
 * Since CLOG segments hold a large number of transactions, the opportunity to
 * actually remove a segment is fairly rare, and so it seems best not to do
 * the XLOG flush unless we have confirmed that there is a removable segment.
 */
void
TruncateCLOG(TransactionId oldestXact, Oid oldestxid_datoid)
{
	int			cutoffPage;

	/*
	 * The cutoff point is the start of the segment containing oldestXact. We
	 * pass the *page* containing oldestXact to SimpleLruTruncate.
	 */
	//写入wal的是clog的位置，clog位置是oldestXact转换出来的clog page号
	cutoffPage = TransactionIdToPage(oldestXact); 

.....
	/*
	 * Write XLOG record and flush XLOG to disk. We record the oldest xid
	 * we're keeping information about here so we can ensure that it's always
	 * ahead of clog truncation in case we crash, and so a standby finds out
	 * the new valid xid before the next checkpoint.
	 */
	// WriteTruncateXlogRec会写对应的wal record并将其写到磁盘上
	WriteTruncateXlogRec(cutoffPage, oldestXact, oldestxid_datoid);
	
	//wal写完后，才真正执行truncate clog段
	/* Now we can remove the old CLOG segment(s) */
	SimpleLruTruncate(XactCtl, cutoffPage);
}

WriteTruncateXlogRec就是写RMGR为RM_CLOG_ID，info为 CLOG_TRUNCAT的wal record：

/*
 * Write a TRUNCATE xlog record
 *
 * We must flush the xlog record to disk before returning --- see notes
 * in TruncateCLOG().
 */
static void
WriteTruncateXlogRec(int pageno, TransactionId oldestXact, Oid oldestXactDb)
{
	XLogRecPtr	recptr;
	xl_clog_truncate xlrec;

	xlrec.pageno = pageno;
	xlrec.oldestXact = oldestXact;
	xlrec.oldestXactDb = oldestXactDb;

	XLogBeginInsert();
	XLogRegisterData((char *) (&xlrec), sizeof(xl_clog_truncate));
	recptr = XLogInsert(RM_CLOG_ID, CLOG_TRUNCATE);
	XLogFlush(recptr);
}

当制造了clog wal record后，还需要redo恢复的routine：

/*
 * CLOG resource manager's routines
 */
void
clog_redo(XLogReaderState *record)
{
...
	//redo info类型是CLOG_ZEROPAGE时，将读取出来的redo信息放在内存，然后写到CLOG page文件中
	if (info == CLOG_ZEROPAGE)
	{
		int			pageno;
		int			slotno;

		memcpy(&pageno, XLogRecGetData(record), sizeof(int));

		LWLockAcquire(XactSLRULock, LW_EXCLUSIVE);

		slotno = ZeroCLOGPage(pageno, false);
		SimpleLruWritePage(XactCtl, slotno); 
		Assert(!XactCtl->shared->page_dirty[slotno]);

		LWLockRelease(XactSLRULock);
	}
	//redo info类型是CLOG_TRUNCATE时，将读取出来的redo信息放在内存中，确认page是可删除的（如果不可用需要write page），然后truncate segment
	else if (info == CLOG_TRUNCATE)
	{
		xl_clog_truncate xlrec;

		memcpy(&xlrec, XLogRecGetData(record), sizeof(xl_clog_truncate));

		/*
		 * During XLOG replay, latest_page_number isn't set up yet; insert a
		 * suitable value to bypass the sanity test in SimpleLruTruncate.
		 */
		XactCtl->shared->latest_page_number = xlrec.pageno;

		AdvanceOldestClogXid(xlrec.oldestXact);

		SimpleLruTruncate(XactCtl, xlrec.pageno);
	}
	else
		elog(PANIC, "clog_redo: unknown op code %u", info);
}

clog redo routine所做的事：

redo info类型是CLOG_ZEROPAGE时，找到一个合适的slot（如果没有需要换出），根据读取出来的redo信息（实际上是clog page号）进行一些是否可写的判断，可以再讲page write到clog文件
redo info类型是CLOG_TRUNCATE时，根据读取出来的redo信息（实际上是clog page号），确认page是可删除的（如果不可用需要write page），然后truncate clog segment

clog的同步小结
#

CLOG只有两种wal日志，两种都不包含事务状态信息，且仅仅是在extend clog page和truncate clog segment时触发，写入的wal record只是一个clog page编号。 CLOG的wal日志RMGR类型只有一种RM_CLOG_ID，这种类型只有两种信息：CLOG_ZEROPAGE、CLOG_TRUNCATE。

/* XLOG stuff */
#define CLOG_ZEROPAGE 0x00
#define CLOG_TRUNCATE 0x10

clog wal同步总结： 从库本质上没有在同步clog信息，只是同步了一些clog文件的扩容和删除信息。

但是，从库的clog文件中明明是有状态信息的，从库明显也需要这部分信息以提供可见性检查。clog中的事务状态是怎么同步的呢？

事务id的wal：类型、写入和redo
#

rmgr=clog的wal不包含事务状态，难道从库不同步clog事务信息？并不是，wal日志中有事务ID的状态信息，clog也会被更新：

--回滚一个事务，提交一个事务
> begin;
BEGIN
> select txid_current();
 txid_current 
--------------
 1817254
(1 row)

> rollback;
ROLLBACK
> begin;
BEGIN
> select txid_current();
 txid_current 
--------------
 1817258
(1 row)

> commit;
COMMIT
> checkpoint;
CHECKPOINT

--pg_waldump查看日志中的事务ID状态
[datalzl/pg_wal]$ pg_waldump ../../pg_wal/000000010000007300000008|grep -E "1817254|1817258"
rmgr: Transaction len (rec/tot): 34/ 34, tx: 1817254, lsn: 73/400ED210, prev 73/400ED1E0, desc: ABORT 2024-08-01 14:41:26.017612 CST
rmgr: Transaction len (rec/tot): 46/ 46, tx: 1817258, lsn: 73/400EEB08, prev 73/400EEAD8, desc: COMMIT 2024-08-01 14:41:37.042545 CST
pg_waldump: fatal: error in WAL record at 73/400F7C78: invalid record length at 73/400F7F88: wanted 24, got 0

在wal中有记录事务ID（1817254，1817258）的状态，并且分别记录为ABORT、COMMIT ；rmgr为Transaction。事务ID状态在wal日志中，但是pg会写到从库的clog里吗？很明显，我们需要找到这部分的redo信息。按照刚才的经验，clog_redo代表rmgr=clog的wal redo源码，那么源码搜索_redo应该能找到rmgr=transactionid的wal redo源码。搜搜，在xact.c中的找到函数xact_redo，其主要调用xact_redo_commit,xact_redo_abort，明显各自对应提交事务和回退事务的wal日志应用逻辑。

void
xact_redo(XLogReaderState *record)
{
	uint8		info = XLogRecGetInfo(record) & XLOG_XACT_OPMASK;

	/* Backup blocks are not used in xact records */
	Assert(!XLogRecHasAnyBlockRefs(record));

	if (info == XLOG_XACT_COMMIT)
	{
	...
		xact_redo_commit(&parsed, XLogRecGetXid(record),
						 record->EndRecPtr, XLogRecGetOrigin(record));
	}
...
	else if (info == XLOG_XACT_ABORT)
	{
	...
		xact_redo_abort(&parsed, XLogRecGetXid(record));
	}
...
	}
	else
		elog(PANIC, "xact_redo: unknown op code %u", info);
}

以commit为例

static void
xact_redo_commit(xl_xact_parsed_commit *parsed,
				 TransactionId xid,
				 XLogRecPtr lsn,
				 RepOriginId origin_id)
{
...

	if (standbyState == STANDBY_DISABLED)
	{
		/*
		 * Mark the transaction committed in pg_xact.
		 */
		TransactionIdCommitTree(xid, parsed->nsubxacts, parsed->subxacts);
	}
	else//standby逻辑
	{
	...
		/*
		 * Mark the transaction committed in pg_xact. We use async commit
		 * protocol during recovery to provide information on database
		 * consistency for when users try to set hint bits. It is important
		 * that we do not set hint bits until the minRecoveryPoint is past
		 * this commit record. This ensures that if we crash we don't see hint
		 * bits set on changes made by transactions that haven't yet
		 * recovered. It's unlikely but it's good to be safe.
		 */
		//在pg_xact中标记事务提交
		TransactionIdAsyncCommitTree(xid, parsed->nsubxacts, parsed->subxacts, lsn);

...
}

看着TransactionIdAsyncCommitTree就是我们要找的写clog的函数。

为了验证wal中事务commit信息的redo逻辑，下面给从库的startup进程打三个断点，然后在源库执行begin;select txid_current();commit;提交一个事务，看看从库的startup进程在做redo的时候是否命中我们想要看到的函数：

(gdb) bt
#0 TransactionIdAsyncCommitTree (xid=xid@entry=1818665, nxids=0, xids=0x0, lsn=lsn@entry=495398394064) at transam.c:274
#1 0x000000000050c139 in xact_redo_commit (parsed=parsed@entry=0x7ffda52c0fc0, xid=1818665, lsn=495398394064, origin_id=<optimized out>) at xact.c:5805
#2 0x000000000050ffa3 in xact_redo (record=0x2b5ff2434038) at xact.c:5962
#3 0x0000000000519ea5 in StartupXLOG () at xlog.c:7411
#4 0x000000000072f301 in StartupProcessMain () at startup.c:204
#5 0x0000000000528701 in AuxiliaryProcessMain (argc=argc@entry=2, argv=argv@entry=0x7ffda52c6ef0) at bootstrap.c:450
#6 0x000000000072c459 in StartChildProcess (type=StartupProcess) at postmaster.c:5494
#7 0x000000000072ec44 in PostmasterMain (argc=argc@entry=3, argv=argv@entry=0x2b5ff242d1c0) at postmaster.c:1407
#8 0x000000000048931f in main (argc=3, argv=0x2b5ff242d1c0) at main.c:210
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y 0x000000000050c060 in xact_redo_commit at xact.c:5753
 breakpoint already hit 43 times
2 breakpoint keep y 0x0000000000508190 in TransactionIdCommitTree at transam.c:262
3 breakpoint keep y 0x00000000005081a0 in TransactionIdAsyncCommitTree at transam.c:274
 breakpoint already hit 1 time

可以命中断点TransactionIdAsyncCommitTree ，并且xid=1818665，也就是刚才在源库提交的事务ID。说明刚才肉眼看的代码逻辑没有问题。 so，standby库的clog事务ID状态由wal rmgr=Transaction来同步

总结
#

clog只存储了事务ID的状态，没有存储事务ID本身
可以通过事务ID手动定位到CLOG文件中的事务状态
rmgr=clog的wal只有扩展和清理clog文件，没有更新事务状态
rmgr=transaction的wal会更新clog的事务状态

references
#

《快速掌握PostgreSQL版本新特性》p24 ↩︎
阎书利 PostgreSQL的CLOG解析 https://www.modb.pro/db/606433 ↩︎
《PostgreSQL数据库内核分析》第7章 p380-390 ↩︎

PostgreSQL流复制

Tue, 13 Aug 2024 00:00:00 +0000

什么是PG流复制？
#

Streaming Replication是pg9.0开始提供的传递WAL日志的方式，只要primary库一产生日志，就会立马传递到standby库。在pg9.0之前，pg只能一个个传送wal日志(log shipping)，备库至少比主库落后一个wal日志

pg流复制进程
#

wal sender：wal sender存在于主库。wal sender进程将主库最新LSN到备库最新的LSN之间的wal 传递给备库 wal receiver：wal receiver存在于备库。wal receiver进程将备库最新的LSN号传递给主库。wal receiver接收wal sender传递过来的WAL数据并写入WAL日志 startup：备库实例恢复进程。将wal日志在备库上重放

pg 16776 14632 0 13:33 ? 00:00:00 postgres: wal sender process lzl 172.17.100.150(13338) streaming 0/3002D30

pg 16775 15329 0 13:33 ? 00:00:00 postgres: wal receiver process streaming 0/3002D30
pg 15330 15329 0 10:26 ? 00:00:00 postgres: startup process recovering 000000010000000000000003

pg流复制原理
#

pg流复制主要分为2个阶段，实例恢复阶段和主备同步阶段。 实例恢复阶段：当pg库异常宕机后，数据库启动时，pg会重放宕机前的最后一个checkpoint之后的所有WAL日志（这跟oracle、mysql等关系型数据库实例恢复是同样的原理，目的就是把数据库置为一致性状态）。pg备库在搭建时，一般主库都是不停机的，此时备份主库出来的备份库处于不一致状态，在备库启动时statup进程将进行实例恢复操作 主备同步阶段：wal receiver进程将备库最新的LSN号传递给主库，wal sender将主库最新LSN到备库最新的LSN之间的wal 传递给wal receiver，wal receiver接收WAL并将WAL写入到磁盘上，startup进程根据磁盘上的WAL日志在备库上重放

同步和异步
#

pg主从有5种模式，由synchronous_commit 参数控制。synchronous_commit 参数的本质就是控制主库什么时候提交。 remote_apply：所有备库上均已应用完WAL时，主库提交。所以这个模式是同步模式，主从是一致的，主库上能查到的数据备库上一定也可以查到，这种模式下主备没有延时，但对主库提交时间有影响，因为主库commit需要等待网络传输和备库应用时间 ynchronous_commit的含义分2种情况，有从库和无从库时（synchronous_standby_name空或非空时）

当synchronous_standby_name为非空时： remote_apply:从库已应用了wal，主库才可以提交。这种模式主从是同步的 on：default。主从的wal都写到磁盘上时，主库提交。类似半同步，不会丢数据。 remote_write：备库接收到wal并将wal日志写到文件系统cache上时，主库提交。此时从库的接收到wal但是还没有落盘，如果操作系统crash，会丢失数据。 local：主库wal刷到磁盘时提交。这种模式是异步的，主库不需要确认备库状态就可以提交。 off：本机wal没有刷到磁盘就可以提交，存在数据丢失风险，不推荐。

当synchronous_standby_name为空时：（当synchronous_standby_name为空时，synchronous_commit只有on和off有效，如果是remote_apply, remote_write and local ，那么仍然被认为是on） on：default。数据库wal写到磁盘上，事务才可以提交 off：本机wal没有刷到磁盘就可以提交，存在数据丢失风险，不推荐。

主从同步关系

主从可靠性

Failover
#

当主库crush时，备库就需要启动failover，此时备库就成为新主库。pg没有提供可以识别failure的方法，但是pg提供了激活主库的方法。（一般三方工具会调用pg激活方法，而主备监控、主库宕机判断、连接切换等等，都不是pg本身来做） pg提供了2种方法将备库激活为主库：trigger_file文件和pg_ctl promote命令。(pg 12以后trigger_file变成promote_trigger_file） trigger_file和pg_ctl promote在激活时都是一条命令就可以完成激活备库的任务，区别在于trigger_file需要在recover_file提前写好trigger_file配置使用trigger_file做主备切换（pg_ctl promote同样的效果，比较简单）：

备库recovery.conf中配置trigger_file
关闭主库
touch trigger_file，将老备库启动为新主库
配置recovery.conf，将老主库启动为新备库
观察新老主备库

failover示例： 环境：主库 172.17.100.150 5432 备库 172.17.100.150 5433

1.备库recovery.conf中配置trigger_file

$ cat recovery.conf|grep trigger
trigger_file = '/pg/pg96data_sla/trigger.kenyon'
$ ll /pg/pg96data_sla/trigger.kenyon
ls: cannot access /pg/pg96data_sla/trigger.kenyon: No such file or directory

在recovery.conf中配置trigger文件路径就可以了，配置后不会出现trigger文件

备库postgres.conf添加配置

max_wal_senders = 6 #max_wal_senders是sender进程的最大数量，默认是0，所以切换前备库必须配置
hot_standby=on #备库打开查询功能

2.关闭主库

$ pg_ctl stop -D /pg/pg96data_pri -m fast
waiting for server to shut down.... done
server stopped

(判断主库WAL是否全部被备库应用：pg9.6- cd pg_xlog;pg 10+ cd pg_wal)

ls -ltr|tail -n 1 |awk '{print $NF}'|while read xlog;do pg_xlogdump $xlog;done

观察备库wal中有关键词shutdown

3.touch激活备库(或者 pg_ctl promote -D /pg/pg96data_sla

$ touch /pg/pg96data_sla/trigger.kenyon

此时recovery.conf变成recovery.done

4.主库设置为备库 配置新备库recovery.conf文件，可以直接cp老备库的过来，修改IP和目录

vi $新备库/recover.conf
standby_mode = on
primary_conninfo = 'host=172.17.100.150 port=5433 user=lzl password=lzl'
recovery_target_timeline = 'latest'

配置postgres.conf，将hot_standby = on写入conf，表示备库开启查询

vi $新备库/postgres.conf
hot_standby = on

启动新备库

/pg/pg96/bin/pg_ctl -D /pg/pg96data_pri -l /pg/pg96data_pri/server.log start

5.检查主备库

postgres=# \x
Expanded display is on.
postgres=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid | 24766
usesysid | 16384
usename | lzl
application_name | walreceiver
client_addr | 172.17.100.150
client_hostname | 
client_port | 47345
backend_start | 2021-07-30 07:44:05.582546+00
backend_xmin | 
state | streaming
sent_location | 0/4033790
write_location | 0/4033790
flush_location | 0/4033790
replay_location | 0/4033790
sync_priority | 0
sync_state | async

pg_basebackup
#

pg_basebackup是pg自带的备份工具，它用来做pg的基础备份。pg_basebackup可以用作PITR，也可以用来构造log-shipping standby和stream standby。它是pg的物理备份工具。 https://liuzhilong.blog.csdn.net/article/details/119533506

pg_rewind
#

pg_rewind可以用作pg主从的维护工具。当2个pg实例时间线（timeline）出现分叉时，pg_rewind可以做实例间的同步。（比如主库运行的情况下，备库failover后运行了一段时间，此时主备的时间线就出现了分叉） https://liuzhilong.blog.csdn.net/article/details/119250794

Replication Slots
#

什么是pg复制槽？ 主从架构下，如果从库还没有收到wal日志，主库就把wal删除了，这样的lag就不能自动恢复。复制槽就是为了确保主库不会把那些还没有被传到从库的WAL日志给删除。在没有使用复制槽的情况下，可能需要用 wal_keep_size/wal_keep_segment和 archive_command去确保wal日志不被删除，但这种方式总会保留过多的wal，且在延时较大时也不能保证wal一定不会被删除。所以复制槽就是为此而生。但是复制槽可能会导致主库一直不删除wal（比如从库已宕机的情况）导致磁盘被撑满，这时就需要max_slot_wal_keep_size来设置wal文件的保留上限。

复制槽参数： max_slot_wal_keep_size：在有复制槽时，该参数定义pg_wal目录下wal文件的最大大小。默认值为-1，表示主库为从库保留wal文件的大小没有上限。 wal_keep_segments/wal_keep_size:pg12及以下为wal_keep_segments，pg13及以上为wal_keep_size。保证pg_wal下的wal文件不会被删除。在没有复制槽的情况下，wal文件超过该大小就可能被删除，可能导致从库不可追日志。如果调整的过大，可能导致目录被撑的很大。该参数默认为0，也就是不保留WAL文件。如果wal被删除，可能会出现如下报错 ERROR: requested WAL segment xxxx has already been removed 这时从库只能期待有归档，否则只要重搭。 primary_slot_name：设置slot的名字，表示pg主从开启复制槽。所以开启pg复制槽至少有类似下面的配置 primary_conninfo = ‘host=172.17.100.150 port=5433 user=lzl password=lzl’ primary_slot_name = ‘pg_slot_lzl’ max_replication_slots:复制槽的最大个数，重启生效。如果使用的复制槽不足，从库将启动失败。应将该值设置的较大。在pg9.6版本以下，默认值为0，pg10以上为10。

创建pg复制槽

1.设置主库max_replication_slots参数 主库：（我的pg版本为9.6) max_replication_slots=10 加入postgres.conf，并重启主库

2.创建复制槽 创建复制槽：

postgres=# SELECT * FROM pg_create_physical_replication_slot('pg_slot_lzl');
 slot_name | xlog_position 
-------------+---------------
 pg_slot_lzl |

查看复制槽

postgres=# SELECT slot_name, slot_type, active FROM pg_replication_slots;
 slot_name | slot_type | active 
-------------+-----------+--------
 pg_slot_lzl | physical | f

3.设置从库primary_slot_name参数 primary_slot_name = 'pg_slot_lzl' 加入recovery.conf,并重启从库

4.查看复制槽

postgres=# select *,pg_xlogfile_name(restart_lsn)as current_xxlog from pg_replication_slots;
 slot_name | plugin | slot_type | datoid | database | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | current_xxlog 
-------------+--------+-----------+--------+----------+--------+------------+------+--------------+-------------+---------------------+--------------------------
 pg_slot_lzl | | physical | | | t | 12802 | | | 0/A002340 | | 00000002000000000000000A
--pg_xlogfile_name(restart_lsn)查看当前wal日志信息

查询冲突
#

什么是查询冲突？ 备库在查询时可能会遇到如下错误 ERROR：canceling statement due to confilct with recovery

为什么会产生冲突呢？我们细想一下，比如说备库正在执行基于某个表的查询（这个查询可能是应用产生的，也可能是手动连接进行的查询），这时主库执行了drop table操作，该操作写入wal日志后传至备库进行应用，为了保证数据一致性，postgresql必然会迅速回放数据，这时drop table和select就会形成冲突。如下图所示：

冲突场景：上面只介绍了1种查询冲突的情况。总结一下有以下几种情况

主库排他锁（包括显示LOCK命令和各种DDL）
主库vacuum清理死元组，从库如果正在使用该元组，就会产生冲突
主库删除了从库查询正在使用的表空间
主库删除了从库正在使用的数据库

试想在仅有主库的情况下：场景1：一个会话发起了drop table，此时发现有select语句正在执行，那么该会话只能等待select完成其事务。场景2：一个会话发起vacuum或后台自动vacuum，不会与当前库查询发生冲突，因为vacuum不会清理正在使用的元组。

从库的处理就不同。因为主库不知道从库的事务状态，而从库又需要与主库保持一致，所以才发生了“查询冲突”

查询冲突参数 hot_standby_feedback： 这个参数是查询冲突这个话题中提到最多的参数，下面我们详细探讨一下。我们假设在没有备库的情况下，会话1查询某行数据，会话2删除该数据，然后commit，此时会话2执行一次vacuum，我们知道这次vacuum并不会删除该行数据，因为会话1的事务还需要使用该元组，所以不会清理该元组。那么如果是主从呢？主库在准备进行vacuum时怎么知道从库还在进行查询，这就是设置该参数的意义，设置hot_standby_feedback参数之后备库会定期向主库通知最小活跃事务id（xmin）值，这样使得主库vacuum进程不会清理大于xmin值的事务。这个参数有利于减少冲突的发生，但并不能完全避免冲突，其实细想一下，这个参数只是减少了由于主库vacuum死亡元组造成的冲突，并不能解决排他锁造成的冲突。或者由于网络中断造成的冲突，假如主备之间的网络中断后，备库就无法向主库正常发送xmin值，如果时间够长，主库在这段时间内还是会清理无用元组，这样网络恢复后就可能发生上面的vacuum造成的冲突。值得注意的是hot_standby_feedback参数并不会覆盖主库上old_snapshot_threshold参数限定的值，old_snapshot_threshold参数限制了死亡元组的无限膨胀，当事务信息超过old_snapshot_threshold的限制时，依然会进行清理。

max_standby_streaming_delay：备机因为接收wal流日志产生查询冲突而取消查询之前的等待时间，设置该参数会在发生冲突时，备库查询不会立即取消，而是等待一个时间后如果还没结束再抛出报错。这个值的大小可以参考备库可能产生的长事务运行时间。

max_standby_archive_delay：备机因为处理归档的wal日志产生查询冲突而取消查询之前的等待时间，和上面的参数类似。

vacuum_defer_cleanup_age：指定vacuum延迟清理死亡元组的事务数，vacuum会延迟清除无效的记录，延迟的事务个数通过vacuum_defer_cleanup_age进行设置。即vacuum和vacuum full操作不会立即清理刚刚被删除元组

可以根据pg_stat_database和pg_stat_database_conflicts视图查看冲突发生的情况

其他相关参数
#

传输参数 max_wal_senders：使用wal sender获取wal的服务最大个数，也就是从库+baseback客户端的最大个数。pg9.6默认为0，pg10以后默认为10。 wal_send_timeout:wal传输xx秒失败后中断复制。该参数在从库宕机或者网络长期中断时，wal不会再尝试传输。默认60。0表示永不中断复制 track_commit_timestamp：记录事务的时间。默认是off。

主库参数 synchronous_standby_names：在主库上配置，备机的复制列表。有下面几种方式（s1，s2，s3代表备机的application_name，配置在recovery.conf中） synchronous_standby_names=‘s1’ 代表s1备机返回就可以提交。 synchronous_standby_names=‘FIRST 2 (s1,s2,s3)’ 代表s1，s2，s3三个备机中前两个s1和s2返回主库就可以提交。 synchronous_standby_names=‘ANY 2 (s1,s2,s3)’ 代表s1，s2，s3三个备机中任意两个备机返回主库就可以提交。 synchronous_standby_names=’*’ 代表匹配任意主机，也就是任意主机返回就可以提交。 wal_level： wal日志级别，这个参数决定了有多少信息写入wal日志，默认是replica，这种模式支持复制和wal归档，同时支持备库只读查询。 minimal：除了实例crash恢复需要的记录，其他不记录，比如CREATE TABLE AS，CREATE INDEX，CLUSTER，COPY可以跳过，该模式记录的日志信息不足以支持wal归档和流复制。 logic：在replica的基础上增加一些信息以支持逻辑解码，该模式会增大wal日志的数量，尤其是大量的update，delete操作的库。在9.6之前还有archive和hot_standby模式，映射到现在的replica模式。 synchronous_commit：前面已讲过，5种模式，各有优劣。 archive_mode ：archive_mode =on表示打开归档 archive_command：归档命令，pg归档直接调用操作系统命令。可以是简单cp命令到备份端 listen_addresses：监听地址。’‘表示所有IP都监听，默认为local

从库参数 hot_standby：on表示打开从库只读 primary_conninfo：从库连接主库的连接串。如primary_conninfo = ‘host=172.17.100.150 port=5432 user=lzl password=lzl’ trigger_file/promote_trigger_file：激活备库的激活文件。pg 12以前叫trigger_file，pg12及以后为promote_trigger_file trigger_file和pg_ctl promote在激活时都是一条命令就可以完成激活备库，前面已经具体演示过 wal_receiver_create_temp_slot：当没有slot时，临时起一个slot（命为primary_slot_name）。默认是off的。

参考文档：
#

《PostgreSQL修炼之道》 https://www.postgresql.org/docs/current/warm-standby.html

https://www.postgresql.org/docs/13/high-availability.html

https://www.postgresql.org/docs/current/runtime-config-replication.html

https://www.postgresql.org/docs/13/runtime-config-wal.html

https://www.postgresql.org/docs/current/app-pgbasebackup.html

https://www.postgresql.org/docs/current/hot-standby.html#HOT-STANDBY-CONFLICT

https://cloud.tencent.com/developer/article/1555354

https://www.modb.pro/db/29737

https://wiki.postgresql.org/wiki/Streaming_Replication

https://www.percona.com/blog/2018/09/07/setting-up-streaming-replication-postgresql/

https://www.cybertec-postgresql.com/en/the-synchronous_commit-parameter/

https://blog.csdn.net/m15217321304/article/details/88850146

https://blog.51cto.com/lishiyan/2460518?source=dra

PostgreSQL逻辑复制

Tue, 13 Aug 2024 00:00:00 +0000

什么是逻辑复制
#

pg逻辑复制基于逻辑解析（logicaldecoding），将wal日志流解析成一定格式输出（output），订阅节点收到解析后的数据进行应用。

逻辑复制不同于流复制（物理复制）基于实例级别主从库物理结构上就是一样，逻辑复制可以基于表级别选择性复制。逻辑复制（Logical Replication）在官方文档里专指”复制-订阅“模式，其实有许多工具可以基于逻辑解析做异构数据库间数据同步。

pg9.4 pglogical插件可以支持逻辑复制（https://github.com/2ndQuadrant/pglogical），pg10开始原生支持逻辑复制。

逻辑复制可以用于数据库升级、异构数据迁移、表级数据同步链路、订阅数据流等等

逻辑解析
#

逻辑解析可以将wal日志中的表数据变更解析成行数据流或sql文本，这些行数据流或sql文本可以被其他类型的数据库或软件消费。而具体的解析格式由outputplugin决定。

复制槽
#

在逻辑复制中，复制槽代表着数据变更流。跟物理复制槽一样，逻辑复制槽也可以保证复制异常中断后，相关的wal日志不被删除，以保证复制重连后仍然可以继续解析wal日志。一个数据库可以有多个复制槽，一个复制槽只有一个outputplugin，一个复制槽代表一条复制链路。复制槽本质上是用来管理复制链路的。不同于流复制可以没有复制槽，逻辑复制是必须有复制槽的。

output plugin
#

output plugin转换wal日志信息成复制槽所要的格式。pg中内置了一些outputplugin，也可以通过插件添加一些额外的outputplugin。每个逻辑复制槽都有一个output plugin用于解析wal相关工作。

outputplugin使用回调函数管理解析。比如OUTPUT_PLUGIN_BINARY_OUTPUT ，OUTPUT_PLUGIN_TEXTUAL_OUTPUT 用于设置out_type是二进制还是文本。还有一些回调函数用于通知plugin事务数据变更，并把事务排序。回调函数当然不用我们人为使用，一些内置的outputplugin已经打包好了。

每个output plugin都有一些不同的解析行为和输出格式

几个常见的outputplugin
#

test_decoding：这是一个outputplugin样例，相当于output plugin原始形态。官方文档说这是一个template，但是它仍然可以解析。这个output plugin是pg自带的，但需要在contrib中编译。

pgoutput：发布订阅模式的默认outputplugin。在发布订阅中，walsender进程使用该outputplugin逻辑解码wal日志。

decoder_raw:解析成sql文本格式。这个不是pg自带的，自行编译：https://github.com/michaelpq/pg_plugins/tree/main/decoder_raw

wal2json：这个outputplugin会将wal日志信息转化为json格式

有些其他的output plugin可参考：https://wiki.postgresql.org/wiki/Logical_Decoding_Plugins

有些国内也有厂商做了自己outputplugin。

几个output plugin和逻辑复制插件的关系：

pgoutput、test_decoding、wa2json上面已经介绍了

pglogical在pg9.4是pglogical replication的前身

BDR是2ndQuadrant开发，支持双向复制、DDL同步，功能更强大，BDR3.0开始闭源

几个能手动接收解析数据的函数和工具
#

pg_logical_slot_get_changes()函数展示解析数据并消费掉;

pg_logical_slot_peek_changes()函数展示解析数据不会消费掉；

pg_recvlogical，pg自带的工具，能消费复制槽内的数据，相当于逻辑复制的下游。对应物理wal接收工具为 pg_receivewal

逻辑解析测试1：观察用2个不同的output plugin解析数据
#

--创建两个逻辑复制槽，分别使用logical_test和logical_raw

lzldb=# select pg_create_logical_replication_slot('logical_test','test_decoding');

 pg_create_logical_replication_slot 

------------------------------------

 (logical_test,0/1756F50)

lzldb=# select pg_create_logical_replication_slot('logical_raw','decoder_raw');

 pg_create_logical_replication_slot 

------------------------------------

 (logical_raw,0/1756F88)

--只创建上游，slot是f状态

lzldb=# select * from pg_replication_slots; 

 slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size 

--------------+---------------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------

 logical_test | test_decoding | logical | 16385 | lzldb | f | f | | | 558 | 0/1766878 | 0/17668B0 | reserved | 

 logical_raw | decoder_raw | logical | 16385 | lzldb | f | f | | | 557 | 0/1756F50 | 0/1756F88 | reserved | 

--创建一张表

lzldb=# create table tdecoder222(a int,b varchar(10));

CREATE TABLE

--尝试获得这个ddl

lzldb=# SELECT * FROM pg_logical_slot_get_changes('logical_raw', NULL, NULL, 'include-xids', '0');

ERROR: option "include-xids" = "0" is unknown

CONTEXT: slot "logical_raw", output plugin "decoder_raw", in the startup callback

lzldb=# SELECT * FROM pg_logical_slot_get_changes('logical_test', NULL, NULL, 'include-xids', '0');

 lsn | xid | data 

-----------+-----+--------

 0/17669C8 | 558 | BEGIN

 0/1776778 | 558 | COMMIT

--能看出decoder_raw完全没有解析ddl，logical_test只是获取了ddl的事物，没有ddl语句本身，相当于没解析ddl

--插入一条数据

lzldb=# insert into tdecoder222 values(1,'lzl'); 

INSERT 0 1

lzldb=# select * from pg_logical_slot_peek_changes('logical_test',null,null);

 lsn | xid | data 

-----------+-----+---------------------------------------------------------------------------

 0/1776890 | 560 | BEGIN 560

 0/1776890 | 560 | table public.tdecoder222: INSERT: a[integer]:1 b[character varying]:'lzl'

 0/1776900 | 560 | COMMIT 560

lzldb=# select * from pg_logical_slot_peek_changes('logical_raw',null,null);

 lsn | xid | data 

-----------+-----+----------------------------------------------------------

 0/1776890 | 560 | INSERT INTO public.tdecoder222 (a, b) VALUES (1, 'lzl');

--test_decoding解析了事物

--decoder_raw把事务解析成了sql语句

这个测试可以得出结论：

1.复制槽在f状态仍会解析，等待下游消费

2.每个output plugin都有一些不同的解析行为和输出格式

逻辑解析测试2：使用pg_recvlogical工具接收逻辑解析数据，模拟一个逻辑复制链路
#

--配置免密登陆

[pg@lzl ~]$ vi .pgpass

[pg@lzl ~]$ cat .pgpass

lzl:5410:lzldb:pg:pg

[pg@lzl ~]$ chmod 0600 .pgpass

--启动pg_recvlogical

[pg@lzl ~]$ pg_recvlogical -h lzl -p 5410 -d lzldb -U pg --slot=logical_raw --start -f recv.sql &

[pg@lzl ~]$ ps -ef|grep recv|grep -v grep

pg 7747 7355 0 21:40 pts/3 00:00:00 pg_recvlogical -h lzl -p 5410 -d lzldb -U pg --slot=logical_raw --start -f recv.sql

lzldb=# insert into tdecoder222 values(2,'qwe');

INSERT 0 1

lzldb=# update tdecoder222 set b='asd' where a=2;

UPDATE 1

[pg@lzl ~]$ tail -2f recv.sql

INSERT INTO public.tdecoder222 (a, b) VALUES (2, 'qwe');

--update没有正确解析

--给表加主键

lzldb=# alter table tdecoder222 add primary key(a);

ALTER TABLE

lzldb=# insert into tdecoder222 values(100,'lzl1');

INSERT 0 1

lzldb=# insert into tdecoder222 values(200,'lzl2');

INSERT 0 1

lzldb=# update tdecoder222 set b='lzlupdate' where a=200;

UPDATE 1

[pg@lzl ~]$ tail -3f recv.sql

INSERT INTO public.tdecoder222 (a, b) VALUES (100, 'lzl1');

INSERT INTO public.tdecoder222 (a, b) VALUES (200, 'lzl2');

UPDATE public.tdecoder222 SET a = 200, b = 'lzlupdate' WHERE a = 200;

–加了主键后update被decoder_raw正确解析

–没有主键不会正确解析，这跟replicaidentity复制标识相关，后面会介绍

逻辑复制的前置条件
#

1.参数
#

1.1基本的必要参数

wal_level。重启生效，默认是replica。wal_level参数必须是logical。logical不是把wal改成逻辑的，它表示在支持物理复制（replica）的基础上增加逻辑解析所必要的信息。在pg9.6以后只有minimal、replica、logical，信息量依次递增。
max_replication_slots。重启生效，在pg9.6版本以下默认值为0，pg10以上为10，10个一般都够了。与物理复制相同，逻辑复制一般也要用到复制槽。pg的备份、物理复制均可以占用到复制槽的数量。

1.2源端必要参数

max_wal_senders。重启生效，默认10。sender进程数限制，发布端的sender传递解析后的日志。一般一个逻辑复制槽对应了一个sender和一个worker。这个跟物理复制类似，一个物理复制对应一个sender和一个receiver。

1.3目标端必要参数

max_worker_processes。重启生效，默认8。工作进程数限制。并行进程（并行查询、并行统计信息收集等，这些并行进程由 max_parallel_workers限制）、逻辑复制工作进程（max_logical_replication_workers）和一些其他需要forkworker的程序均与该参数有关。应该设置为max_parallel_workers+逻辑复制应用端worker+其他后台worker。
max_logical_replication_workers。重启生效，默认4。逻辑复制工作进程数，包括逻辑复制的应用工作进程和表同步工作进程。
max_sync_workers_per_subscription。reload生效，默认2。逻辑同步新增表时同步工作进程，目前一张表只有一个并行。
以上三个参数是梯度式的max_sync_workers_per_subscription<max_logical_replication_workers<max_worker_processes。总之得有worker可用。

2 权限
#

复制用户的权限。逻辑复制的用户需要有replication权限。

ALTER ROLE <usename>WITH REPLICATION;

hba访问限制，允许下游使用复制用户访问数据库

host lzldb user1 172.17.100.150/32 md5

对于发布订阅模式。需要database上的create权限或ssuperuser权限。

在创建发布时只有fortable至少需要带create权限的表owner，其余发布都必须要superuser

在创建订阅时必须要superuser。

grant create on database lzl1db to owner1; 或者

alter user replicate1 superuser;

另外复制过程中表的读或写权限也是必要的。

pg间的逻辑同步——发布与订阅
#

pg的内置逻辑复制基于发布订阅模型。发布与订阅模式不是解析成sql应用。

发布
#

发布者可以有多个发布，每个发布可以有多个表。
发布时可以指定

for table 发布某些表，新增表需要显示添加ALTER PUBLICATION ADD TABLE。创建此发布至少是表的owner。

for all tables 发布database下的所有表，新增表自动发布。创建此发布必须是superuser

for all tables in schema 发布schema下的所有表，新增表自动发布。创建此发布必须是superuser。pg15开始支持

发布默认包含INSERT, UPDATE, DELETE, and TRUNCATE，也可以指定复制某些命令。不同步DDL。（官方文档原话。也就是说truncate在pg里面不算ddl，这个留坑后面再研究。truncate在mysql和oracle中是ddl）
只能发布基表；临时表、外部表、视图、序列等等都不能发布。分区表发布与pg版本和分区属性有关，pg15默认发布分区表所有分区
publish_via_partition_root。pg13开始支持。该发布参数表示分区表使用分区进行过滤（fales，默认）还是用户父分区进行行过滤。如果设置为true，那么支持了异构分区表逻辑复制，比如分区表到普通表的复制。true时不能进行truncate复制。

订阅
#

一个订阅只有一个发布者，但可订阅发布者上的多个发布。
订阅者可以有多个订阅，每个订阅都会从一个复制槽中接收数据。
一个订阅对应一个复制槽，这个复制槽在发布端。
在创建或删除订阅时，默认自动在发布者创建或删除复制槽。
创建订阅必须要superuser
DDL不会被同步，表必须是已建好的。
存量数据默认同步，存量数据通过copy的方式快照拷贝到订阅者
同步可以暂停和继续ALTER SUBSCRIPTION sub1 {ENABLE|DISABLE}
当发布新增表后，需要在订阅端refresh。alter subscription sub1 refresh publication
发布和订阅的表schema名、表名、字段名必须一致，字段类型可以不一致（只要能隐式转换成功），字段顺序可以不一致。
订阅还有些属性，比如二进制传输、流传输、同步提交、两阶段提交等

logicalreplication launcher是用来启动订阅端的worker进程的，只在启动时存在

/*-------------------------------------------------------------------------
...
 * IDENTIFICATION

 * src/backend/replication/logical/launcher.c
...
 * NOTES
 * This module contains the logical replication worker launcher which
 * uses the background worker infrastructure to start the logical
 * replication workers for every enabled subscription.
 *-------------------------------------------------------------------------

 */

发布订阅相关视图
#

pg_publication; –查看发布。发布本身是无状态的，复制槽是有状态的，所以没有pg_stat_publication

pg_publication_tables –查看发布的表，简单明了

pg_publication_rel –查看发布的表，都是id

pg_stat_subscription –查看订阅状态，pid是worker进程的pid

pg_subscription –查看订阅

pg_subscription_rel –查看订阅表，没有pg_subscription_tables。另外该视图可以查看订阅下面各个表的同步情况，这是复制槽视图做不到的

\dRp list replication publications

\dRs list replication subscriptions

创建一个发布和订阅
#

用专门的复制用户replicate1，在库lzldb下创建一个发布和订阅，实现逻辑复制表trep1

`角色`	`主机ip`	`端口`	`库名`	`schema`	`表名`	`复制用户`	`版本`
`发布节点`	`172.17.100.150`	`5410`	`lzldb`	`public`	`trep1`	`replicate1`	`pg13`
`订阅节点`	`172.17.100.150`	`5412`	`lzlbd`	`public`	`trep1`	`replicate1`	`pg13`

创建发布
#

#修改postgres.conf，wal_level参数重启生效

wal_level=logical 

#修改pg_hba.conf文件,reload生效

host lzldb replicate1 172.17.100.150/32 md5

--创建复制用户并赋权

create user replicate1 with password 'replicate1';

alter user replicate1 with replication;

grant create on database lzldb to replicate1;

--创建要复制的表并授权给复制用户

\c lzldb replicate1 --如果复制用户不是表的owner，应该授权grantselect on trep1 to replicate1

create table trep1(a int primary key,b char(10));

insert into trep1 values(1,'abc') 

--创建发布，用superuser用户也可以

\c lzldb replicate1

create publication pub_lzl1 for table trep1;

--查看发布。\dRp或pg_publication
lzldb=# select * from pg_publication;

 oid | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot 

-------+----------+----------+--------------+-----------+-----------+-----------+-------------+-----------

 16400 | pub_lzl1 | 16392 | f | t | t | t | t | f

创建订阅
#

--创建表定义

create table trep1(a int primary key,b char(10));

--用superuser用户创建订阅

CREATE SUBSCRIPTION sub_test

CONNECTION 'host=172.17.100.150 port=5410 dbname=lzldb user=replicate1 password=replicate1'

PUBLICATION pub_lzl1;

lzlbd=# select * from pg_subscription; --查看订阅。\dRs或pg_subscription

 oid | subdbid | subname | subowner | subenabled | subconninfo | subslotname | subsynccommit | subpublications 

-------+---------+----------+----------+------------+--------------------------------------------------------------------------------+-------------+---------------+-----------------

 16394 | 16384 | sub_test | 10 | t | host=172.17.100.150 port=5410 dbname=lzldb user=replicate1 password=replicate1 | sub_test | off | {pub_lzl1}

lzlbd=# select * from trep1;--查看存量数据已同步

 a | b 

---+------------

 1 | abc

发布订阅模式测试1:truncate同步
#

lzldb=# truncate table trep1;

TRUNCATE TABLE

lzldb=# select * from trep1;

 a | b 

---+---

(0 rows)

lzlbd=# select * from trep1; --发布订阅模式，truncate可以同步

 a | b 

---+---

(0 rows)

发布订阅模式测试2:新增表同步
#

--在已有发布订阅下，新增一个表同步。lzldb是发布者，lzlbd是订阅者

lzldb=# create table tab_pk(a int,b varchar(10));

CREATE TABLE

lzldb=# alter table tab_pk add primary key(a);

ALTER TABLE

lzldb=# alter publication pub_lzl1 add table tab_pk;

ALTER PUBLICATION

--发布端新增表后需要在订阅端执行refresh，refresh默认同步存量数据

lzlbd=# alter subscription sub_test refresh publication; 

ALTER SUBSCRIPTION

lzlbd=# select * from pg_subscription_rel ;

 srsubid | srrelid | srsubstate | srsublsn 

---------+---------+------------+-----------

 16394 | 16389 | r | 0/15F2898

 16394 | 16400 | d | 

--订阅的状态码： i = 初始化， d =正在复制数据， s = 已同步， r =准备好(普通复制)

--此时表tab_pk数据并没有同步，因为订阅端复制用户缺少查询表的权限

lzldb=# grant select on tab_full to replicate1;

GRANT

lzlbd=# select * from pg_subscription_rel ;

 srsubid | srrelid | srsubstate | srsublsn 

---------+---------+------------+-----------

 16394 | 16389 | r | 0/15F2898

 16394 | 16400 | r | 0/172D830

--订阅为ready状态，新增表同步完成

replica identity复制标识
#

复制标识写进wal日志以标识一行数据。无论是发布订阅还是第三方逻辑同步工具，都需要定位表中的行，以标识update、delete到底作用在下游的哪一条数据。 pg中可以设置4种复制标识模式。

default(d) 非系统表的默认标识。表有主键就用主键，如果没有主键就是nothing
index(i) 将一个非空唯一索引作为标识。必须是非空且唯一，这样才能标识一行。如果只是唯一，可以有多个空值。其实也可以显示指定主键为index模式。
full(f) 将行的所有列作为标识。full模式会增大wal日志量
nothing(n) 系统表的默认模式，没有标识，update、delete无法作用到下游

查看表的复制标识：
select relname,relreplident from pg_class where relname='tabname1';
当表的复制标识是i时，查看索引是否是复制标识
\d tabname
select rel.relname,idx.indisreplident from pg_index idx ,pg_class rel where idx.indexrelid=rel.oid and relname='idx_1';

修改表的复制标识：

ALTER TABLE tab1REPLICA IDENTITY { DEFAULT | USING INDEX index_name | FULL | NOTHING };

复制标识测试1：将一个没有主键的表的复制标识设置为非空唯一索引
#

lzldb=# create table tab_idx(a int,b varchar(10));

CREATE TABLE

lzldb=# select relname,relreplident from pg_class where relname='tab_idx';

 relname | relreplident 

---------+--------------

 tab_idx | d

lzldb=# create unique index idx_1 on tab_idx(b);

CREATE INDEX

lzldb=# alter table tab_idx alter b set not null; --当做复制标识的索引必须是非空唯一索引

ALTER TABLE

lzldb=# select rel.relname,idx.indisreplident from pg_index idx ,pg_class rel where idx.indexrelid=rel.oid and relname='idx_1';

 relname | indisreplident 

---------+----------------

 idx_1 | f

lzldb=# alter table tab_idx REPLICA IDENTITY using index idx_1; --修改表的复制标识

ALTER TABLE

lzldb=# select rel.relname,idx.indisreplident from pg_index idx ,pg_class rel where idx.indexrelid=rel.oid and relname='idx_1';

 relname | indisreplident 

---------+----------------

 idx_1 | t

lzldb=# \d tab_idx --pg_index或者\d查看索引复制标识，\d只能查看显示修改的索引复制标识

 Table "public.tab_idx"

 Column | Type | Collation | Nullable | Default 

--------+-----------------------+-----------+----------+---------

 a | integer | | | 

 b | character varying(10) | | not null | 

Indexes:

 "idx_1" UNIQUE, btree (b) REPLICA IDENTITY

复制标识测试2：full模式，多条重复数据时，是否可以正常同步
#

--发布端执行一下命令

lzldb=# create table tab_full (a int,b varchar(10)); --添加一个无主键和非空索引的表同步

CREATE TABLE

lzldb=# insert into tab_full values(1,'abc'); --插入相同的5条数据

INSERT 0 1

lzldb=# grant select on tab_full to replicate1;

GRANT

lzldb=# alter publication tab_full add table tab_pk;

ALTER PUBLICATION

--

lzlbd=# alter subscription sub_test refresh publication; 

ALTER SUBSCRIPTION

lzlbd=# select ctid,* from tab_full ;

 ctid | a | b 

-------+---+-----

 (0,1) | 1 | abc

 (0,2) | 1 | abc

 (0,3) | 1 | abc

 (0,4) | 1 | abc

 (0,5) | 1 | abc

lzldb=# delete from tab_full where ctid='(0,2)';

ERROR: cannot delete from table "tab_full" because it does not have a replica identity and publishes deletes

HINT: To enable deleting from the table, set REPLICA IDENTITY using ALTER TABLE.

lzldb=# update tab_full set a=2 where ctid='(0,5)';

ERROR: cannot update table "tab_full" because it does not have a replica identity and publishes updates

HINT: To enable updating the table, set REPLICA IDENTITY using ALTER TABLE.

--当表的replica identity是d(default)时，没有主键就是nothing。nothing无法复制delete和update。

lzldb=# alter table tab_full replica identity full;

ALTER TABLE

lzldb=# delete from tab_full where ctid='(0,2)'; --复制标识设置为full后，删除成功

DELETE 1

lzlbd=# select ctid,* from tab_full ; --

 ctid | a | b 

-------+---+-----

 (0,2) | 1 | abc

 (0,3) | 1 | abc

 (0,4) | 1 | abc

 (0,5) | 1 | abc

lzldb=# update tab_full set a=2 where ctid='(0,5)'; 

UPDATE 1

lzldb=# select ctid,* from tab_full; 

 ctid | a | b 

-------+---+-----

 (0,1) | 1 | abc

 (0,3) | 1 | abc

 (0,4) | 1 | abc

 (0,6) | 2 | abc

lzlbd=# select ctid,* from tab_full ; 

 ctid | a | b 

-------+---+-----

 (0,3) | 1 | abc

 (0,4) | 1 | abc

 (0,5) | 1 | abc

 (0,6) | 2 | abc

–这个例子可以证明3个点

–1.当复制标识为d(default)时，默认用主键，如果没有主键就是nothing

–2.nothing不能复制delete和update

–3.full时的重复数据也可以正常逻辑复制，虽然数据行的ctid不一样，但是也达到了复制目的

第三方同步软件
#

第三方同步软件已经有比较成熟的方案，而且使用比较多，比如ogg、dts、ktl等等

这些同步软件非常灵活，他们可以实现真正的异构同步，可以从pg库同步到不同的数据库或者kafka、大数据消费平台等等。

当然也可以从其他架构的数据平台同步到pg库里，比如如今场景比较多的oracle到pg的同步。

因为我们这里主要讨论pg数据库本身，当pg充当下游入库时，只是一些数据写入问题，问题非常少，不会有逻辑解析、复制槽等等问题，所以这一小章节不讨论pg作为异构同步下游的情况，只观察和总结pg作为上游往异构数据库同步的场景。这些第三方软件一般都利用了pg自身的逻辑解析，自行指定outputplugin并自动创建复制槽和复制链路，有些软件自动创建了订阅，而有些就没有订阅只有复制槽。

前面已经了解了逻辑解析、outputplugin、复制槽、replicaidentity、复制的前置条件等知识点，下面模拟一个pg到oracle的同步，直接将前置条件配置好开始同步。

创建ogg同步pg到oracle的同步
#

安装软件：

ogg for oracle：Oracle GoldenGate 21.3.0.0.0 for Oracle on Linux x86-64

ogg for pg ：Oracle GoldenGate 21.3.0.0.0 for PostgreSQL on Linux x86-64

oracle ：11.2.0.4

pg ：13.10

安装步骤：

ogg的安装和部署就不介绍了，我也是参照文章的安装步骤一步步搭建，安装文章参考：https://liuzhilong.blog.csdn.net/article/details/129252320?spm=1001.2014.3001.5502

同步架构图：

lzldb=# select * from pg_replication_slots where slot_name='ext_pg_5d4b1d39f7494f79';

-[ RECORD 1 ]-------+------------------------

slot_name | ext_pg_5d4b1d39f7494f79

plugin | test_decoding --ogg默认使用test-decoding

slot_type | logical

datoid | 16385

database | lzldb

temporary | f

active | t --只要ogg extract是running的，复制槽就是active状态

active_pid | 3509

xmin | 

catalog_xmin | 591

restart_lsn | 0/17F3E38

confirmed_flush_lsn | 0/17F4020

wal_status | reserved

safe_wal_size | 

select * from pg_stat_replication

-[ RECORD 2 ]----+------------------------------

pid | 3509

usesysid | 10

usename | pg

application_name |GoldenGateCapture

client_addr | 127.0.0.1

client_hostname | 

client_port | 43665

backend_start | 2023-02-28 15:12:17.350469+08

backend_xmin | 

state | streaming

sent_lsn | 0/17F4140

write_lsn | 0/17F4020

flush_lsn | 0/17F4020

replay_lsn | 

write_lag | 

flush_lag | 

replay_lag | 

sync_priority | 0

sync_state | async

reply_time | 2023-02-28 16:39:44.986625+08

--replay_lsn没有值

--连lag都没有值

逻辑复制监控
#

逻辑复制延迟监控有一个重要的手段是从复制软件看延迟。如果没有就只有从复制槽视图查看，复制槽视图的信息是比较多的，比如复制槽是否active就直接代表了复制链路是否在同步。

复制槽视图对于逻辑复制监控非常重要，发布订阅的一些额外监控前面已介绍过，这里着重介绍宽泛的逻辑复制的监控

pg_replication_slots
#

复制槽视图，每个复制槽的信息和一些复制槽状态。手工创建复制槽或者工具、订阅自动创建了复制槽，都会在这里展示

slot_name	复制槽名
plugin	逻辑复制槽output plugin的名字，如果是空那么就是物理复制槽
slot_type	physical or logical
datoid	逻辑复制槽的database id
database	逻辑复制槽的database
temporary	是否是临时复制槽。临时复制槽不会写到磁盘，会话结束临时复制槽自动删除。pg_basebackup默认使用的就是临时复制槽
active	复制槽状态 t or f。如果是f，需要尽快考虑把复制链路拉起或者删除，因为可能阻碍wal日志删除导致主库磁盘打满，这个跟参数max_slot_wal_keep_size相关
active_pid	使用复制槽的walsender pid。当复制槽状态是t的时候，才有walsender pid
xmin	复制槽需要持有的最小事务id
catalog_xmin	复制槽需要持有的catalog最小事务id
restart_lsn	slot需要保留的wal的位置lsn号，以确保下游消费端需要的wal不会被清理。max_slot_wal_keep_size 参数是slot需要保留wal的最大大小，超过这个值wal也能被删除，默认值-1表示不会清理。这个值表示下游最新checkpoint消费后的lsn位置，可以帮助定位复制链路的延迟
confirmed_flush_lsn	逻辑复制下游确认接收的lsn。物理复制槽为空
wal_status	`被这个复制槽申明的wal的状态` reserved 代表复制槽保留了wal，wal没有超过max_wal_size(自动检查点间距） extended 代表复制槽保留了wal，wal超过了max_wal_size，但是复制槽仍保留了wal。此状态的wal仍在wal_keep_size或max_slot_wal_keep_size内 unreserved 复制槽不再保留需要wal，在下个checkpoint即将删除wal lost 复制槽需要的wal已被清理，复制槽已无效 `The last two states are seen only when max_slot_wal_keep_size is non-negative。比较好理解，毕竟max_slot_wal_keep_size是判断是否可以删除wal的标准。如果没有删除slot wal的机制，那就不会出现ureserved和lost两种状态。` `If restart_lsn is NULL, this field is null.也比较好理解，如果wal的lsn都没有就不知道wal保留的位置，也无法判断wal是否超过了wal_keep_size或max_slot_wal_keep_size`
safe_wal_size	到在被删除WAL文件之前，可以写入的WAL字节数。如果这个值是负数或者是0，意味着已经超过了max_slot_wal_keep_size设置的值，只要做检查点，就会删除wal文件，这样使用插槽的备库就必须重建了

pg_stat_replication
#

与其说是复制状态，其实walsender状态更准确。该视图展示每个walsender的状态，一个walsender一条记录。

如果pg_replication_slots中有而pg_stat_replication中没有，那么说明walsender不在了，逻辑复制挂了，pg_replication_slots active应该是f
如果pg_replication_slots中没有而pg_stat_replication中有，那么说明这是个不带复制槽的物理复制

没有复制槽也可以有replicationstat信息，有walsender的复制槽也需看该视图，因为该视图比pg_replication_slots揭示更多复制状态信息

所以当复制槽没有挂时，pg_stat_replication对于监控逻辑复制延迟非常重要

pid	walsender pid ，同pg_replication_slotsactive_pid
usesysid	连入这个walsender的user oid，也就是下游使用的复制用户oid
usename	连入这个walsender的usename
application_name	下游的的应用程序名称。如果是订阅，那么就是订阅名。如果是pg_recvlogical就是pg_recvlogical
client_addr	下游的IP，如果是空就是本地socket连接
client_hostname	下游的主机名
client_port	下游的端口，如果是-1就是本地socket连接
backend_start	backend启动时间，也就是下游连入walsender的时间
backend_xmin	hot_standby_feedback打开时，standby的xmin。这个明显是物理复制的
state	状态比较简单易懂 startup: walsender正在启动 catchup: walsender正在追主库日志 streaming: walsender已经追上了主库日志，正常复制状态 backup: walsender在发送备份，这个状态出现在备份使用的walsender stopping: walsender正在停止
sent_lsn	发送的lsn
write_lsn	下游write到磁盘的lsn
flush_lsn	下游flush到磁盘的lsn
replay_lsn	下游重放的lsn
write_lag	主库flush wal和下游write之间的日志lag
flush_lag	主库flush wal和下游flush之间的日志lag
replay_lag	主库flush wal和下游relay之间的日志lag
sync_priority	同步优先级
sync_state	同步状态
reply_time	上次答复时间

sent_lsn、write_lsn、flush_lsn、replay_lsn的关系
#

上面很好的展示了sent_lsn、write_lsn、flush_lsn的层级关系

这些监控指标看上去很像流复制的，对于逻辑复制来说sent_lsn、write_lsn、flush_lsn也一般都有值

但是在逻辑复制不清楚下游是什么东西的情况下，replay这个日志回放动作可能是没有的，所以逻辑复制可能没有replay_lsn

但是有一个东西是确认有效的，就是sent_lsn

看完pg_replication_slots和pg_stat_replication视图监控，发现都没有展示日志解析延迟，最多只能看到日志传输延迟

pg_stat_replication_slots
#

这个视图从pg14开始才有，这个视图专门监控逻辑复制槽状态，可以额外监控spill的状态。pg13只有查看pg_replslot目录。spill后面会介绍

逻辑复制槽的事务快照和pg_logical目录
#

复制槽所需的事物快照会持久化到磁盘，源码在snapbuild.c中

void
SnapBuildSerializationPoint(SnapBuild *builder, XLogRecPtr lsn)
{
if (builder->state < SNAPBUILD_CONSISTENT)
SnapBuildRestore(builder, lsn);
else
SnapBuildSerialize(builder, lsn);
}

snap持久化有2种行为：一种是restore从磁盘加载到内存，一种是serialize从内存持久化到磁盘

事物快照持久化：

SnapBuildSerialize(SnapBuild *builder, XLogRecPtr lsn)
...
sprintf(path, "pg_logical/snapshots/%X-%X.snap",
(uint32) (lsn >> 32), (uint32) lsn);
...
else if (ret == 0)
{
/*
 * somebody else has already serialized to this point, don't overwrite
 * but remember location, so we don't need to read old data again.
 *
 * To be sure it has been synced to disk after the rename() from the
 * tempfile filename to the real filename, we just repeat the fsync.
 * That ought to be cheap because in most scenarios it should already
 * be safely on disk.
 */
fsync_fname(path, false);
fsync_fname("pg_logical/snapshots", true);

builder->last_serialized_snapshot = lsn;
goto out;
}

事物快照加载到内存：

SnapBuildRestore(SnapBuild *builder, XLogRecPtr lsn)
...
if (builder->state == SNAPBUILD_CONSISTENT)
return false;

sprintf(path, "pg_logical/snapshots/%X-%X.snap",
(uint32) (lsn >> 32), (uint32) lsn);

fd = OpenTransientFile(path, O_RDONLY | PG_BINARY);

逻辑复制槽需要的事物在未提交以前，会将事物脏数据和未消费的数据存放在pg_logical/snapshots/ 下面。在提交数据或启动复制槽后交给reorderbuffer：或者清理复制槽后，数据被释放

我的环境有一个长时间未启用的slot，它的restart_lsn为0/1776858

postgres=# select slot_name,plugin,slot_type,database,active,restart_lsn from pg_replication_slots where slot_name='logical_test';
 slot_name | plugin | slot_type | database | active | restart_lsn 
--------------+---------------+-----------+----------+--------+-------------
 logical_test | test_decoding | logical | lzldb | f | 0/1776858

pg_logical/snapshots/下最旧的snapshot就是它

[pg@lzl snapshots]$ ll
total 300
-rw------- 1 pg pg 144 Feb 23 20:410-1776858.snap
-rw------- 1 pg pg 144 Feb 23 20:44 0-1776900.snap
-rw------- 1 pg pg 144 Feb 23 20:45 0-1776938.snap

删除不要的复制槽

select pg_drop_replication_slot('logical_test');

等了几分钟snap被删除

[pg@lzl snapshots]$ ll 0-1776858.snap
ls: cannot access 0-1776858.snap: No such file or directory

逻辑解析工作内存和溢出到pg_replslot
#

logical_decoding_work_mem
#

pg13以前，逻辑解析的最多会在内存中保留4096条变更（max_changes_in_memory代码中写死），超过4096条变更，事务数据会写入磁盘

pg13引入参数logical_decoding_work_mem。逻辑解析使用的工作内存，所有walsender解析都会使用这个共享内存区。如果逻辑解析持有的数据大过该内存值，会写入磁盘。逻辑解析工作内存大小默认64m。

总结
#

逻辑复制通过复制槽管理，一个复制槽一个walsender进程，一个outputplugin
output plugin决定了逻辑解析后的数据输出形态，在创建复制槽时指定
复制标识replicaidentity建议优先:主键->非空唯一索引->full
发布订阅模式是pg内置的逻辑复制，默认使用pgoutput。发布可以单独使用
发布端进程是walsender，订阅端进程是worker。需要关注各自进程的参数
逻辑复制第三方软件较多，他们一般都使用pg逻辑解析这套体系
监控复制链路需要关注pg_replication_slots,pg_stat_replication
pg_logical目录会存放事务解析的元数据snap，等待事务提交后解析
pg_replslot目录会存放超过logical_decoding_work_mem的事物信息，称为spill

参考资料
#

书：《postgreSQL实战》

官方文档：

PostgreSQL: Documentation: 15: Chapter 49. Logical Decoding

PostgreSQL: Documentation: 15: 49.1. Logical Decoding Examples

PostgreSQL: Documentation: 15: pg_recvlogical

PostgreSQL: Documentation: 14: 52.81. pg_replication_slots

PostgreSQL: Documentation: 13: 19.6. Replication

PostgreSQL: Documentation: 13: 48.6. Logical Decoding Output Plugins

PostgreSQL: Documentation: 15: 31.1. Publication

PostgreSQL: Documentation: 15: 31.2. Subscription

PostgreSQL: Documentation: 15: CREATE PUBLICATION

Logical replication internals | Select * from Adrien

An Overview of Logical Replication in PostgreSQL - Highgo Software Inc.

从实际案例聊聊逻辑解码

折磨许久的逻辑解码异常

Monitoring replication: pg_stat_replication - CYBERTEC

其他资料：

https://zhuanlan.zhihu.com/p/311496301

A Guide to PostgreSQL Change Data Capture - DZone

Change data capture in Postgres: How to use logical decoding and wal2json - Microsoft Community Hub

PgSQL · PostgreSQL 逻辑流复制技术的秘密 · 数据库内核月报 · 看云

剖析postgresql逻辑复制原理_postgresql 逻辑复制_麒思妙想的博客-CSDN博客

http://pigsty.cc/zh/blog/2021/03/03/postgres逻辑复制详解/

Logical replication and logical decoding - Azure Database for PostgreSQL - Flexible Server | Microsoft Learn

Linux内存浅析

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

内存的基本概念
#

操作系统内存非常重要且比较复杂，其中有许多知识点仍然需要掌握才能更进一步分析程序问题。由于是初次全面系统地接触OS内存，目的是为了全面且低层次地理解linux内存相关概念，不会深入其中原理，所以本章也会尽量避免linux的源码知识。

物理内存和虚拟内存
#

(https://en.wikipedia.org/wiki/Memory_address)

物理内存（Physical memory）：物理内存是计算机系统中实际存在的硬件内存，通常是RAM（随机存取存储器）的形式。

虚拟内存（Virtual memory）：虚拟内存是一个线性区，并没有分配实际物理内存，程序认为它们有比实际物理内存更大的地址空间。虚拟内存的实现允许程序访问比物理内存更大的地址范围，而不需要所有数据都同时存在于物理内存中。内核释放物理页面是通过释放线性区，找到其所对应的物理页面，将其全部释放的过程。

内存管理单元（Memory Management Unit，MMU）：是一个硬件组件，负责将程序中使用的虚拟地址转换为实际在物理内存中存储数据的物理地址。MMU的主要任务是执行地址映射。

页表（Page Table）：页表是一种数据结构，用于存储虚拟地址空间与物理地址空间之间的映射关系。程序试图访问虚拟内存时，MMU通过查询页表确定相应的物理地址。

系统调用流程： https://users.cs.utah.edu/~aburtsev/cs5460/lectures/lecture19-memory-management/lecture19-memory-management.pdf

（图有点糊，最上面的字是 “User Space|Kernel Space”）

用户程序通过C库或通过系统调用才能访问内核系统，用户程序不能直接访问内核系统
内核系统通过MMU访问物理内存；通过驱动访问磁盘其他外部设备
虚拟内存系统（上图中的VM Subsystem）中包含buddy、slab算法等

用户空间和内核空间
#

进程虚拟地址空间分成了用户空间和内核空间。

用户空间：

用户进程在内存中运行的空间
这部分空间被保护，系统防止其他进程访问。（共享内存除外）
但是内核进程可以直接访问用户进程

内核空间：

内核空间是内核进程使用的空间
在内核空间，运行操作系统的内核代码，这些代码具有更高的特权级别，可以直接访问系统硬件、管理进程、进行文件系统操作等

上下文切换：

当用户程序需要访问系统服务或执行需要更高权限的操作时，会触发从用户空间到内核空间的上下文切换。
上下文切换是一种操作系统机制，用于保存和恢复程序的状态，确保在用户程序和内核之间切换时不会发生数据丢失。

用户空间和内核空间的划分是为了提供安全隔离，防止用户程序直接影响操作系统的关键部分。早期的操作系统和Dos系统不区分内核、用户空间，一个程序的错误或恶意行为可能对整个系统造成影响。

(https://www.zhihu.com/tardis/zm/art/66794639?source_id=1003)

32位系统：总共4GB地址空间，3G UserSpace|1G KernelSpace

64位系统：总共256TB地址空间，128T UserSpace|128T KernelSpace

2^32=4GB，2^64=16777216TB，为什么是64位的系统是256TB地址空间呢？

64-bit computing wiki上有解释。简而言之，256TB (256 × 1024^4 bytes) 的内存地址足够了，目前以及能想象的未来还不会出现16EB (16 × 1024^6 bytes)的内存。

进程虚拟地址空间
#

每个进程通常都有自己的独立虚拟内存空间。虚拟内存是一种抽象概念，为每个运行的进程提供了似乎是连续且私有的地址空间，使得每个进程都感觉自己拥有整个计算机系统的全部内存。

进程虚拟地址空间分布：

（https://www.sohu.com/a/392831824_467784）

mmap 映射区域至顶向下扩展，mmap 映射区域和堆相对扩展，直至耗尽虚拟地址空间中的剩余区域，这种结构便于C运行时库使用mmap 映射区域和堆进行内存分配。
栈区(Stack)：存储程序执行期间的本地变量和函数的参数，从高地址向低地址生长
堆区(Heap)：动态内存分配区域，通过 malloc、new、free 和delete 等函数管理
未初始化变量区(BSS)：存储未被初始化的全局变量和静态变量
数据区(Data)：存储在源代码中有预定义值的全局变量和静态变量
代码区(Text)：存储只读的程序执行代码，即机器指令。

进程虚拟地址空间分布和映射：

(https://velog.io/@mysprtlty/%EA%B0%80%EC%83%81-%EB%A9%94%EB%AA%A8%EB%A6%AC%EC%99%80-%EA%B0%80%EC%83%81-%EC%A3%BC%EC%86%8C-%EA%B3%B5%EA%B0%84)

共享内存
#

前面讲到，虚拟地址空间中的用户空间不能被其他用户进程访问，如果通过内核区域实现多进程的用户访问同一内存数据，那么无法避免上下文切换。多进程的应用程序明显需要进程间的相互访问，所以一种直接可以实现用户进程访问同一物理内存的方法便应运而生，这就是共享内存。

共享内存是实现进程相互访问IPC（inter process communication）的机制之一，其他的方式还有message queues和semaphores。

（https://www.geeksforgeeks.org/inter-process-communication-ipc/）

由于本身就是多个虚拟内存地址空间对应一个物理内存地址空间，所以只要把两个进程的地址空间中的一段指向同一物理内存即可。

（https://www.softprayog.in/programming/interprocess-communication-using-system-v-shared-memory-in-linux）

共享内存（seems like）有许多实现方式，例如postgresql默认是mmap来实现共享内存，参考shared_memory_type参数和Managing Kernel Resources。其他的共享内存实现可参考这篇文章：宋宝华：世上最好的共享内存(Linux共享内存最透彻的一篇)

页表 PAGE TABLE
#

进程虚拟地址空间是对于每个进程而言的，而物理内存空间只有一个。那么如果映射、转换虚拟内存和共享内存呢？

(https://courses.engr.illinois.edu/cs241/sp2014/lecture/09-VirtualMemory_II_sol.pdf)

页表就是存储虚拟内存地址和物理内存地址的对应关系的地方。(这里有内存管理单元MMU和转换缓冲区TLB等的概念，我们简化一下，简单理解为虚拟内存到物理内存转换功能（PAGING），这里只看页表）。一个页表是一组页表项page table entries (PTEs) 组成，PTE存储了虚拟页和物理页间的map。

单个页表虽然可以实现内存到虚拟内存的转换功能，但是直接这样实现话，页表本身又占用了太多的内存。

(https://courses.engr.illinois.edu/cs241/sp2014/lecture/09-VirtualMemory_II_sol.pdf)

所以，需要对单个页表进行再分页：二级页表和四级页表

二级页表：

二级页表就是对单页表的再分页。4G 的空间需要 4M 的页表来存储映射表，如果将这 4M 分成 1K 个页（4K）, 这 1K 个页也需要一个表进行管理，我们成为页目录表，这个页目录表里面有 1K 项，每项 4 个字节，页目录表大小也就是 4K 。

四级页表：

对于 64 位系统，两级页表也不够，需要用四级页表

（https://maodanp.github.io/2019/06/02/linux-virtual-space/）

查看pagetable的大小：

[pg@lzl 2345]$ cat /proc/meminfo |grep PageTables
PageTables: 46736 kB

NUMA
#

Uniform Memory Access (UMA)：所有cpu访问内存的时间是等价的。UMA存在的问题是多个处理器通过一条总线访问内存，使共享总线上负载增加。多个处理器会争用memory controller造成冲突。另外总线带宽有限，会有访问延迟。

Non-Uniform Memory Access (NUMA)：一小组CPU一起访问它们自己的本地内存。存在多组CPU和它们的内存组时，每组CPU和内存组就构成一个NUMA节点(node)。

UMA：

NUMA：

（https://users.cs.utah.edu/~aburtsev/cs5460/lectures/lecture19-memory-management/lecture19-memory-management.pdf）

NUMA的基本特性：

cpu访问本地node的内存要比remote的更快
默认情况下linux优先在cpu上分配本地内存，策略可以配置
每个node都有自己的内存结构
不是所有场景都适合numa，需要上层应用的适配

NUMA balancing：

通过自动转移任务到远端cpu或者拷贝远端数据到本地内存的方式，实现本地访问。redhat 7上默认打开。

转移任务或者拷贝数据本身也消耗资源，导致任务变慢，该特性可能不适用于部分应用，例如oracle的exdata就对NUMA做了针对优化。

numactl：

NUMA的OS配置工具。

numactl –show检视cpu和node情况，如下为4node总共64c256g，每个node有16c64g：

available: 4 nodes (0-3)
node 0 cpus: 0 1 2 3 4 5 6 7 32 33 34 35 36 37 38 39
node 0 size: 65418 MB
node 0 free: 310 MB
node 1 cpus: 8 9 10 11 12 13 14 15 40 41 42 43 44 45 46 47
node 1 size: 65536 MB
node 1 free: 41 MB
node 2 cpus: 16 17 18 19 20 21 22 23 48 49 50 51 52 53 54 55
node 2 size: 65536 MB
node 2 free: 82 MB
node 3 cpus: 24 25 26 27 28 29 30 31 56 57 58 59 60 61 62 63
node 3 size: 65536 MB
node 3 free: 43 MB

zone
#

NUMA把cpus和内存分成多个node（node 0，node 1，node 2 ···），UMA结构中也可以把cpu内存整体看成node 0。

在Linux中每个node用数据结构struct pglist_data表示，数据类型为typedef pg_data_t。每个node又分为多个zone，一个zone的数据结构为zone_t，数据类型为zone_struct，一般有3种数据类型ZONE_DMA, ZONE_NORMAL , ZONE_HIGHMEM，每个类型的zone有各种不同的功能。

（https://www.kernel.org/doc/gorman/html/understand/understand005.html）

32位zone的区域分布及功能：

ZONE_DMA：(<16MB)，Direct Memory Access (DMA)，古老的16 MiB限制，包含ISA devices。
ZONE_DMA32：由于很多设备在访问无法用 32 位寻址的内存时遇到问题，在x86-64新增了这样一个区域，该区域只存在于x86-64架构中。（详见ZONE_DMA32）
ZONE_NORMAL： (16MB to 896MB)，可直接映射到内核段的普通内存域；大部分内核操作都在NORMAL区进行，这是最重要的一个区域
ZONE_HIGHMEM：(>896MB)，标记了超出内核段的物理内存，不能直接被内核调用。

32位和64位的zone分布图：

https://users.cs.utah.edu/~aburtsev/cs5460/lectures/lecture19-memory-management/lecture19-memory-management.pdf

注意zone是对于物理内存而言的，虚拟内存的用户态转换为内核态后，才可以调用物理内存。下图便是虚拟内存空间的内核地址与物理地址空间中的zone的关系：

（https://wr.informatik.uni-hamburg.de/_media/teaching/wintersemester_2014_2015/kp-1415-memory-management.pdf）

检视zone：

cat /proc/zoneinfo

cat /proc/buddyinfo

cat /proc/pagetypeinfo

$ cat /proc/buddyinfo 
Node 0, zone DMA 1 1 1 1 1 0 1 1 1 1 2 
Node 0, zone DMA32 688 2080 1420 995 596 357 278 241 276 32 133 
Node 0, zone Normal 195748 204074 161167 119070 70791 33578 9556 2070 1034 2533 7328 
Node 1, zone Normal 11705 51467 36752 21326 11343 7309 5024 3403 2597 3056 10898

页
#

虚拟内存和物理内存被分割为固定大小的片段，一般是4KB大小。所以虚拟内存分割后就有了虚拟页，物理内存分割后就有了物理页（PP or PF，Physical Page or Page Frame），物理页也叫页帧，也是4KB。页帧代表系统内存的最小单位。

虚拟地址空间的每个页面都可以通过其描述项对应到物理地址空间的一个页帧上。

Huge Pages/Transparent Huge Pages
#

页是内存分配的最小单元（默认4K），当map分配大量的连续页时性能较差，Huge Page就是为了解决这个问题。大页不仅分配的时候更cheap，页表同时也相对会更小。hugepagesz 为2 MB或1 GB，默认是2MB。REDHAT 6开始实现了Huge Page。

由于手动管理大页比较麻烦，REDHAT 6开始同样也提供了自动管理大页的功能，即透明大页。

在oracle的数据库管理中，一般把大页打开给SGA使用，透明大页关闭。相关资料也比较多可行搜索资料。

同样的，PostgreSQL也可以开启大页。由于数据库一般会占用较多的操作系统内存，数据库开启大页一般可以降低内存分配的压力。

文件页与PageCache/匿名页与SwapCache
#

文件页可以map到磁盘上的文件，文件系统的读写会通过Page Cache当做缓存IO，脏数据周期或被调用时“sync”（or fsync之类的）到对应的磁盘，Page Cache就是用来“提升”磁盘性能的内存区域。

相对应的，没有文件相关联的页叫匿名页（Anonymous pages ），一般对应着heap、stack。当内存资源紧张时，内核会把不经常使用的匿名页中的数据写入到 Swap 分区或者 Swap 文件中。

简而言之：

page cache是与文件映射对应;
swap cache是与匿名页对应

（https://www.slideshare.net/raghusiddarth/memory-management-in-linux-11551521?from_search=2）

以上page cache的图是站在操作系统的角度来看的，应用程序（如数据库）的写入也可以不delayed，甚至不通过Page cache。

内存分配
#

内存分配也十分复杂，涉及很多概念。两种常见的内存分配方式为buddy、slab

buddy
#

buddy系统用于分配连续的内存页，每个zone都有各自的buddy系统。buddy系统划分了大块内存以响应内存分配请求，同时由于合并的特性可以减少系统内存碎片化。

buddy allocator将内存分为2的幂次方的页，最大阶数为10：

当内存请求大于已有块的大小时，系统会将较大的块分割成两个相等大小的伙伴块。当内存释放时，系统会尝试将相邻的伙伴块合并成一个更大的块：

释放⻚⾯的时候就直接把⻚⾯放回空闲列表，如果其之前拆开的另⼀半⻚⾯也没有被分配，则组合成双倍⻚⾯交给更⼤的列表，然后依次循环，直到不能再循环或者已经到头。

由于高阶页因为不停的分配没有了，此时再申请高阶页时便会触发碎片问题：

等待内存回收成功后，buddy本身会合并低阶到高阶，然后分配高阶页面：

（The implementations of anti pages fragmentation in Linux kernel https://teawater.github.io/presentation/antif.pdf）

然而内存回收也可能赶不上分配速度，所以buddy系统不总是那么理想。

分析示例：

$ cat /proc/buddyinfo 
Node 0, zone DMA 0 0 0 1 2 1 1 0 1 1 3 
Node 0, zone DMA32 7 6 5 6 5 6 7 7 6 2 272 
Node 0, zone Normal 317681 38869 31620 19250 8931 2579 815 182 19 5 0 

上述包含3个ZONE：DMA，DMA32，Normal
阶数： 0 ~ 10，即buddy里对应每一阶对应的数量。buddy最大的阶数为10, 即1024个pages，也就是4MB
如Normal 行第3列表示有31620个2^2连续内存块可以用
以此类推，越是往后的空间，就越是连续，数目越多，就代表这个大小的连续空间越多，当大的连续空间很少的时候，也就说明内存碎片已经不少
另外，全部加起来就是当前free状态的内存

通过buddyinfo判断内存碎片问题：

#host 1
Node 0, zone Normal 317681 38869 31620 19250 8931 2579 815 182 19 5 0 
#host 2
Node 0, zone Normal 7321 7833 10885 8514 2311 1644 1663 1302 1141 7384 80675 

上面是两个主机的内存情况，对比可以发现，下面这个主机的连续内存更多，上面那个主机存在内存碎片问题。

slab
#

slab分配器是基于对象进行管理的。slab系统是一种专门为内核内存设计的内存分配算法。它通过将内存划分为固定大小的cache来实现，每个slab都包含同一类型的对象集。当有内存请求时，该算法首先检查适当的slab缓存中是否存在可用的对象。如果存在，则返回该对象。如果不存在，则算法会分配一个新的slab并将其添加到适当的cache中。

不同大小的对象对应不同的slab cache：

(https://bootlin.com/doc/training/linux-kernel/linux-kernel-slides.pdf)

虽然slab有不同的cache和对象，但是slab仍然使用的是物理连续的内存：

（https://i.stack.imgur.com/wo8Gg.png）

slab也有3种实现方式：

内存回收
#

推荐文章：linux强制回收内存,linux内存源码分析 - 内存回收

内存回收概述
#

当系统内存压力具大时，就会对系统的每个压力大的zone进程内存回收，内存回收主要是针对匿名页和文件页进行；
对于匿名页，内存回收过程中会筛选出一些不经常使用的匿名页，将它们写入到swap分区中，然后作为空闲页框释放到伙伴系统；
对于文件页，内存回收过程中也会筛选出一些不经常使用的文件页：
- 如果此文件页中保存的内容与磁盘中文件对应内容一致，说明此文件页是一个干净的文件页，就不需要进行回写，直接将此页作为空闲页框释放到伙伴系统中；
- 如果文件页保存的数据与磁盘中文件对应的数据不一致，则认定此文件页为脏页，需要先将此文件页回写到磁盘中对应数据所在位置上，然后再将此页作为空闲页框释放到伙伴系统中。
内存回收完成后，系统空闲的页框数量就会增加，能够缓解内存压力，但在回收过程中会对系统的IO造成很大的压力，所以，在系统内，为每个zone会设置一条线，当空闲页框数量不满足这条线时，就会执行内存回收操作，而系统空闲页框数量满足这条线时，系统是不会进行内存回收操作的。

zone的水位线与kswapd
#

（https://vivani.net/2022/06/14/linux-kernel-tuning-page-allocation-failure/)

当可用内存较低时kswapd守护进程会被唤醒以释放页

**pages_low:**当可用的空闲页面数量低于pages_low 时，buddy allocator会唤醒 **kswapd **进程，内核开始将页换出到硬盘。
**pages_min:**当可用页面数量达到 pages_min时，说明页回收工作的压力就比较大，因为内存域中急需空闲页。分配器将以同步的方式执行 kswapd 工作，有时也称为直接回收。
**pages_high:**一旦 kswapd 被唤醒开始释放页面，只有在可用页面数量达到pages_high时，内核才认为该区域是“平衡的”。如果水位线达到pages_high，kswapd 将重新进入休眠状态。空闲页多于pages_high，则内核认为zone的状态是理想的。

内存回收以zone为单位进行，/proc/zoneinfo可以查看min、low、high的值。

vm.min_free_kbytes也就是min_pages线，十分重要的操作系统参数。非常低的值会阻止系统有效地回收内存，这可能会导致系统崩溃并中断服务。太高的值会增加系统回收活动，造成分配延迟，这可能导致系统立即进入内存不足状态。

内存分配和回收的种类
#

快速内存分配：是get_page_from_freelist()函数，通过low阀值从zonelist中获取合适的zone进行分配，如果zone没有达到low阀值，则会进行快速内存回收，快速内存回收后再尝试分配。

慢速内存分配：当快速分配失败后，也就是zonelist中所有zone在快速分配中都没有获取到内存，则会使用min阀值进行慢速分配，在慢速分配过程中主要做三件事，异步内存压缩、直接内存回收以及轻同步内存压缩，最后视情况进行oom分配。并且在这些操作完成后，都会调用一次快速内存分配尝试获取页框。

（https://blog.csdn.net/weixin_35094083/article/details/116688112）

不同的内存分配路径中，会触发不同的内存回收方式，对zone的内存回收方式分为两种：

后台内存回收（kswapd）：在物理内存紧张的时候，会唤醒 kswapd 内核线程来回收内存，这个回收内存的过程异步的，不会阻塞进程的执行。
直接内存回收（direct reclaim）：如果后台异步回收跟不上进程内存申请的速度，就会开始直接回收，这个回收内存的过程是同步的，会阻塞进程的执行。

内存压缩
#

内存压缩见：内存的监控-/proc/pagetypeinfo部分

LRU
#

对于zone的内存回收，它针对三样东西进程回收：slab、lru链表中的页、buffer_head。这里只讨论内存回收针对lru链。

lru链表主要作用就是将页排序，将最应该回收的页放到最后面，最不应该回收的页放到最前面，然后进行内存回收时，就会从后面向前面进行扫描，将扫描到的页尝试进行回收。

lru链表描述符，里面有5个lru链表，活动/非活动匿名页lru链表，活动/非活动文件页lru链表，禁止换出页链表：

（https://lpc.events/event/11/contributions/896/attachments/793/1493/slides-r2.pdf）

内存回收来说，它只会处理前面4个lru链表，也就是活动匿名页lru链表，非活动匿名页lru链表，活动文件页lru链表，非活动文件页lru链。回收到足够页框后直接返回：快速内存回收、kswapd内存回收中会这样做。

可以通过meminfo查看global lruvec（理解为lru区域）：

## cat /proc/meminfo |grep -i active
Active: 597380 kB
Inactive: 601920 kB
Active(anon): 10896 kB
Inactive(anon): 117376 kB
Active(file): 586484 kB
Inactive(file): 484544 kB

实际上lruvec不止一个，cgroup、NUMA node都有自己的lruvec，同时global也有自己的lruvec

drop cache
#

Dropcache会记录哪些页面是缓存文件系统数据的页面，并在页面被强制回收时把数据写回磁盘，以便下次访问时可以再次缓存。

默认值：vm.drop_caches = 0。默认情况下，Linux内核不会自动清除缓存
/proc/sys/vm/drop_caches的值设置为1：内核会清除未使用的页缓存pagecache。
/proc/sys/vm/drop_caches的值设置为2：内核会释放dentry和inode所使用的内存，dentry和inode是文件系统元数据结构，用于存储文件和目录的信息。
/proc/sys/vm/drop_caches的值设置为3：效果相当于1+2，释放所有未使用的缓存

当内核决定回收某些缓存时，它会检查缓存中的数据与硬盘上的数据是否一致。如果数据不一致，内核需要将数据写回磁盘，然后才能回收该缓存。这个过程可能导致IO飙高。在进行Drop Cache操作时，建议不要有任何重要的I/O操作，因为这可能会影响系统性能。

操作命令：

echo 3 > /proc/sys/vm/drop_caches #刷cache缓存
echo 0 > /proc/sys/vm/drop_caches #恢复默认值

内存的监控
#

如果不了解内存的基本知识其实很难看懂内存监控信息，在有了以上内存基础的情况下，我们来一个个过内存相关监控命令、工具的使用。

/proc 目录有些什么？
#

/proc 主要是进程 (process)信息和系统信息

其中system information部分，有些是linux提供的一些系统状态的接口，可以查看整个操作系统层面的监控信息，比如slabinfo,swaps,zoneinfo,buddyinfo

另一部分process是每个进程运行数据和状态信息，cd到对应进程目录下，可以看到对应进程的持有的fd和进程内存信息等

进程下面还有线程，线程的信息目录：/proc/[pid]/task/[tid]/，其下内容跟进程目录下面差不多。

更多的proc信息参考proc(5) — Linux manual page

/proc/meminfo
#

/proc/meminfo是了解当前Linux系统内存使用状况的主要接口，最常用的free,vmstat,ps等命令就是通过它获取数据。/proc/meminfo的信息要更加全面，下面只列出一些常见的信息，详细含义可参考红帽文档

#一般的内存信息
cat /proc/meminfo | grep "Mem"
MemTotal: 994328 kB		#总内存大小（减去一些保留的和内核的）
MemFree: 66428 kB		#完全没有用到的物理内存
MemAvailable: 207192 kB		#在不使用交换空间的情况下，启动一个新的应用最大可用内存的大小

#IO缓冲区
cat /proc/meminfo | grep -e "Buffers" -we "Cached" 
Buffers: 12820 kB		#raw disk block使用的IO缓冲区，不会超过20MB
Cached: 254592 kB		#磁盘使用的page cache size（包含tmpfs和shmem不包含SwapCached）

#swap
cat /proc/meminfo | grep "Swap" 
SwapCached: 13936 kB		#swap cache中包含的是被确定要swapping换页，但是尚未写入物理交换区的匿名内存页
SwapTotal: 945416 kB		#swap空间总大小
SwapFree: 851064 kB		#剩余的swap的大小

#lru活动与非活动页数（一眼懂）
cat /proc/meminfo | grep -e "Active" -e "Inactive" 
Active: 194308 kB
Inactive: 553172 kB
Active(anon): 59024 kB
Inactive(anon): 437264 kB
Active(file): 135284 kB
Inactive(file): 115908 kB

#脏页
cat /proc/meminfo | grep -e "Dirty" -e "Writeback" 
Dirty: 0 kB		#还未写入的脏页
Writeback: 0 kB		#正在写入的脏页
WritebackTmp: 0 kB		#？temporary buffer for writebacks used by the FUSE module

#map信息
cat /proc/meminfo | grep -e "AnonPages" -e "Map"
AnonPages: 95296 kB		#map的匿名页
Mapped: 153192 kB		#map的文件页
DirectMap4k: 113336 kB		#map的4k内核页
DirectMap2M: 1900544 kB		#map的2M内核页
DirectMap1G: 0 kB		#map的1G内核页

#共享内存
cat /proc/meminfo | grep "Shmem"
Shmem: 28920 kB		#shmem和tmpfs的总内存大小
ShmemHugePages: 0 kB		#shmem和tmpfs的总大页内存大小
ShmemPmdMapped: 0 kB		#Shared memory mapped into userspace with huge pages

#内核内存（注意slab就是内核的）
cat /proc/meminfo | grep -ie "reclaim" -e "slab" -e "kernel"
KReclaimable: 35008 kB		#分配给内核的Reclaimable内存
Slab: 88752 kB		#slab cache
SReclaimable: 35008 kB		#slab cache中Reclaimable内存
SUnreclaim: 53744 kB		#slab cache中不能reclaim的内存
KernelStack: 5988 kB		#所有任务使用的kernel stack内存

#分配的可用内存（与MemAvailable含义不同）
## CommitLimit=[("total RAM pages" - "total huge TLB pages") * overcommit_ratio]/100 + "total swap pages"
## 简而言之，设置了MemAvailable的水位然后加上了swap就等于allocatable内存
cat /proc/meminfo | grep -ie "commit"
CommitLimit: 1442580 kB		#allocatable内存
Committed_AS: 3035924 kB		#预估当前最坏场景下，需要分配的内存


#虚拟内存
cat /proc/meminfo | grep -e "Vmalloc"
VmallocTotal: 34359738367 kB	#已分配的虚拟内存总大小
VmallocUsed: 34780 kB			#已使用的虚拟内存总大小
VmallocChunk: 0 kB			#最大的连续虚拟内存块

#page table占用的内存（一眼懂）
cat /proc/meminfo | grep PageTables
PageTables: 4120 kB

#大页内存
cat /proc/meminfo | grep -i hugepage
AnonHugePages: 32768 kB
ShmemHugePages: 0 kB
FileHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB

/proc/buddyinfo
#

buddyinfo由于信息简洁易懂，是最为常用的判断内存碎片问题的方式。详见 “内存分配-buddy章节”

$ cat /proc/buddyinfo 
Node 0, zone DMA 0 0 0 1 2 1 1 0 1 1 3 
Node 0, zone DMA32 7 6 5 6 5 6 7 7 6 2 272 
Node 0, zone Normal 317681 38869 31620 19250 8931 2579 815 182 19 5 0 

/proc/pagetypeinfo
#

pagetypinfo首先提供有关页块大小的信息。它提供与buddyinfo相同类型的信息，但按类型进行细分并详细说明每种类型的页的数量。

在理解pagetypeinfo前，需要先了解下memory compaction.

假如一个zone中的内存如下：

白色代表可用内存，红色代表已使用内存。以上内存的碎片化已经比较严重了，如果此时有请求2阶以上的内存，是无法分配的。此时该memory compaction发生作用了，压缩算法会在原有的zone上标记movable pages和Free pages链表。

movable扫描器从底部到顶部扫描，free扫描器从顶部到底部扫描，movable和free扫描器最终会在中间的某点相遇。然后通过页迁移将已使用页转移到zone的顶端。

page compation两种触发方式：

当分配page的时候，在LOW水位出现分配失败的时候，会尝试慢速内存分配，过程中就会出现page compaction
通过echo x > /proc/sys/vm/compact_memory来启动page compaction的动作，启动后内核线程kcompactd就会启动来进行页面整理

因为⻚⾯中数据被迁移到新位置，所以不会有采取的内存回收导致的那么⼤的性能问题，⽽且因为⽬标更明确，得到的连续⻚⾯的成本也更低。另外ANON⻚⾯回收是需要SWAP的，⽽这⾥不需要。

此时再来看下/proc/pagetypeinfo的信息：

$ cat /proc/pagetypeinfo 
Page block order: 9
Pages per block: 512

...（DMA忽略）
Node 0, zone Normal, type Unmovable 870 530 391 157 103 41 9 2 1 0 0 
Node 0, zone Normal, type Movable 5886 9235 5728 4072 1561 324 115 41 12 4 13018 
Node 0, zone Normal, type Reclaimable 3 4 8 11 2 3 1 1 1 0 0 
Node 0, zone Normal, type HighAtomic 0 0 0 0 0 0 0 0 0 0 0 
Node 0, zone Normal, type CMA 0 0 0 0 0 0 0 0 0 0 0 
Node 0, zone Normal, type Isolate 0 0 0 0 0 0 0 0 0 0 0 

不同的page被分类，称为pageblock。每个pageblock根据其类型不同分成⼏个列表，分配内存的时候，根据申请⻚⾯类型的不同，向相应的列表中申请⻚⾯，⽽释放的时候也会根据其所属pageblock回到相应列表。不同的pageblock：

Unmovable：无法压缩的page
Movable：可压缩的page
Reclaimable：可以回收的page
HighAtomic：为了缓解碎片问题增加的pageblock。高阶并且具备同等级别的才能从该pageblock中申请page
CMA：CMA 全称是 Contiguous Memory Allocator（连续内存分配器）
Isolate：⻚⾯不会被分配，⽤来帮助isolate⻚⾯。isolate⻚⾯的时候会将⻚块先设置为isolate防⽌其被释放

CMA看上去又是一个大块知识，可以简单理解为buddy系统的补充：

（内存之旅——如何提升CMA利用率？ https://ost.51cto.com/posts/10815）

smaps & maps & pmap
#

VSS/RSS/PSS/USS

查看一个进程占用的内存，常有VSS/RSS/PSS/USS四种形式，主要是内存计算的口径不同

（https://cloud.tencent.com/developer/article/1683708）

VSS（Virtual Set Size）只是一个虚拟空间大小，对内存实际占用量意义不大。
RSS（Resident Set Size）是对于计算一个进程总的内存占用量，包括共享库占用的共享内存大小，比如私有内存大小N，共享内存大小M，则RSS=N+M。肯能会有一点误解，因为像libc这种大部头库文件，共享者很多，都算在一个进程头上不科学。
PSS （Proportional Set Size）是单个进程运行时实际占用的物理内存大小，包含比例分配共享库占用的内存，一个共享库有 N 个进程使用，那么该库比例分配给 PSS 的大小为 1/N。PSS计算进程内存更准确，除了自己独占的内存，再加上分到的共享部分。
USS （Unique Set Size）是进程独自占用的物理内存大小，不包含共享内存

/proc/[pid]/maps

/proc/[pid]/maps可查看进程的虚拟内存的用户空间内存映射

[pg@lzl 2345]$ cat maps 
起始地址-结束地址 权限 偏移地址 主次设备号 inode编号												 文件名
00400000-00bae000 r-xp 00000000 fd:00 1093852 /pg/pg15.3/bin/postgres ---代码段
00dad000-00dc3000 rw-p 007ad000 fd:00 1093852 /pg/pg15.3/bin/postgres
00dc3000-00df5000 rw-p 00000000 00:00 0 
00f1e000-00f60000 rw-p 00000000 00:00 0 [heap] ---heap区
33a6000000-33a6022000 r-xp 00000000 fd:00 1976006 /lib64/ld-2.17.so
...
7fbe2ae09000-7fbe2ae0a000 rw-p 0000c000 fd:00 1975966 /lib64/libnss_files-2.17.so
7fbe2ae1b000-7fbe33ca7000 rw-s 00000000 00:04 12556 /dev/zero (deleted)
7fbe33ca7000-7fbe39b38000 r--p 00000000 fd:00 1181300 /usr/lib/locale/locale-archive
7fbe39b38000-7fbe39b3d000 rw-p 00000000 00:00 0 
7fbe39b46000-7fbe39b4d000 rw-s 00000000 00:10 12559 /dev/shm/PostgreSQL.3661351388
7fbe39b4d000-7fbe39b4e000 rw-s 00000000 00:04 32769 /SYSV0010c0b6 (deleted)
7fbe39b4e000-7fbe39b4f000 rw-p 00000000 00:00 0 
7fffe3933000-7fffe3948000 rw-p 00000000 00:00 0 [stack] --stack区 
7fffe397d000-7fffe397e000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]

(1)起始地址-结束地址：本段在虚拟内存中的地址范围 (2)权限：本段的权限; r-读，w-写，x-执行， p-私有 (3)偏移地址：即本段映射地址在文件中的偏移 (4)主次设备号：所映射的文件所属设备的设备号，对应vm_file->f_dentry->d_inode->i_sb->s_dev。匿名映射为0。其中fd为主设备号，00为次设备号。 (5)inode号：对应vm_file->f_dentry->d_inode->i_ino，与ls –i显示的内容相符，匿名映射为0。 (6)映射的文件名：对有名映射而言，是映射的文件名，对匿名映射来说，是此段内存在进程中的作用

以下是文心的分析：（真给它分析出来了，这是一个postgres主进程）

/proc/[pid]/smaps

/proc/[pid]/smaps 文件是基于 /proc/[pid]/maps 的扩展，比同一目录下的maps文件更为详细。每一个VMA都有如下的一系列数据：

[pg@lzl 2345]$ cat smaps 
00400000-00bae000 r-xp 00000000 fd:00 1093852 /pg/pg15.3/bin/postgres
Size: 7864 kB --VSS内存
Rss: 408 kB		--RSS内存
Pss: 140 kB		--PSS内存
Shared_Clean: 404 kB		--共享的、干净的内存大小
Shared_Dirty: 0 kB		--共享的、已脏的（即已修改）的内存大小
Private_Clean: 4 kB		--私有的、干净的内存大小
Private_Dirty: 0 kB		--私有的、已脏的内存大小
Referenced: 408 kB		--当前页面被标记为已引用或者包含匿名映射
Anonymous: 0 kB		--匿名页
AnonHugePages: 0 kB		--匿名大页
Swap: 0 kB		--已交欢出的内存大小
KernelPageSize: 4 kB		--内核页面大小
MMUPageSize: 4 kB		--pagetable页面大小
...
7fffe3933000-7fffe3948000 rw-p 00000000 00:00 0 [stack]
Size: 88 kB
Rss: 16 kB
Pss: 16 kB
...

现在知道，maps是进程的内存映射信息，smaps还包含每段映射的内存大小（VSS,RSS,PSS）。

可通过查看进程smaps的PSS、RSS等数据，计算出进程的内存用量，注意单位是kb

所有进程的物理总内存使用量：

grep Pss /proc/[1-9]*/smaps | awk '{total+=$2}; END {printf "%d kB\n", total }'

某进程PSS内存：

cat /proc/90875/smaps |grep Pss |awk '{sum+=$2 };END {print sum/1024}'

某进程的RSS内存 ：

cat /proc/68729/smaps |grep Rss |awk '{sum+=$2 };END {print sum/1024}'

某进程私有内存：

cat /proc/90875/smaps|sed '/zero/,/VmFlags/d' |grep Private |awk '{sum+=$2 };END {print sum/1024}'

pmap

pmap命令解析的是/proc/[pid]/maps和/proc/[pid]/smaps文件。参数不多，-x表示展示更多信息

[root@lzl ~]# pmap -x 2345
2345: /pg/pg15.3/bin/postgres -D /pg/1503data
Address Kbytes RSS Dirty Mode Mapping
0000000000400000 7864 212 0 r-x-- postgres
0000000000dad000 88 12 12 rw--- postgres
0000000000dc3000 200 36 32 rw--- [ anon ]
0000000000f1e000 264 12 8 rw--- [ anon ]
00000033a6000000 136 108 0 r-x-- ld-2.17.so
...
00007fbe2ae09000 4 0 0 rw--- libnss_files-2.17.so
00007fbe2ae1b000 145968 4396 4396 rw-s- zero (deleted)
00007fbe33ca7000 96836 8 0 r---- locale-archive
00007fbe39b38000 20 16 16 rw--- [ anon ]
00007fbe39b46000 28 4 4 rw-s- PostgreSQL.3661351388
00007fbe39b4d000 4 0 0 rw-s- [ shmid=0x8001 ]
00007fbe39b4e000 4 4 4 rw--- [ anon ]
00007fffe3933000 84 16 16 rw--- [ stack ]
00007fffe397d000 4 4 0 r-x-- [ anon ]
ffffffffff600000 4 0 0 r-x-- [ anon ]
---------------- ------ ------ ------
total kB 268896 5532 4540

pmap输出格式跟/proc/[pid]/maps差不多，每个vma地址一行，但是比maps多了VSS和RSS，这样就可以直接看进程虚拟内存的每个区域所使用的大小，帮助快速判断内存较多的区域在哪。

如果地址空间中[heap]太大，那有可能是堆内存产生了泄漏；再比如说，如果进程地址空间包含太多的 vma（可以把 maps 中的每一行理解为一个 vma），那很可能是应用程序调用了很多 mmap 而没有 munmap；再比如持续观察地址空间的变化，如果发现某些项在持续增长，那很可能是那里存在问题

分析示例

从主机的TOP的内存查看某pg backend进程内存看上去比较高，此时需要进一步分析map信息：

 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 
68729 postgres 20 0 5579004 5.116g 5.114g R 97.4 1.4 128:27.94 postgres: lzl: lzldb lzl 30.78.14.174(58067) DELETE 

查看这个进程Rss、Pss、Uss

cat /proc/68729/smaps |grep Rss |awk '{sum+=$2 };END {print sum/1024}'
5422.67 ---5.4G Rss
cat /proc/68729/smaps |grep Pss |awk '{sum+=$2 };END {print sum/1024}'
467.957	 ---467mb Pss
cat /proc/68729/smaps|sed '/zero/,/VmFlags/d' |grep Private |awk '{sum+=$2 };END {print sum/1024}'
179.605 ---179mb Uss

Rss-Uss=5.3G的共享内存，从Pss-Uss=290mb的proportion共享内存，大致能看出这个backend只是这个共享内存proportion的一小部分

$ pmap -x 68729
68729: postgres: pdmp: pdmpdata pdmp 30.78.14.174(46252) DELETE 
Address Kbytes RSS Dirty Mode Mapping
0000000000400000 6084 2444 0 r-x-- postgres
0000000000bf0000 4 4 4 r---- postgres
0000000000bf1000 52 52 52 rw--- postgres
...
00002b7f65bfa000 5441216 5365444 5365444 rw-s- zero (deleted) --这部分占用最多
00002b80b1daa000 48 0 0 r-x-- libnss_files-2.17.so
00002b80b1db6000 2044 0 0 ----- libnss_files-2.17.so
00002b80b1fb5000 4 4 4 r---- libnss_files-2.17.so
00002b80b1fb6000 4 4 4 rw--- libnss_files-2.17.so
00002b80b1fb7000 24 0 0 rw--- [ anon ]
00002b80ba001000 516 516 516 rw--- [ anon ]
00007fffe16f7000 132 88 88 rw--- [ stack ]
00007fffe175b000 8 4 0 r-x-- [ anon ]
ffffffffff600000 4 0 0 r-x-- [ anon ]

继续深入到smap分析，可以直接定位到zero (deleted)这部分

$ cat smaps 
00400000-009f1000 r-xp 00000000 fd:06 58726481 /paic/postgres/base/9.6.6/bin/postgres
...
2b7f65bfa000-2b80b1daa000 rw-s 00000000 00:04 72254 /dev/zero (deleted)
Size: 5441216 kB
Rss: 5365444 kB
Pss: 264618 kB
Shared_Clean: 0 kB
Shared_Dirty: 5365444 kB --共享的脏数据
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 5364764 kB
Anonymous: 0 kB
AnonHugePages: 0 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
VmFlags: rd wr sh mr mw me ms sd 

从以上分析可以得出：这是个pg的私有进程，变动了大量数据还没有刷脏，自己私有内存不多，大部分都是共享内存中占用的。这很有可能是一个pg中的事务变动了很多数据暂时还没提交。

另外，/dev/zero (deleted)在proc(5) — Linux manual page有解释:

Although these entries are present for memory regions that were mapped with the MAP_FILE flag, the way anonymous shared memory (regions created with the MAP_ANON | MAP_SHARED flags) is implemented in Linux means that such regions also appear on this directory. Here is an example where the target file is the deleted /dev/zero one:
 lrw-------. 1 root root 64 Apr 16 21:33
 7fc075d2f000-7fc075e6f000 -> /dev/zero (deleted)

“非专业翻译”：匿名页和共享页由 /dev/zero (deleted)表示

/proc/[pid]/status
#

status可查看进程的状态信息，包含一部分内存信息。

[root@lzl 2345]# cat status 
Name: postgres			---运行这个线程的命令
State: S (sleeping)	---进程状态
Tgid: 2345					---Thread group ID (i.e., Process ID)
Pid: 2345					---Thread ID
PPid: 1	 					---PID of parent process.
...
VmPeak: 268964 kB		---虚拟内存峰值
VmSize: 268896 kB		---虚拟内存当前值
VmLck: 0 kB
VmHWM: 13400 kB		---RSS的峰值
VmRSS: 5532 kB		---RSS的当前值
VmData: 528 kB		---数据段
VmStk: 88 kB		---stack段
VmExe: 7864 kB		---text段
VmLib: 3100 kB		---共享库代码段
VmPTE: 136 kB		---Page table entries
VmSwap: 308 kB		---swap的大小
Threads: 1			---该进程的线程数
....

status相对map，没有映射信息，内存数据更概况一些，也可以更直观的看到虚拟内存的每个段所占用的大小

查看SWAP用量最多的进程：

for file in /proc/*/status ; do awk '/VmSwap|Name|^Pid/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 3 -n -r | head

cgroup memory
#

cgroup的memory控制现在已经很常见。一些主机参数需要在cgroup中设置。内存设置、监控信息均在/sys/fs/cgroup/memory/下面

cginfo查看CGROUP内存分配和使用情况： /opt/cgtools/cginfo -t perf -s mem

cginfo -t perf -s mem
==================== Cgroup Performance: memory ====================
DB_TYPE INSTANCE_NAME MEM_OOM MEM_FILE_GB MEM_MAP_GB MEM_USED_GB MEM_ALLO_GB ALLO_RATE MEM_GLOB_GB GLOB_RATE 
------- ------------- ------- ----------- ---------- ----------- ----------- --------- ----------- --------- 
postgres LZLDB 0 154.3 0.0 4.2 160.0 2.6% 375 1.1% 

查看比较详细的CGROUP内存使用状态: /sys/fs/cgroup/memory/[group]/memory.stat

$ cat memory.stat 
...
total_cache 167791534080
total_rss 4006932480
total_rss_huge 0
total_mapped_file 11747328
total_swap 0
total_pgpgin 792754417976
total_pgpgout 792712474991
total_pgfault 477971874868
total_pgmajfault 97318
total_inactive_anon 1610874880
total_active_anon 2408255488
total_inactive_file 73446166528
total_active_file 94332768256
total_unevictable 0

smem
#

smem是一款强大的展示内存使用情况的工具，读取/proc下面的smaps、meminfo等信息然后汇总输出。smem可以输出总体和具体map的内存情况，非常直观而且可以从不同的维度去分析，总体是一款分析内存使用非常好用的工具。

repo可直接下载，基本上解压即可使用。更多用法可参考smem memory reporting tool，以下只简单示例：

查看系统内存使用 -w：

[root@lzl ~]# smem -w -k
Area Used Cache Noncache 
firmware/hardware 0 0 0 
kernel image 0 0 0 
kernel dynamic memory 183.9M 84.0M 99.9M 
userspace memory 112.3M 62.2M 50.1M 
free memory 700.3M 700.3M 0 

查看每个用户的内存消耗 -u:

[root@lzl ~]# smem -s pss -urk
User Count Swap USS PSS RSS 
oracle 25 85.2M 30.8M 95.7M 383.0M 
root 93 112.4M 38.5M 42.3M 86.2M 
pg 12 5.9M 1.6M 2.5M 5.9M 
mysql 1 169.7M 1.7M 1.7M 2.0M 

查看某个用户的内存消耗-U

[root@lzl ~]# smem -U pg -k
 PID User Command Swap USS PSS RSS 
 2345 pg /pg/pg15.3/bin/postgres -D 364.0K 124.0K 134.0K 228.0K 
 2352 pg postgres: logical replicati 636.0K 144.0K 161.0K 196.0K 
 ...

过滤某个进程 -P（PROCESSFILTER，不是pid）：

[root@lzl ~]# smem -P postgres -p
 PID User Command Swap USS PSS RSS 
 2346 pg /pg/pg16.0/bin/postgres -D 0.01% 0.01% 0.01% 0.01% 
 2350 pg postgres: walwriter 0.01% 0.01% 0.01% 0.01% 
 ...

查看进程的mapping和内存占用情况 -m：

[root@lzl ~]# smem -P postgres -mpr -s pss
Map PIDs AVGPSS PSS 
<anonymous> 13 0.02% 0.24% 
[heap] 3 0.07% 0.20% 
/usr/lib64/libpython2.6.so.1.0 1 0.11% 0.11% 
/pg/pg15.3/bin/postgres 6 0.01% 0.06% 
/pg/pg16.0/bin/postgres 6 0.01% 0.06% 
/dev/zero 12 0.00% 0.03% 
[stack] 13 0.00% 0.02% 
...

smem看进程内存的USS\PSS\RSS很直观，不过有个问题，smem不能过滤pid，只能通过用户名或PROCESSFILTER去过滤，对于一个主机部署多个数据库实例时，过滤父PID或子PID，不是很友好。

top
#

top可实时的展示系统运行状态。top玩法也可以非常花哨，直接top运行同样可以展示非常多的信息。

使用top中的排序：

command sorted-field supported
M %MEM Yes
N PID Yes
P %CPU Yes
T TIME+ Yes

可以用%MEM来排序内存占用较多的进程，%MEM表示RES的内存百分比

top - 23:38:01 up 3 days, 22:32, 2 users, load average: 1.12, 1.42, 1.09
Tasks: 198 total, 13 running, 183 sleeping, 0 stopped, 2 zombie
Cpu(s): 0.0%us, 0.3%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1020348k total, 325848k used, 694500k free, 1352k buffers
Swap: 4128760k total, 635872k used, 3492888k free, 150288k cached

 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 
18537 oracle 20 0 636m 24m 21m S 0.0 2.4 0:05.41 oracle 
18533 oracle 20 0 638m 24m 21m S 0.0 2.4 0:02.01 oracle 
... 
18509 oracle 20 0 634m 4384 4036 S 0.0 0.4 0:01.93 oracle 
 2639 root 20 0 729m 4052 1444 S 0.0 0.4 8:45.32 nautilus 

内存相关的解读：

第四行：内存使用信息：物理内存量、已用内存量、空闲内存量、缓冲内存量第五行：交换分区信息：可用交换区总量、已用交换区总量、空闲交换区总量、内核用于缓存的数量

第六行（内存相关）：

VIRT：VSS
RES：RSS（likely），anything occupying physical memory
SHR：Shared Memory Size。It will include shared anonymous pages and shared file-backed pages
%MEM： RSS百分比，A task’s currently resident share of available physical memory.

另外，查看内存的时候不要忘了看一眼进程的状态

S（示例第八列）Process Status：

D = uninterruptible sleep。不可中断的睡眠状态。表示该进程正在等待某个外部事件完成，如磁盘I/O操作或网络请求。通常情况下，D进程不能被直接终止。
I = idle
R = running
S = sleeping
T = stopped by job control signal
t = stopped by debugger during trace
Z = zombie

top命令可以看到主机的内存汇总信息，进程使用内存信息有RSS,SHR，粗略算一下RES-SHR=USS也可以计算私有内存的占用大小，另外还可以看到进程状态，所以top -p查看某进程的内存基本信息还是很好用的。

free
#

free展示主机的swap、内存的总量和剩余量，信息都是解析自/proc/meminfo

user@ubuntu:~$ free

 total used free shared buff/cache available
Mem: 8029356 794336 6297928 183384 937092 6816804
Swap: 0 0 0

total ：Total usable memory (MemTotal and SwapTotal in /proc/meminfo). This includes the physical and swap memory minus a few reserved bits and kernel binary code.
used ： Used or unavailable memory (calculated as total - available)
free：Unused memory (MemFree and SwapFree in /proc/meminfo) shared Memory used (mostly) by tmpfs (Shmem in /proc/meminfo)
buffers：Memory used by kernel buffers (Buffers in /proc/meminfo)
cache：Memory used by the page cache and slabs (Cached and SReclaimable in /proc/meminfo)。不仅有pagecache，还有SReclaimable的slab！
buff/cache：Sum of buffers and cache
available：cache包含pagecache和SReclaimable，free包含mem free和swap free；而available包含pagecache和即将被reclaim的内存；表示可用内存，但它们的计算方式不同，在实际应用中，由于缓存的存在，available通常会比free大

Page Cache： Page cache 主要用来作为文件系统上的文件数据的缓存来用，尤其是针对当进程对文件有 read/write 操作的时候。

Buffer Cache： Buffer cache 则主要是设计用来在系统对块设备进行读写的时候，对块进行数据缓存的系统来使用

ps aux
#

ps最大的好处就是从进程的角度分析进程状态（包括内存），COMMAND带[ ]标志的进程为kernel进程。

[pg@lzl ~]$ ps aux|head -1;ps aux|grep postgres
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
pg 2345 0.0 0.0 268896 236 ? Ss Jan01 0:03 /pg/pg15.3/bin/postgres -D /pg/1503data
pg 2353 0.0 0.0 269040 196 ? Ss Jan01 0:00 postgres: checkpointer 
pg 2354 0.0 0.0 269032 160 ? Ss Jan01 0:02 postgres: background writer 
pg 2356 0.0 0.0 269032 116 ? Ss Jan01 0:01 postgres: walwriter 
pg 2357 0.0 0.0 270508 824 ? Ss Jan01 0:02 postgres: autovacuum launcher 
pg 2358 0.0 0.0 270492 620 ? Ss Jan01 0:00 postgres: logical replication launcher 
pg 29818 0.0 0.0 103372 868 pts/0 S+ 09:16 0:00 grep postgres

VSZ,RSS单位是kb。内存信息比较少，VSZ没什么价值，RSS可以参考一下，没有PSS，USS这类信息，能分析的内容不多

ipcs
#

ipcs -m 是一个用于查询 IPC（进程间通信）共享内存资源的命令。分析共享内存的时候比较有用。

[pg@lzl ~]$ ipcs -m

------ Shared Memory Segments --------
key shmid owner perms bytes nattch status 
0x0010c0b6 32769 pg 600 56 6 

共享内存的 key 值
共享内存的编号 (shmid)
创建该共享内存的用户
权限（perms）
创建的大小（bytes）
连接到该共享内存的进程数（nattach）
共享内存的状态

此时连接一个会话到PostgreSQL，会多一个backend进程

------ Shared Memory Segments --------
key shmid owner perms bytes nattch status 
0x0010c0b6 32769 pg 600 56 7 

nattch+1，说明私有的backend进程也分享了一部分PG共享出来的内存。此时理解下面这个图也更深刻

（http://gauss.ececs.uc.edu/Courses/c4029/code/memory/virtual.pdf）

vmstat
#

vmstat是Virtual Meomory Statistics（虚拟内存统计）的缩写，可对操作系统的虚拟内存、进程、CPU活动进行监控。它是对系统的整体情况进行统计，不足之处是无法对某个进程进行深入分析。 有用的参数说明：

vmstat [options] [delay [count]]
OPTIONS:
-a 显示活跃和非活跃内存
-m 显示slabinfo
-s 显示内存相关统计信息及多种系统活动数量
-t Append timestamp to each line，在最后加个输出时间戳
-w Wide output mode.没有加w的话，输出比较窄，可以减少对不齐问题

-bash-4.1$ vmstat -w 1 3
procs -------------------memory------------------ ---swap-- -----io---- --system-- -----cpu-------
 r b swpd free buff cache si so bi bo in cs us sy id wa st
 0 1 661652 763348 324 76100 15 12 54 21 18 45 0 0 79 21 0
 2 1 661652 763340 304 75764 0 0 0 32 12 84 0 1 0 99 0
41 1 661652 760744 244 78300 228 0 3216 0 265 442 0 0 0 100 0

pidstat
#

pidstat是sysstat工具的一个命令，用于监控全部或指定进程的CPU、内存、线程、设备IO等系统资源的占用情况。

有用的参数说明：

pidstat OPTIONS interval [ count ] 
-d :Report I/O statistics 
-u :Report CPU utilization
-r :Report page faults and memory utilization
-w :Report task switching activity
-p :pid[,...] 
-l :Display the process command name and all its arguments.

查看某进程的内存情况：

-bash-4.1$ pidstat -r -l -p 2345
Linux 2.6.32-431.el6.x86_64 (lzl) 01/06/2024 _x86_64_ (1 CPU)

02:48:32 PM PID minflt/s majflt/s VSZ RSS %MEM Command
02:48:32 PM 2345 0.23 0.00 268896 240 0.02 /pg/pg15.3/bin/postgres -D /pg/1503data 

各类指标比较容易理解，VSZ,RSS说的都不想说了

minflt/s：这是“minor page faults”的缩写，指的是每秒发生的“次要页面错误”的数量。当一个程序试图访问一个不在物理内存中的页面时，就会发生页面错误。如果这个页面确实在硬盘上的交换区（swap）中，那么这是一个次要页面错误（minor page fault）。
majflt/s：这是“major page faults”的缩写，指的是每秒发生的“主要页面错误”的数量。与次要页面错误不同，主要页面错误发生在程序试图访问一个不在物理内存中，且也不在硬盘上的交换区中的页面时。

sar
#

sar（System Activity Reporter 系统活动情况报告）是目前 Linux 上最为全面的系统性能分析工具之一，可以从多方面对系统的活动进行报告，包括：文件的读写情况、系统调用的使用情况、磁盘 I/O、CPU 效率、内存使用状况、进程活动及 IPC 有关的活动等。SAR工具是sysstat软件包的一部分。

(https://www.brendangregg.com/Perf/linux_observability_sar.png)

sar非常强大，man的参数介绍就有1k多行，本篇不太可能解释完（偷懒）。

内存相关的参数：

sar OPTIONS interval [ count ] 
-B :Report paging statistics
-r :Report memory utilization statistics
-W :Report swapping statistics.
-H :Report hugepages utilization statistics
-s [ start_time ] ] [ -e [ end_time ] 

示例：sar查看内存利用率 sar -r 1 3

kbmemfree：这个值和 free 命令中的 free 值基本一致，所以它不包括 buffer 和 cache 的空间
kbmemused：这个值和 free 命令中的 used 值基本一致，所以它包括 buffer 和 cache 的空间
%memused：这个值是 kbmemused 和内存总量(不包括 swap)的一个百分比
kbbuffers : free 命令中的 buffer
kbcached： free 命令中 cache
kbcommit：保证当前系统所需要的内存，即为了确保不溢出而需要的内存(RAM + swap)
%commit：这个值是 kbcommit 与内存总量(包括 swap)的一个百分比

示例：sar查看内存页的状态 sar -B 1 3

pgpgin/s：表示每秒从磁盘或SWAP置换到内存的字节数(KB)
pgpgout/s：表示每秒从内存置换到磁盘或SWAP的字节数(KB)
fault/s：每秒钟系统产生的缺页数，即主缺页与次缺页之和(major + minor)
majflt/s：每秒钟产生的主缺页数
pgfree/s：每秒被放入空闲队列中的页个数
pgscank/s：每秒被 kswapd 扫描的页个数
pgscand/s：每秒直接被扫描的页个数
pgsteal/s：每秒钟从 cache 中被清除来满足内存需要的页个数
%vmeff：每秒清除的页(pgsteal)占总扫描页(pgscank + pgscand)的百分比

示例：sar查看swap信息 sar -W 1 3 报告说明

pswpin/s：每秒系统换入的交换页面（swap page）数量
pswpout/s：每秒系统换出的交换页面（swap page）数量

示例：sar查看历史内存信息 sar -B -s "08:00:00" -e "10:00:00"

#不加-e表示从开始时间点到现在的信息
$ sar -B -s "08:00:00"
09:45:01 PM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s %vmeff
09:46:01 PM 414429.37 395024.08 179478.63 0.07 352922.62 12003.78 4266.52 16269.42 99.99
09:47:01 PM 879907.08 337948.43 157970.97 0.02 402290.21 0.00 0.00 0.00 0.00
09:48:01 PM 772977.43 507343.30 150255.50 0.05 466742.08 0.00 5821.28 5821.27 100.00

以上pgsank表示kswapd进程介入回收内存的速度，pgscand表示直接内存回收的速度

gcore
#

gcore是gdb的一部分，可生成进程的core dump文件

示例dump一个PostgreSQL的backend进程

[root@lzl ~] ps -ef|grep 8296
pg 8296 2345 0 09:41 ? 00:00:00 postgres: pg lzldb [local] idle 
[root@lzl ~] cat /proc/8296/smaps |grep Pss |awk '{sum+=$2 };END {print sum/1024}' 
0.351562
[root@lzl ~] cat /proc/8296/smaps |grep Rss |awk '{sum+=$2 };END {print sum/1024}'
0.445312
[root@lzl ~] cat /proc/8296/smaps|sed '/zero/,/VmFlags/d' |grep Private |awk '{sum+=$2 };END {print sum/1024}'
0.0078125

8296进程的uss只有7.8 bytes，RSS 445 bytes。dump内存：

gcore -o /tmp/dump 8296

dump要花点时间，而且dump下来的文件比较大，并且会夯住进程

[root@lzl 8296]# ls -lh /tmp/dump.8296 
-rw-r--r-- 1 root root 252M Jan 7 10:59 /tmp/dump.8296

gdb
#

gdb可查看内存中具体位置和内容

示例查看PostgreSQL backend的缓存数据

1.新开一个会话查找一个分区表，会话保持不断开

[pg@lzl ~]$ psql
psql (15.3)
Type "help" for help.

postgres=> \c lzldb
You are now connected to database "lzldb" as user "pg".
lzldb=> select * from lzlpartition limit 1;
 appl_no | is_deleted | date_created | date_updated 
---------+------------+--------------+--------------
(0 rows)

2.pmap，smaps查看进程内存占用情况，找到想dump的内存段

[root@lzl 13393]# pmap -x 13393
13393: postgres: pg lzldb [local] idle 
Address Kbytes RSS Dirty Mode Mapping
0000000000400000 7864 1204 0 r-x-- postgres
..
00007fbe2ae1b000 145968 2164 176 rw-s- zero (deleted) ---RSS这里占用最多
00007fbe33ca7000 96836 0 0 r---- locale-archive
00007fbe39b38000 20 0 0 rw--- [ anon ]
00007fbe39b46000 28 0 0 rw-s- PostgreSQL.3661351388
00007fbe39b4d000 4 0 0 rw-s- [ shmid=0x8001 ]
00007fbe39b4e000 4 0 0 rw--- [ anon ]
00007fffe3933000 84 36 0 rw--- [ stack ]
00007fffe397d000 4 4 0 r-x-- [ anon ]
ffffffffff600000 4 0 0 r-x-- [ anon ]

[root@lzl 13393]# cat /proc/13393/smaps |grep -A 13 zero
7fbe2ae1b000-7fbe33ca7000 rw-s 00000000 00:04 12556 /dev/zero (deleted)
Size: 145968 kB
Rss: 2164 kB
Pss: 2164 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 1988 kB
Private_Dirty: 176 kB
Referenced: 2164 kB
Anonymous: 0 kB
AnonHugePages: 0 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB

3.gdb dump memory

dump内存的起始位置为smaps中的vm地址+0x

[pg@lzl tmp]$ gdb
(gdb) attach 13393
(gdb) dump memory /tmp/delete.dump 0x7fbe2ae1b000 0x7fbe33ca7000

4.查看dump文件

可简单通过strings 查看

[root@lzl 13393]# strings /tmp/delete.dump|grep lzl|sort|uniq
...
 @lzlpartition_202301
lzlpartition_202301
lzlpartition_202301_appl_no_idx
lzlpartition_202301_date_created_idx
...
lzlpartition_202306
lzlpartition_202306_appl_no_idx
lzlpartition_202306_date_created_idx
 @lzlpartition_attach
lzlpartition_attach
 @nk_lzlpartition
nk_lzlpartition
select * from lzlpartition limit 1;

会话只要查询了分区表，就把所有分区、索引等元数据全部缓存到backend进程中

注意：

gdb attach [pid]会夯住进程，不要随意执行
dump文件大小等于VSS，一般远大于RSS/PSS/USS

内存小节
#

references
#

轻松突破文件IO瓶颈：内存映射mmap技术 https://blog.51cto.com/u_15481245/6582927

一步一图带你深入理解 Linux 物理内存管理 https://cloud.tencent.com/developer/article/2352771?areaId=106001

从DBA的角度系统学习一下内存管理 https://mp.weixin.qq.com/s/CybzGP44dVWQN5hfFrVx7A

https://linux2me.wordpress.com/2017/09/15/linux-introduction-to-memory-management/

Memory management in Linux https://www.slideshare.net/raghusiddarth/memory-management-in-linux-11551521?from_search=2

Linux Performance Tunning Memory https://www.slideshare.net/shayc1/linux-performance-tunning-memory?from_search=4

Linux内核这样学才能学会（内存篇） https://mp.weixin.qq.com/s/lKKHH1MMiZbnIbDQt3-IAQ

https://courses.engr.illinois.edu/cs241/sp2014/lecture/09-VirtualMemory_II_sol.pdf

Linux的进程虚拟地址空间 https://maodanp.github.io/2019/06/02/linux-virtual-space/

redhat官方文档 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_tuning_and_optimization_guide/chap-virtualization_tuning_optimization_guide-numa

Data Processing on Modern Hardware https://db.in.tum.de/teaching/ss21/dataprocessingonmodernhardware/MH_8.pdf?lang=de

Chapter 2 Describing Physical Memory https://www.kernel.org/doc/gorman/html/understand/understand005.html

各类命令的man手册

linux强制回收内存,linux内存源码分析 - 内存回收(整体流程) https://blog.csdn.net/weixin_35094083/article/details/116688112

内存之旅——如何提升CMA利用率？ https://ost.51cto.com/posts/10815

The implementations of anti pages fragmentation in Linux kernel https://teawater.github.io/presentation/antif.pdf

T H E /proc F I L E S Y S T E M https://www.kernel.org/doc/Documentation/filesystems/proc.txt

The /proc/meminfo File in Linux https://www.baeldung.com/linux/proc-meminfo

the proc filesystem https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/s2-proc-meminfo

linux的/proc/{pid}/maps介绍及使用(定位内存泄漏) https://blog.csdn.net/mijichui2153/article/details/123934531

Linux top命令的cpu使用率和内存使用率 https://blog.csdn.net/weixin_45030965/article/details/127693042

smem memory reporting tool https://www.selenic.com/smem/

Linux performance optimization https://feiyang233.club/post/linux/

gdb onlinedocs https://sourceware.org/gdb/current/onlinedocs/gdb

Linux_Core_Dumps https://averageradical.github.io/Linux_Core_Dumps.pdf

PostgreSQL FDW浅析

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

FDW的基本概念
#

什么是SQL/MED？
#

SQL/MED是为了统一异构数据源的访问方式。2003年SQL/MED加入到ISO/IEC 9075-9标准中，SQL/MED定义为通过foreign-data wrappers（fdw）或datalink（如oracle、pg的dblink）管理外部数据的SQL标准扩展。简而言之，SQL/MED是国际SQL扩展标准。很多库已经支持SQL/MED如DB2、MariaDB、PG等等。在没用SQL/MED时应用只能自行访问需要的数据源，并在应用层对数据进行处理：

使用SQL/MED后，数据访问架构会更清晰

但是，这个架构图看上去是简化了，对于数据库的IO、计算压力却提升了。这跟当今把计算从数据库剥离到应用层的思想是违背的。当然两种方案各有优劣，有些场景下SQL/MED还是会使用到。 SQL/MED作为一个标准存在，PostgreSQL也通过FDW极好的支持了SQL/MED标准。

什么是FDW？
#

postgresql从开始9.1支持fdw。用户可以通过常规的SQL语句访问外部数据（foreign data）。foreign data通过foreign data wrapper（fdw）来访问。postgresql数据库中的fdw本身是一个library ，因为不同的外部数据对应这不同的fdw插件，所以我们也常说说它是fdw插件。 pg中的FDW功能十分强大，不仅支持多种数据源，还对数据访问做了优化，甚至可以用来做“超出预期”的事情，比如集群功能的实现。

安装与下载
#

基本上每种数据库、数据类型都有各自的fdw插件，访问oracle库有oracle_fdw，访问mysql库有mysql_fdw等等。fdw插件可以直接安装或者下载安装：

已包含在extension中的fdw。有file_fdw、postgres_fdw、cstore_fdw
其他的fdw插件可以在PGXN或者wiki上下载，比如：oralce_fdw、mysql_fdw、json_fdw。注意仔细阅读readme，了解不同fdw的限制和使用规则。

fdw插件下载地址：https://pgxn.org/tag/fdw/
更多的fdw（大部分是beta版）:https://wiki.postgresql.org/wiki/Foreign_data_wrappers

自行编写fdw。https://www.postgresql.org/docs/current/fdwhandler.html

pg中fdw相对dblink的优势
#

pg库也有dblink。fdw和dblink在功能上是很类似的都是访问外部表。但是fdw有更多优势

fdw支持更多的数据源（非常非常多）。dblink只支持postgresql数据库，相当于fdw的其中一个插件postgres_fdw功能（实际上postgres_fdw要强的多）
对开发透明。可以像访问普通表一样访问外部表
更符合标准SQL语法
在很多场景下有更好的性能

The functionality provided by this module overlaps substantially with the functionality of the older dblink module. But postgres_fdw provides more transparent and standards-compliant syntax for accessing remote tables, and can give better performance in many cases.

总之，fdw强于dblink插件，基本上可以把dblink遗忘了。

fdw的4个对象
#

不同的fdw有不同的用法，但基本都需要创建4个对象foreign data wrapper（包装器），server（外部服务），user mapping（用户映射），foreign table（外部表）。其中有些对象不是必须的，比如file_fdw就可以没有user mapping，而关系型数据库的fdw一般都需要创建user mapping。

foreign data wrapper
#

在CREATE EXTENSION创建好相应的fdw插件后，foreign data wrapper就自动建好了。比如创建一个file_fdw extension，其对应的foreign data wrapper自动创建好。

=# create extension file_fdw;
CREATE EXTENSION

=# \dx
 Name | Version | Schema | Description 
--------------------+---------+------------+------------------------------------------------------------------------
 file_fdw | 1.0 | public | foreign-data wrapper for flat file access

## select * from information_schema.foreign_data_wrappers;
 foreign_data_wrapper_catalog | foreign_data_wrapper_name | authorization_identifier | library_name | foreign_data_wrapper_language 
------------------------------+---------------------------+--------------------------+--------------+-------------------------------
 postgres | file_fdw | postgres | [null] | c

也可以不使用插件，自行创建一个外部数据包装器，参考CREATE FOREIGN DATA WRAPPER

server
#

CREATE SERVER可以创建一个外部服务，相当于指定了数据来源。其中OPTIONS的语法因不同的foreign-data wrapper而不同，比如file_fdw,postgres_fdw的OPTION语法肯定是不一样的，这时就要读fdw插件的readme或者官方文档了。例如创建一个file_fdw的外部服务名叫fileserver:

CREATE SERVER fileserver FOREIGN DATA WRAPPER file_fdw;

创建一个postgres_fdw的外部服务名叫pgserver，服务来自172.0.0.1:5432 pg实例上的lzldb库：

CREATE SERVER pgserver FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host '172.0.0.1', dbname 'lzldb', port '5432');

查看server：

=# select * from information_schema.foreign_servers;
 foreign_server_catalog | foreign_server_name | foreign_data_wrapper_catalog | foreign_data_wrapper_name | foreign_server_type | foreign_server_version | authorization_identifier 
------------------------+---------------------+------------------------------+---------------------------+---------------------+------------------------+--------------------------
 postgres | pgserver | postgres | postgres_fdw | [null] | [null] | postgres
 postgres | fileserver | postgres | file_fdw | [null] | [null] | postgres

user mapping
#

user mapping定义了外部服务用户和本地用户的对应关系。所以一般关系型数据库类的fdw都有user mapping，而file这类的fdw没有用户定义就不需要创建这个。例如用刚才的pgserver创建一个user mapping

CREATE USER MAPPING FOR localuser SERVER pgserver OPTIONS (user 'remoteuser', password 'mypasswd');

查看user mapping

=# select * from information_schema.user_mappings;
 authorization_identifier | foreign_server_catalog | foreign_server_name 
--------------------------+------------------------+---------------------
 localuser | lzldb | pgserver

foreign table
#

foreign table相当于在本地映射了远程表，然后就可以像普通表一样进行访问。因为涉及本地对象了，OPTION很多，所以全语法有些复杂，可参考CREATE FOREIGN TABLE，简单点那么在本地建一个远程对应的表就可以了。而因fdw的不同语法也有所不同，此处不多做展示了。举例两个常见的创建foreign table的方式：创建和导入。创建一个外部表

CREATE FOREIGN TABLE localtable (
 id char(5) NOT NULL,
 name varchar(40) NOT NULL
)
SERVER pgserver OPTIONS (table_name 'remotetable');

一个个创建foreign table比较麻烦，可以一次把外部schema下的table全部导入

IMPORT FOREIGN SCHEMA remoteschema FROM SERVER pgserver INTO localschema;

查看foreign table

 information_schema.foreign_tables; --能直观看到foreign表
 pg_foreign_server; --不太直观，但展示了option选项

fdw的使用
#

查看外部表信息
#

psql自带的快捷命令比较清晰，可以简单的查看外部表的4个对象，不过要注意search_path的设置

psql命令	含义
\des	list foreign servers
\deu	list uses mappings
\det	list foreign tables
\dtE	list both local and foreign tables

外部表对象的视图/表比较乱，稍微梳理一下

foreign data wrapper 表/视图	含义
information_schema._pg_foreign_data_wrappers	信息较全
information_schema.foreign_data_wrappers	信息较少
information_schema.foreign_data_wrapper_options	针对性的查foreign data wrapper的option
pg_foreign_data_wrapper	信息略少，但是有权限信息！权限信息其他几个视图都没有

foreign server 表/视图	含义
information_schema._pg_foreign_servers	信息较全
information_schema.foreign_servers	信息较少
information_schema.foreign_server_options	针对性的查option，不是一个server一条记录，而是一个option一个记录
pg_foreign_server	信息较少，基表

user mapping 表/视图	含义
information_schema._pg_user_mappings	较全的user mapping信息
information_schema.user_mappings	信息较少
information_schema.user_mapping_options	针对性的查um的option
pg_user_mappings	信息比information_schema._pg_user_mappings略少一点。这个视图可以被没有权限的用户查看，密码会被展示为null
pg_user_mapping	信息较少，基表，主要是option。没有访问权限的用户是查看不了的

foreign table 表/视图	含义
information_schema._pg_foreign_tables	信息较全，展示所有外部表信息
information_schema._pg_foreign_table_columns	展示了列与列的对应关系
information_schema.foreign_table_options	针对性的展示foreign table的option
foreign_tables	信息较少，基表

这些视图/表看上去挺乱的，但是实际上结构还比较清楚。4种对象的数据字典基表都基本都是一个逻辑

pg_xxx是基表，是4个对象的基础信息来源
information_schema._pg_xxx 关联了pg_xxx基表和其他一些信息，information_schema._pg_xxx是一个汇总的视图，信息比较全面
information_schema.xxx是information_schema._pg_xxx上的视图，信息少一点
information_schema.xxx_options针对性展示option信息，信息仅来自于全量视图information_schema._pg_xxx
一个特殊的视图pg_user_mappings，无权限用户也可以使用

注意权限问题
#

如果一路使用postgres超级用户去创建外部表，基本上不会遇到什么问题。但是在生产环境中通常应用用户不会是超级用户。所以，权限是非常重要的。它不仅重要而且还比较麻烦，所以使用普通用户做实验很重要（任何实验都是）。pg的权限像闯关打BOSS，缺少任何一环的权限都是不行的。权限问题需要注意以下几点

foreign data wrapper，server，user mapping的owner都是创建者，必须各自授权用户usage权限或者是owner本身才可以使用
访问远端数据源，需要使用合适权限用户，也就是在user mapping那一步指定合适的远端库登陆用户
本地库在创建/导入外部表后，对象被看成本地对象（只有数据字典），所以pg对本地对象的访问权限体系也得合适。

权限可以参考下面postgres_fdw访问外部表的示例

fdw使用示例
#

全世界已有成百上千种数据源有了相应的FDW实现，各种关系型数据库、nosql数据库、各种类型的文件、Web Service、列式存储、大数据等等。这里介绍几种常见的fdw。

postgres_fdw的使用
#

这个几乎是最常用也最强大的fdw，可以在本地库中访问外部PostgresSQL数据库。当然也可以用来自我访问，这个功能是很重要的，因为：PGSQL内部不能跨database访问！ 如果要解决这个问题，一个比较好的办法就是用fdw实现本地实例跨database访问，通过外部连接实现自己访问自己···

这里是一个用postgres_fdw实现跨database访问的例子一个实例里面有两个database，aka和bkb。你不能通过一个sql同时查询aka和bkb库，database在pg中是逻辑隔绝的，有点像oracle 12c的pdb

[lzl@postgres]=# \l
 aka | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =Tc/postgres +
 | | | | | postgres=CTc/postgres
 bkb | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =Tc/postgres +
 | | | | | postgres=CTc/postgres

虽然2个库都是本地库，但是在使用fdw的时候还是需要本地库远程库的概念。这里我们把aka当作本地库，bkb当作远程库，实现在aka库中访问bkb库的表，并处理权限问题。

1.安装fdw插件

\c aka
create extension postgres_fdw;

注意：插件是库级别的，需要切到本地库上

2.用户授权

grant usage on foreign data wrapper postgres_fdw to akadata;

3.创建server

\c aka akadata
CREATE SERVER bkb_server FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host '127.0.0.1', port '5432', dbname 'bkb');

4.创建user mapper

CREATE USER MAPPING FOR akadata SERVER bkb_server OPTIONS (user 'bkbdata', password 'bkbpasswd');

5.aka库下创建schema，schema授权给akadata用户 因为担心有重复的表名，导入到另一个schema里

\c aka postgres
create schema bkb;
grant usage on schema bkb TO akadata;
--GRANT select ON ALL TABLES IN SCHEMA bkb TO akadata;
grant all privileges on schema bkb TO akadata;

6.导入bkb表

\c aka akadata

导入整个schema

IMPORT FOREIGN SCHEMA public FROM SERVER bkb_server INTO bkb;

导入单个表

 IMPORT FOREIGN SCHEMA public LIMIT TO (tab1) FROM SERVER bkb_server INTO bkb

7.查看外部表 *注意 search_path，导入完成后\d可能看不到外部表 select * from bkb.tab1直接查询可以查到外部表数据，或者基表或视图查看所有的外部表信息

=# select * from information_schema.foreign_tables;
 foreign_table_catalog | foreign_table_schema | foreign_table_name | foreign_server_catalog | foreign_server_name 
-----------------------+----------------------+-------------------------------------+------------------------+---------------------
 aka | bkb | tab1 		| aka | bkb_server

file_fdw的使用
#

file_fdw插件为pg提供了访问外部文件的能力，目前只提供了只读能力。file_fdw已经在contrib中，可以直接CREATE EXTESION安装使用。外部文件必须是符合COPY规则的。来个经典的把pg的输出日志映射成外部表的例子，脚本来自官方文档 (注意官方文档和pgsql库的版本，pgsql的版本不同日志输出略有不同，所以建的外部表字段有一点不一样） 1.创建file_fdw插件

CREATE EXTENSION file_fdw;

2.创建外部服务

CREATE SERVER fileserver FOREIGN DATA WRAPPER file_fdw;

3.创建外部表

CREATE FOREIGN TABLE pglog (
 log_time timestamp(3) with time zone,
 user_name text,
 database_name text,
 process_id integer,
 connection_from text,
 session_id text,
 session_line_num bigint,
 command_tag text,
 session_start_time timestamp with time zone,
 virtual_transaction_id text,
 transaction_id bigint,
 error_severity text,
 sql_state_code text,
 message text,
 detail text,
 hint text,
 internal_query text,
 internal_query_pos integer,
 context text,
 query text,
 query_pos integer,
 location text,
 application_name text
) SERVER fileserver
OPTIONS ( filename 'pg_log/postgresql-07-06.csv', format 'csv' );

4.查看日志表 直接在库中查看映射的日志表，很方便查到报错信息

=# select user_name,database_name,process_id,error_severity,message from pglog where error_severity<>'LOG';
 user_name | database_name | process_id | error_severity | message 
-----------+---------------+------------+----------------+-----------------------------------------------
 appuser1 | db1 | 102349 | ERROR | value too long for type character varying(20)
 appuser1 | db1 | 55378 | ERROR | value too long for type character varying(20)
 appuser2 | db2 | 219377 | ERROR | relation "dual" does not exist

postgres_fdw深入
#

postgres_fdw性能优化
#

跟绝大多数fdw插件不同，postgres_fdw是PostgreSQL Global Development Group维护的官方插件，其源码包含contrib中。因为外部服务的功能、结构的不同，一些功能比如获得远程库的访问代价、某些场景下的聚合下推等在其他fdw中是难以实现的。但是在postgres_fdw中却可以做到，官方对 postgres_fdw做了非常多的优化，其功能已经非常强大。

SQL执行过程
#

解析器通过外部表的定义生成查询树
计划器连接到外部服务foreign server
获得cost信息。如果use_remote_estimate是true时（默认），计划器会在远程库执行explain获得访问代价（第（3）步）；如果是false，那么不会去执行explain（第（3）步）而是在本地进行计算。
deparse生成远程库SQL文本。fdw直接通过发送SQL文本的方式访问远程库对象，计划器会生成远程库执行的sql文本。执行计划Remote SQL部分可直接看见deparse生成的SQL文本：

=> explain (verbose) select a from bkb.tab1 where a=1;
 QUERY PLAN 
-----------------------------------------------------------------
 Foreign Scan on bkb.tab1 (cost=100.00..146.86 rows=15 width=4)
 Output: a
 Remote SQL: SELECT a FROM public.tab1 WHERE ((a = 1))

发送SQL语句并接收数据。远程库接收到SQL后自行执行，并按fetch_size（默认100行）返回结果给本地库

代价估算
#

postgres_fdw可以将远程库的对象访问代价传递给本地库，以计算整个SQL的执行计划代价。然而仅仅返回远程库估算的代价是不够的，还需要考虑远程访问本身的成本。postgres_fdw提供了3个OPTIONS设置来调整外部表的代价估算： use_remote_estimate：设置为true时，计划器会去远程库explain获得估算的代价，并加上fdw_startup_cost和fdw_tuple_cost的代价计算总的访问代价；如果为false（默认），planner在本地计算并加上fdw_startup_cost和fdw_tuple_cost计算出总的访问代价。本地的外部表统计信息可能与实际不一致。 fdw_startup_cost：外部表的启动代价，默认100。代表在外部服务上创建连接、解析、生成计划的代价 fdw_tuple_cost：扫描外部表每个tuple的额外代价，默认0.01。代表数据传输的代价，延时越高这个设置应该设置的越高。

默认设置下，外部表的startup cost为100：

=> explain select * from bkb.students;
 QUERY PLAN 
--------------------------------------------------------------------------
 Foreign Scan on students (cost=100.00..119.03 rows=301 width=248)

聚合下推
#

聚合下推是将运算放在远程库执行，本地库直接获得远程库的执行结果。如果没有聚合下推，数据需要全部返回给本地库并由本地库进行计算，这会增加数据传输对SQL执行效率的影响，且会加大本地库的计算负担。

(环境中的bkb.*都是外部表，本地表都是public.*)

谓词下推 postgres_fdw支持where下推，下推后不需要返回全部数据到本地库

=> explain (verbose,costs off) select f1.a from bkb.tab1 f1 where f1.a=1;
 QUERY PLAN 
---------------------------------------------------------
 Foreign Scan on bkb.tab1 f1
 Output: a
 Remote SQL: SELECT a FROM public.tab1 WHERE ((a = 1))

pg直接将整个语句发送给远程库执行，where在远程库进行过滤。

sort下推 postgres_fdw支持sort下推，同样可以发送sort给远程库执行。注意sort的默认模式。

=> explain (verbose,costs off) select f1.a from bkb.tab1 f1 order by 1 desc nulls first;
 QUERY PLAN 
---------------------------------------------------------------------
 Foreign Scan on bkb.tab1 f1
 Output: a
 Remote SQL: SELECT a FROM public.tab1 ORDER BY a DESC NULLS FIRST

join下推 一些无法下推的join不能在远程库进行计算，比如本地表join外部表，只能直接把外部表的查询结果拿到本地进行join

=> explain (verbose,costs off) select f1.a,l2.a from bkb.tab1 f1,tab1 l2 where f1.a=l2.a;
 QUERY PLAN 
-----------------------------------------------------
 Hash Join
 Output: f1.a, l2.a
 Hash Cond: (l2.a = f1.a)
 -> Seq Scan on public.tab1 l2
 Output: l2.a, l2.b
 -> Hash
 Output: f1.a
 -> Foreign Scan on bkb.tab1 f1
 Output: f1.a
 Remote SQL: SELECT a FROM public.tab1

本地表join外部表时，外部表只能全部访问（没有其他where的情况下）返回给本地库，然后又本地库做join操作

两个表都是外部表时可以下推到远程库去执行join操作

=> explain (verbose,costs off) select f1.a,f1.b from bkb.tab1 f1 left join bkb.tab2 f2 on f1.a=f2.a;
 QUERY PLAN 
-----------------------------------------------------------------------------------------------------
 Foreign Scan
 Output: f1.a, f1.b
 Relations: (bkb.tab1 f1) LEFT JOIN (bkb.tab2 f2)
 Remote SQL: SELECT r1.a, r1.b FROM (public.tab1 r1 LEFT JOIN public.tab2 r2 ON (((r1.a = r2.a))))

Remote SQL直接将join发送给远程库去执行，本地库只需要等待返回结果。

聚合函数下推 支持聚合函数下推，聚合函数必须是IMMUTABLE的

=> explain (verbose,costs off) select b,count(*),avg(a) from bkb.tab1 group by b;
 QUERY PLAN 
----------------------------------------------------------------------------
 GroupAggregate
 Output: b, count(*), avg(a)
 Group Key: tab1.b
 -> Foreign Scan on bkb.tab1
 Output: a, b
 Remote SQL: SELECT a, b FROM public.tab1 ORDER BY b ASC NULLS LAST

某些场景并不支持，比如having语句只能在本地filter，Remote SQL没有传递having文本到远程库

=> explain (verbose,costs off) select b,count(*) from bkb.tab1 group by b having count(*)>=2;
 QUERY PLAN 
-------------------------------------------------------------------------
 GroupAggregate
 Output: b, count(*)
 Group Key: tab1.b
 Filter: (count(*) >= 2)
 -> Foreign Scan on bkb.tab1
 Output: a, b
 Remote SQL: SELECT b FROM public.tab1 ORDER BY b ASC NULLS LAST

其他特性
#

远程执行相关OPTION设置
#

默认情况下，只有where中的内置运算符和函数能在远程服务执行。不是内置运算符的只能在远程库fetch数据到本地，然后在本地计算。如果内置运算符和函数能在远程执行，且运行结果和本地一致，性能会有提升。 extensions：由用户来指定哪些fdw extension可以用“远程计算”。只能在server层设置。 fetch_size：从远程库获取数据时，一次fetch的数据行数，默认为100。可以在server或table层设置。更新设置 updatable：默认情况下postgres_fdw的外部表都是可以更新的。不过可以用updatable选项来设置。如果外部表本身就是不可更新的，可以在表级设置updatable为false，使其直接在本地报错。 truncatable：pg14开始postgres_fdw支持truncate外部表，并提供truncatable选项控制外部表是否可以truncate，该选项默认为true。

连接管理
#

在会话发起第一次外部表访问时，会建立与远程库的连接，只要本地会话没有断开，就会一直使用这个连接。如果使用多个user mapping则会为每个用户映射建立连接。 pg14开始keep_connections选项可以控制这个特性。keep_connections默认为on，表示会话后续可以重用这个连接；为off时事务结束边断开连接。 pg14开始 postgres_fdw_get_connections()可查看连接情况

事务管理
#

fdw的事务特性需要注意以下几点：

远程库按本地库发送的文本执行SQL
本地有SERIALIZABLE隔离级别时，远程也是SERIALIZABLE隔离级别，否则远程是REPEATABLE READ隔离级别
本地事务提交或回滚时，远程事务也提交或回滚
fdw不支持2pc事务因为不支持分布式2PC事务，可能导致事务部分提交。比如以下示例，远程库即使更新失败，本地库的update仍然可以完成。

=> select * from tab1;
 a | b 
---+-----
 1 | abc
=> begin; --开启事务
BEGIN
=> update tab1 set b='123' ; --本地更新数据，成功
UPDATE 6
=> update bkb.tab1 set b='a' where c=1; --远程更新数据，失败
ERROR: 42703: column "c" does not exist
LINE 1: update bkb.tab1 set b='a' where c=1;
=> commit; --事务提交
COMMIT
=> select * from tab1;
 a | b 
---+-----
 1 | 123

无分布式锁管理
#

fdw没有分布式锁管理，所以也没有分布式死锁检测机制。

如果在本地库产生死锁并且deadlock_timeout设置了一个值（默认1s），会话会产生报错本地表死锁检测：

session 1	session 2
=> begin; BEGIN
	=> begin; BEGIN
=> update tab2 set b=1; UPDATE 1
	=> update tab1 set b=1; UPDATE 1
=> update tab1 set b=1; --等待
	=> update tab2 set b=1; `sql ERROR: 40P01: deadlock detected`

外部表不会检测死锁：

session a	session b
=> begin; BEGIN
	=> begin; BEGIN
=> update bkb.tab2 set b=1; UPDATE 1
	=> update tab1 set b=1; UPDATE 1
=> update tab1 set b=1; --等待
	=> update bkb.tab2 set b=1; --等待

异步执行
#

pg14开始支持postgres_fdw异步执行。在执行计划中存在多个append节点时，可以并行执行，这样能提高多个外部表访问时的性能。异步执行只能在有多个会话时才能产生，也就是说多个user mapping的情况下才会有异步执行。 async_capable选项控制异步执行特性，默认为false。另外enable_async_append参数也要打开，默认on。

这个特性十分重要，因为异步执行几乎是sharding所必要的特性。它可以实现在扫描每个sharding分片时并行的执行，既同时使用多个分片上的资源进行数据访问，提高sharding数据的访问效率。

并行提交
#

pg15开始支持postgres_fdw并行提交。远程事务随着本地事务提交而提交，在没有并行提交/回滚时，pg只能串行的提交/回滚各个远程的事务（子事务同样也是顺序提交）。当有很多外部事务关联本地事务时，所有外部事务顺序提交完这种模式效率较低。此时可以使用并行提交特性，由parallel_commit和parallel_abort选项控制，分别代表并行提交事务和并行关闭事务，默认均为false。并行提交对性能的提升参考这篇文章

postgres_fdw的版本历史
#

postgres_fdw非常强大，并且不断的在版本更新中提升。以下表格汇总了各个版本相关postgres_fdw的需要关注的功能提升：

版本	release支持说明
9.3	postgres_fdw发布
9.6	支持下推join，sort，update，delete；支持fetch_size设置
10	可下推聚合函数到外部服务；下推更多场景下的join
11	可下推算子到分区表上； UPDATE/DELETE语句的join可以下推到外部服务
12	下推更多场景下的order by/limit子句；
13	加强权限密码认证功能； pg_dump可导出外部表
14	当一个查询有多个外部表时，提供并行扫描能力，由async_capable控制；支持批量插入； postgres_fdw_get_connections()查看当前外部连接情况；支持truncate外部表
15	下推CASE表达式；支持并行提交，由server选项parallel_commit控制
16	postgres_fdw可以中断并行事务；支持外部表analyze_sampling设置；可通过batch_size选项控制COPY数据到外部表；允许外部表truncate触发器

sharding的实现
#

基于FDW实现sharding
#

有许多分支基于PostgreSQL已经实现了sharding功能，比如XC/XL、Citus等等，但是PostgreSQL本身是单实例数据库，目前还没有原生支持sharding。并且虽然很多分支实现了sharding但也会造成其版本跟PostgreSQL社区版本存在lag。由于SQL/MED本身是为了访问外部数据而定义的标准，所以postgres_fdw可以通过访问外部实例的方式实sharding功能。基于FDW实现sharding的方案目前来看是对代码改动最小的，并且很多分支也是基于这个方案来实现。所以PostgreSQL原生支持sharding一直呼声很高，社区也考虑过用postgres_fdw实现sharding功能

实现sharding的核心功能
#

一个能够使用的sharding，需要具备一些特性，以下列举几个sharding功能较为受关注的特性，其中一些功能已经在postgres_fdw实现，一些仍然to-do：

分区管理。SQL/MED拥有透明访问特点，如果sharding在分区表上实现，sharding以分区的方式附在分区表上，访问分区也是透明的，这样一来业务就完全不需要关注数据路由就可以在数据库层实现sharding。现在原生分区也可以加入外部表。
分区优化。把外部表当成分区可以使用分区表上的优化功能，比如分区裁剪、PARTITION WISE JOIN等功能可以极大的降低访问开销。
聚合下推。把数据全部采集到本地进行计算明显不是sharding的初衷，把计算放到各自的远程库分片上执行可以充分利用资源，所以DML、谓词下推、聚合函数下推等对于sharding来说很重要。
并行扫描。在没有并行扫描时，多个sharding只能顺序执行；有并行扫描后分片可以同时运行。该特性已在pg14实现
2PC事务。2PC事务可以保证分布式事务的原子性，如果没有2PC那么可能出现部分分片数据更新，部分分片更新失败的情况。该特性也比较重要，fdw目前还不支持2PC事务。
分片管理。外部表的分区不是自动添加的，只能手动完成创建和添加到分区表的操作。如果分区特别多，管理起来会很麻烦
全局事务。需要一些机制来保证全局事务一致性，比如全局时钟、全局快照管理等等
分布式锁。需要更强大的分布式锁机制
批量写入。DML/COPY等分发到分片的操作需要支持批量写入。

总结
#

PostgreSQL的FDW功能由SQL/MED标准而来，用来访问外部数据，并且支持非常多类型的数据访问
FDW有4个基本对象：foreign data wrapper，server，user mapping，foreign table
postgres_fdw有很多功能提升和性能优化，可以将算子下推到远程库
基于postgres_fdw可以实现sharding功能，有些功能还有待完善

参考
#

https://www.interdb.jp/pg/pgsql04.html https://www.postgresql.org/docs/13/postgres-fdw.html https://www.postgresql.org/docs/current/file-fdw.html https://wiki.postgresql.org/wiki/WIP_PostgreSQL_Sharding https://www.percona.com/blog/postgres_fdw-enhancement-in-postgresql-14/ https://www.percona.com/blog/foreign-data-wrappers-postgresql-postgres_fdw/ https://www.percona.com/blog/parallel-commits-for-transactions-using-postgres_fdw-on-postgresql-15/ https://www.enterprisedb.com/blog/postgresql-aggregate-push-down-postgresfdw https://www.postgresql.fastware.com/postgresql-insider-fdw-ove https://momjian.us/main/writings/pgsql/sharding.pdf https://www.slideserve.com/johnna/sql-med-and-more-powerpoint-ppt-presentation https://dbaplus.cn/news-19-2090-1.html https://www.highgo.ca/2019/08/08/horizontal-scalability-with-sharding-in-postgresql-where-it-is-going-part-3-of-3/ https://www.highgo.ca/2021/06/28/parallel-execution-of-postgres_fdw-scans-in-pg-14-important-step-forward-for-horizontal-scaling/

PostgreSQL本地化

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

本地化的概念
#

本地化的目的是支持不同国家、地区的语言特性、规则。比如拥有本地化支持后，可以使用支持汉语、法语、日语等等的字符集。除了字符集以外，还有字符排序规则和其他语言相关规则的支持，例如我们知道(‘a’,‘b’)该如何排序，那么(‘a’,‘A’)和(‘啊’,‘阿’)又该如何排序？如果通过google去搜本地化、字符集、collation相关信息，可能会得到一些复杂又遥远的知识。最好的老师还是

本地化知识点总共分为3个部分：locale本地化支持、collation校验、字符集。

locale
#

pg的本地化由由操作系统提供，需要检查操作系统是否支持locale -a。在初始化数据库时可指定locale

initdb --locale=en_US

也可以单独设置本地化子类：字符串排序、字符归类方法、数值格式、日期格式、时间格式、货币格式等

initdb --locale=zh_CN --lc-monetary=en_US

所有本地化子类：

本地化子类	规则
LC_COLLATE	String sort order
LC_CTYPE	Character classification (What is a letter? Its upper-case equivalent?)
LC_MESSAGES	Language of messages
LC_MONETARY	Formatting of currency amounts
LC_NUMERIC	Formatting of numbers
LC_TIME	Formatting of dates and times

这些子类又可以分为两部分，其中lc_messages，lc_monetary，lc_numeric，lc_time在初始化后，可以通过参数进行调整。LC_COLLATE，LC_CTYPE属于collation，详见collation的调整。 locale设置会影响如下行为：

Sort order in queries using ORDER BY or the standard comparison operators on textual data
The upper, lower, and initcap functions
Pattern matching operators (LIKE, SIMILAR TO, and POSIX-style regular expressions); locales affect both case insensitive matching and the classification of characters by character-class regular expressions
The to_char family of functions
The ability to use indexes with LIKE clauses

COLLATION
#

collation是字符排序的顺序和字符分类行为。一些数据库操作符依赖collation，比如order by、lower, upper、initcap 、to_char等等。使用如下SQL查询系统表pg_collation，来获取字符集支持的LC_COLLATE和LC_CTYPE信息

 select pg_encoding_to_char(collencoding) as encoding,collname,collcollate,collctype from pg_collation where collname in ('default','C','POSIX','en_US.utf8','zh_CN.utf8','zh_CN.gb2312','zh_SG.gb2312') ;
 encoding | collname | collcollate | collctype 
----------+--------------+--------------+--------------
 | default | | 
 | C | C | C
 | POSIX | POSIX | POSIX
 UTF8 | en_US.utf8 | en_US.utf8 | en_US.utf8
 EUC_CN | zh_CN.gb2312 | zh_CN.gb2312 | zh_CN.gb2312
 UTF8 | zh_CN.utf8 | zh_CN.utf8 | zh_CN.utf8
 EUC_CN | zh_SG.gb2312 | zh_SG.gb2312 | zh_SG.gb2312

encoding是字符集，collname为collation的名字

encoding 为空时，表示这个 collation 支持所有的字符集
default, C, POSIX是所有平台都支持的collation，由libc提供，其他collation取决于操作系统是否支持(locale -a)
default表示使用建库时的collation，可通过\l查看
C语义上等价于POSIX，但是PG仍然认为他们是不同的collation。他们的字符都以ASCII码对比，严格按照字节序比对大小。

=> SELECT 'a' COLLATE "C" < 'b' COLLATE "POSIX" ;
ERROR: 42P21: collation mismatch between explicit collations "C" and "POSIX"
LINE 1: SELECT 'a' COLLATE "C" < 'b' COLLATE "POSIX" ;
LOCATION: merge_collation_state, parse_collate.c:834

UTF8是最常见的字符集，我们最常见的语言环境是en_US和zh_CN
可以通过CREATE COLLATION ...创建自定义的collation。不过LC_COLLATE和LC_CTYPE不同的情况非常少见

LC_COLLATE
#

LC_COLLATE影响字符比对（排序、字符操作等等） collate子句可以转化表达式的collation：

expr COLLATE collation

注意这里指定的是collation，不是lc_collate。如果没有显示指定collation，数据库默认使用字段的collation，如果字段没有指定collation，使用database的默认collation。

不同的collation排序测试：

 select col1 from (values ('a'), ('A'), ('啊'), ('阿')) 
-> AS l(col1)
-> order by col1 collate "C";
 col1 
------
 A
 a
 啊
 阿
 select col1 from (values ('a'), ('A'), ('啊'), ('阿')) 
-> AS l(col1)
-> order by col1 collate "en_US.utf8";
 col1 
------
 a
 A
 啊
 阿
 select col1 from (values ('a'), ('A'), ('啊'), ('阿')) 
-> AS l(col1)
-> order by col1 collate "zh_CN.utf8";
 col1 
------
 a
 A
 阿
 啊

这3个不同的collation有不同的lc_collate，排序方法应该是不一样的，从结果来看确实是不一样的，出现了3种排序结果。 collation C为什么A<a? collation C使用的ASCII的编码顺序，ASCII码中大写在小写前面。而en_US.utf8和zh_CN.utf8的英文字母明显不是这个顺序 中文的顺序 同样是utf8字符集，中文环境和英文环境的中文顺序不一样。不同的lc_collate对于不同本地化语言，应该都可以对应到不同的alphabets。其中，lc_collate=C的排序一定是按字节序排的，虽然ASCII没有中文，但是C也可以排序中文，（基本）每个中文都可以对应UTF8的一个编码，而C以其字节序排序。

LC_CTYPE
#

LC_CTYPE影响字符操作（如upper、initcap等）如果字符串都是英文，比如是’abcD’，initcap在3种collation下都会转换为’Abcd’，这里不多展示了。但是加入中文，结果就不一样了：

select initcap('啊aAAa阿bBBb' collate "C");
 initcap 
--------------
 啊Aaaa阿Bbbb

select initcap('啊aAAa阿aAAa' collate "en_US.utf8");
 initcap 
--------------
 啊aaaa阿aaaa

select initcap('啊aAAa阿aAAa' collate "zh_CN.utf8");
 initcap 
--------------
 啊aaaa阿aaaa

LC_CTYPE=C时，initcap把每个非连续英文字符串的首字母大写，而en_US.utf8和zh_CN.utf8只会将首个字符大写（中文就不会变），其他英文字符小写。 initcap中文也许处于需求不明的状况，但是我们可以得出结论：不同的LC_CTYPE会导致initcap等字符敏感函数结果不一样。另外，中文对于大小写不敏感，一些其他本地化语言同样有大小写，不同的LC_CTYPE导致的结果会更复杂。

字符集
#

字符集基础
#

PostgreSQL支持不同的字符集character sets（也叫encodings）。字符集于collation是两个概念，但是字符集必须跟LC_CTYPE，LC_COLLATE兼容。就像在pg_collation中看到的那样，C/POSIX支持所有字符集，而其他collation只支持一种字符集（linux系统中）。

PostgreSQL中文相关可用的字符集： (*collation C由libc库提供，部分collation可以由ICU库提供，需提前编译)

Name	Description	Language	Server端是否支持?	ICU是否支持?	Bytes/Char	Aliases
BIG5	Big Five	繁体中文	No	No	1–2	WIN950, Windows950
EUC_CN	Extended UNIX Code-CN	简体中文	Yes	Yes	1–3	GB2312
GB18030	National Standard	中文	No	No	1–4
GBK	Extended National Standard	简体中文	No	No	1–2	WIN936, Windows936
UTF8	Unicode, 8-bit	all	Yes	Yes	1–4	Unicode

繁体中文： BIG5是最常见的繁体中文字符集标准。之前是业界标准，后来被录入为国家标准。 简体中文： GB是国标的意思，GB2312、GB18030、GBK都是我国的国家字符集标准。由于生僻字等问题，并经过多年发展产生了一些历史版本，所以标准看上去有多个。其中EUC_CN全称为 Extended UNIX Code-CN ，其实就是GB2312，但它也不能处理所有罕见字。类似命名的还有EUC_KR,EUC_JP,EUC_TW等等。 国际标准：上面的字符集都是国家标准，他们除了支持英、中外不支持其他语言。而国际标准支持世界上所有语言，这就是unicode国际编码标准(甚至emoji也包含其中 👍)。（还有个著名的国际标准组织ISO也在维护字符集，他俩有交集，这里先忽略ISO）。由于Unicode编码方案的不同又有UTF-8、UTF-16、UTF-32三种编码方式。

UTF-8编码格式:

字节	格式	实际编码位	码点范围
1字节	0xxxxxxx	7	0 ~ 127
2字节	110xxxxx 10xxxxxx	11	128 ~ 2047
3字节	1110xxxx 10xxxxxx 10xxxxxx	16	2048 ~ 65535
4字节	11110xxx 10xxxxxx 10xxxxxx 10xxxxxx	21	65536 ~ 2097151

UTF8编码是变长的。 0x00-0x7F之间的字符(1字节），UTF-8编码与ASCII（American Standard Code for Information Interchange 美国标准信息交换代码）编码完全相同，所以UTF-8是完全兼容ASCII的。由于同源、同义、相似性，在unicode中中日韩越使用了同一编码，称为中日韩统一表意文字（或称中日韩越统一表意文字）。中日韩统一表意文字编码范围为：3400-4DBF/4E00-9FFF/20000-3FFFF

字符集转换
#

server_encoding与client_encoding不一致，可发生自动转换Server查出来的字符集。设置服务端字和客户端字符集参考设置字符集一节。中文相关字符集Server/Client可转化表：

Server Character Set	Available Client Character Sets
BIG5	not supported as a server encoding
EUC_CN（GB2312）	EUC_CN（GB2312）, `MULE_INTERNAL`, `UTF8`
GB18030	not supported as a server encoding
GBK	not supported as a server encoding
UTF8	*all supported encodings*
GB18030，GBK服务端都不支持，所以其实只有EUC_CN（GB2312）、UTF8能在Server/Client转换。

以上是可以转换的字符集，仍需要CONVERSATION的支持。PG内置了一些转换函数，可通过pg_conversion查看：

Conversion Name	Source Encoding	Destination Encoding
big5_to_utf8	BIG5	UTF8
euc_cn_to_utf8	EUC_CN	UTF8
gb18030_to_utf8	GB18030	UTF8
gbk_to_utf8	GBK	UTF8
utf8_to_big5	UTF8	BIG5
utf8_to_euc_cn	UTF8	EUC_CN
utf8_to_gb18030	UTF8	GB18030
utf8_to_gbk	UTF8	GBK

可通过create conversation语句创建自定义的转换，需指定转换的function。有些字符集间看上去可以转换，但是server端根本不支持存储这些字符集（如big5、gb18030、gbk），所以也没啥用。我们这里仅需要知道euc_cn和utf8能相互转换就可以了。没有CONVERSATION是不能发生转换的：

--EUC_CN的database
=> \encoding EUC_KR
EUC_KR: invalid encoding name or conversion procedure not found

字符集转换测试： 需要注意客户端的字符集设置（如CRT的 “session”-“Appearance”-“Character encoding”） 至少有3个端有字符集的概念：数据库server、数据库client、UI客户端。CONVERSATION也只能控制：数据库server -> 数据库client 1.server为UTF8的转换测试：

create table zh(col1 varchar(20));
insert into zh values('>'),('阿'),('〇'); --〇 ling是一个中文
--CRT不设置为UTF8中文全是乱码，只有CRT设置UTF8来插入

=> show server_encoding;
 server_encoding 
-----------------
 UTF8
=> show client_encoding;
 client_encoding 
-----------------
 UTF8
--完全没有转换的情况下，UTF8正常展示。此时3端字符集为：UTF8 - UTF8 - UTF8
=> select * from zh;
 col1 
------
 >
 阿
 〇

--切换数据库client字符集，此时3端字符集为：UTF8 - EUC_CN - UTF8
=> \encoding EUC_CN; --设置客户端字符集

=> select * from zh where col1 in ('阿');
ERROR: 22021: invalid byte sequence for encoding "EUC_CN": 0xe9 0x98
LOCATION: report_invalid_encoding, mbutils.c:1597
Time: 0.112 ms
=> select * from zh where col1 in ('〇');
ERROR: 22021: invalid byte sequence for encoding "EUC_CN": 0xe3 0x80
ERROR: 22021: invalid byte sequence for encoding "EUC_CN": 0xe3 0x80
--“阿”和“〇”看上去不能转换为EUC_CN，但不是这样的
 
=> select * from zh limit 2;
 col1 
------
 >
 <B0><A2>
(2 rows)
--第二行即是"阿"，数据库server/client看上去转换了字符集，从UTF8转换为了EUC_CN
--但是可能是因为UI客户端问题没有正确显示（此时UI客户端CRT为UTF8）

--然而把CRT改成GB2312还是不会正确展示
select * from zh limit 2;
 col1 
------
 >
 <B0><A2>
(2 rows)

--当查询〇时，数据库直接抛出报错，说明〇不能从UTF8转换为EUC_CN
select * from zh ;
ERROR: 22P05: character with byte sequence 0xe3 0x80 0x87 in encoding "UTF8" has no equivalent in encoding "EUC_CN"
LOCATION: report_untranslatable_char, mbutils.c:1631

2.server为EUC_CN的转换测试：

=> show server_encoding; --database为EUC_CN字符集
server_encoding 
-----------------
EUC_CN

--在EUC_CN库下同样创建一个zh表，此时尝试插入就有问题了 
=> insert into zh values('〇');
ERROR: 22P05: character with byte sequence 0xe3 0x80 0x87 in encoding "UTF8" has no equivalent in encoding "EUC_CN"
LOCATION: report_untranslatable_char, mbutils.c:1631

同样报错〇不能从UTF8转换为EUC_CN。EUC_CN（GB2312）中文编码不完全与UTF8相同，EUC_CN（GB2312）不是所有中文都包含的，特别是罕见字。

设置locale、collation和字符集
#

上面已经了解过本地化和字符集设置了，这里做一个汇总

database cluster的locale、collation、字符集
#

初始化时可设置database cluster的locale和字符集，参考：

initdb -D $DATADIR -E UTF8 --locale=en_US.UTF8 
initdb -D $DATADIR -E UTF8 --locale=en_US.UTF8 --lc_collate=C --lc_ctype=C
initdb -D $DATADIR -E UTF8 --locale=en_US.UTF8 --lc_collate=C --lc_ctype=C --lc-messages=en_US.UTF8 --lc-monetary=en_US.UTF8 --lc-numeric=en_US.UTF8 --lc-time=en_US.UTF8

initdb会创建postgres，template1，和template0三个库。create database语句时默认使用template1创建库。

encoding设置字符集；locale设置LC_COLLATE，LC_CTYPE，LC_MESSAGES，LC_MONETARY，LC_NUMERIC，LC_TIME，除非特别指定（如–lc_collate）
LC_COLLATE，LC_CTYPE称为collation，还可在database、列、索引上设置。LC_MESSAGES，LC_MONETARY，LC_NUMERIC，LC_TIME为实例参数，可随时修改。
encoding只能在初始化、创建database时设置，一旦设置不可修改。

database的collation、字符集
#

创建database时可设置database的字符集、lc_collate、lc_ctype。

create database ,createdb都可以在创建database时指定字符集，一旦创建就不能修改database的字符集。两个命令都是使用template库来创建database

template又有template0和template1，官方文档有这样一句话：

Another common reason for copying template0 instead of template1 is that new encoding and locale settings can be specified when copying template0, whereas a copy of template1 must use the same settings it does. This is because template1 might contain encoding-specific or locale-specific data, while template0 is known not to.

template1是可写数据的模板库，可能包含本地化过的数据，而template0不能写数据，所以要创建不同的本地化库应使用template0。

而且要显示使用template0，因为不指定的话默认是template1。所以在创建database时没有指定template1且指定其他字符集会报错：

=> create database db_GB2312 ENCODING 'EUC_CN' LC_COLLATE 'zh_CN.gb2312' LC_CTYPE 'zh_CN.gb2312';
ERROR: 22023: new encoding (EUC_CN) is incompatible with the encoding of the template database (UTF8)
HINT: Use the same encoding as in the template database, or use template0 as template.

另外，不能在创建database时通过指定locale来设置字符集

=> create database db_GB2312 locale 'zh_CN.gb2312' template 'template0';
ERROR: 22023: encoding "UTF8" does not match locale "zh_CN.gb2312"
DETAIL: The chosen LC_CTYPE setting requires encoding "EUC_CN".
LOCATION: check_encoding_locale_matches, dbcommands.c:773

报错表示需要指定LC_CYTPE子选项，把collation相关子选项全部加上仍然报错：

=> create database db_GB2312 LOCALE 'EUC_CN' LC_COLLATE 'zh_CN.gb2312' LC_CTYPE 'zh_CN.gb2312';
ERROR: 42601: conflicting or redundant options
DETAIL: LOCALE cannot be specified together with LC_COLLATE or LC_CTYPE.

LOCALE又不能跟LC_CTYPE等子选项一起使用然后把locale去掉，通过设置字符集、LC_COLLATE、LC_CTYPE 来设置，可以成功。

创建指定字符集的database的正确姿势：

create database

create database db_GB2312 ENCODING 'EUC_CN' LC_COLLATE 'zh_CN.gb2312' LC_CTYPE 'zh_CN.gb2312' template 'template0';

createdb 通过cli命令createdb来创建，createdb封装了create database，他俩是等价的：

 createdb -E EUC_CN -T template0 --lc-collate=zh_CN.gb2312 --lc-ctype=zh_CN.gb2312 db_GB2312

查看database字符集：

\l
pg_database

select datname,pg_encoding_to_char(encoding),datcollate,datctype,datlocprovider,daticulocale from pg_database;

show参数

SERVER_ENCODING,LC_COLLATE,LC_CTYPE三个参数都是不可更改的，分别展示当前database的server端字符集、LC_COLLATE、LC_CTYPE

列的collation
#

collation只跟字符排序、字符函数相关，跟编码不相关。在没有索引的情况下，修改列的collation相当于只是在调整这个列的default排序输出，有索引的情况下会重建索引。不指定列的collation默认与database一致。

建表时指定collation：（注意有些字段类型是un-collatable的，比如int）

create table t1(col1 varchar(10) collate "en_US.utf8");
alter table t1 alter column col1 type varchar(10) collate "C";

注意：alter table不修改长度是不会重建表的，但是一定会重建索引

查看列的默认collation：

1. \d+ t1

2. information_schema.columns
select table_catalog,table_schema,table_name,column_name,collation_name from information_schema.columns where table_name='t1';

3. pg_attribute
select a.attrelid::regclass,a.attname,a.attcollation,c.collname,c.collcollate,c.collctype from pg_attribute a left join pg_collation c on a.attcollation=c.oid where a.attrelid::regclass='tlzl'::regclass and a.attcollation<>0;

推荐方式3查看。\d+ ,information_schema.columns虽然能看到collname，但是collname不是唯一的。只有方式3可以看到collate,ctype

指定collate和查看pg_attribute的测试：

create table tlzl(
 col1 varchar(10) ,
 col2 varchar(10) collate "C",
 col3 varchar(10) collate "zh_CN",
 col4 varchar(10) collate "en_US.utf8"
);

 --列的collation相当于给列打上默认排序的标记，也看不到具体是哪个collate和ctype
db_utf8_c=> Table "public.tlzl"
 Column | Type | Collation | Nullable | Default | Storage | Compression | Stats target | Description 
--------+-----------------------+------------+----------+---------+----------+-------------+--------------+-------------
 col1 | character varying(10) | | | | extended | | | 
 col2 | character varying(10) | C | | | extended | | | 
 col3 | character varying(10) | zh_CN | | | extended | | | 
 col4 | character varying(10) | en_US.utf8 | | | extended | | | 
--collname和collate，ctype不是一一对应的，上面的col3 zh_CN看不出来collate是哪个
db_utf8_c=> select pg_encoding_to_char(collencoding) as encoding,collname,collcollate,collctype from pg_collation where collname like 'zh_CN%';
 encoding | collname | collcollate | collctype 
----------+--------------+--------------+--------------
 EUC_CN | zh_CN | zh_CN | zh_CN
 EUC_CN | zh_CN.gb2312 | zh_CN.gb2312 | zh_CN.gb2312
 UTF8 | zh_CN.utf8 | zh_CN.utf8 | zh_CN.utf8
 UTF8 | zh_CN | zh_CN.utf8 | zh_CN.utf8
 
--pg_attribute展示比\d+准确
db_utf8_c=> select a.attrelid::regclass,a.attname,a.attcollation,c.collname,c.collcollate,c.collctype from pg_attribute a left join pg_collation c on a.attcollation=c.oid where a.attrelid::regclass='tlzl'::regclass and a.attcollation<>0;
 attrelid | attname | attcollation | collname | collcollate | collctype 
----------+---------+--------------+------------+-------------+------------
 tlzl | col1 | 100 | default | | 
 tlzl | col2 | 950 | C | C | C
 tlzl | col4 | 12562 | en_US.utf8 | en_US.utf8 | en_US.utf8
 tlzl | col3 | 13200 | zh_CN | zh_CN.utf8 | zh_CN.utf8
--此时才知道，col3 zh_CN的collate是zh_CN.utf8 

修改列的collate重写测试：

--给字段加索引，看看重写情况
db_utf8_c=> create index idxcol4 on tlzl(col4);
CREATE INDEX

db_utf8_c=> select pg_relation_filepath('tlzl') TableRelid, pg_relation_filepath('idxcol4') IndexRelid; 
 tablerelid | indexrelid 
------------------+------------------
 base/40996/41006 | base/40996/41015

db_utf8_c=> alter table tlzl alter column col4 type varchar(10) collate "C";
ALTER TABLE
db_utf8_c=> select pg_relation_filepath('tlzl') TableRelid, pg_relation_filepath('idxcol4') IndexRelid; 
 tablerelid | indexrelid 
------------------+------------------
 base/40996/41006 | base/40996/41016
--表没有重写，索引重写了

列的collation只是标记，修改列的collation不会重写表，但是如果其上有索引，那么会重写这个索引（有时候不会见下面一节）。

索引的collation
#

在创建索引时，如不显示指定索引的collation，那么索引会使用列上声明的collation。

创建索引时显示使用collation：

create index idx_C on tlzl(col3 collate "C");

另外，索引还可以以text_pattern_ops，varchar_pattern_ops，bpchar_pattern_ops来创建，此时的索引不依赖collation的规则，而是一个字符一个字符的对比

The difference from the default operator classes is that the values are compared strictly character by character rather than according to the locale-specific collation rules.

CREATE INDEX test_index ON test_table (col varchar_pattern_ops);

其实这种索引跟collation不是完全无关，索引一定有一个排序规则，这种索引的排序规则看上去跟C一致。参考like不走索引一节

查看索引的collation:

\d+ --\d+会展示指定过collate的索引，如果没有的话使用的是列默认索引
db_utf8_c=> \d+ tlzl
 Table "public.tlzl"
 Column | Type | Collation | Nullable | Default | Storage | Compression | Stats target | Description 
--------+-----------------------+------------+----------+---------+----------+-------------+--------------+-------------
 col1 | character varying(10) | | | | extended | | | 
 col2 | character varying(10) | C | | | extended | | | 
 col3 | character varying(10) | zh_CN | | | extended | | | 
 col4 | character varying(10) | en_US.utf8 | | | extended | | | 
Indexes:
 "idx_c" btree (col3 COLLATE "C")
 "idxcol4" btree (col4)
Access method: heap

通过pg_index查看更为清晰:（pg_index的indcollation类型是oidvector的，不能直接转化为oid，查起来麻烦点）

db_utf8_c=> select indcollation,indexrelid::regclass from pg_index where indexrelid::regclass ='idx_C'::regclass;
 indcollation | indexrelid 
--------------+------------
 950 | idx_c

db_utf8_c=> select oid,pg_encoding_to_char(collencoding) as encoding,collname,collcollate,collctype from pg_collation where oid=950;
 oid | encoding | collname | collcollate | collctype 
-----+----------+----------+-------------+-----------
 950 | | C | C | C

另外，不能通过alter index改变索引的collation，只能删除重建

测试：指定过索引collate后，修改列的collate是否会重写索引？

db_utf8_c=> select pg_relation_filepath('tlzl') TableRelid, pg_relation_filepath('idxcol4') IndexRelid4,pg_relation_filepath('idx_c') IndexRelidC; 
 tablerelid | indexrelid4 | indexrelidc 
------------------+------------------+------------------
 base/40996/41020 | base/40996/41023 | base/40996/41024
(1 row)

db_utf8_c=> alter table tlzl alter column col3 type varchar(10) collate "en_US.utf8";
ALTER TABLE
db_utf8_c=> select pg_relation_filepath('tlzl') TableRelid, pg_relation_filepath('idxcol4') IndexRelid4,pg_relation_filepath('idx_c') IndexRelidC; 
 tablerelid | indexrelid4 | indexrelidc 
------------------+------------------+------------------
 base/40996/41020 | base/40996/41023 | base/40996/41024 --idx_c的relfileid没有变

如果指定过索引的collate，修改其字段默认collate，不会重新索引。

客户端的字符集
#

客户端设置与database不同的字符集，会发生字符集转换，也可能转换不成功，具体参考字符集转换一节。

服务端的字符集在创建database后无法改变，client的字符集可随时调整。

Client字符集设置方法很多：

直接在客户端设置

\encoding UTF8 --仅psql支持
SET CLIENT_ENCODING TO UTF8; --session级修改参数
SET NAMES UTF8; --sql标准

设置环境变量PGCLIENTENCODING
设置client_encoding服务端配置参数

优先级：客户端设置>环境变量PGCLIENTENCODING>client_encoding服务端配置参数

查看client字符集：

\encoding --仅psql支持
SHOW client_encoding;

表达式collate
#

表达式加collate会覆盖表达式原本的collation，相当于指定了排序collation。

需在表达式的最后加collate关键字：

expr COLLATE collation

--例如
select * from tab1 order by name COLLATE "C";

排序和collate索引选择详见排序结果问题一节。

MORE
#

概念整理
#

PostgreSQL本地化有三个重要概念：字符集、locale、collation，需要弄清他们的关系。

字符集在服务端的设置非常重要，只能在初始化和建db时指定，建库后不可修改。字符集选择直接影响编码方式，collation并不是，但是他俩之间有依赖关系。locale同样可以在初始化时指定，其中collation可在建库时指定，也可以单独指定列的collation，注意他们只是默认值。只有在建索引时指定collation，会影响其真正的存储顺序。不同的collation是无法使用索引的，即使他们同源。

client字符集和LC_MASSAGES等4个参数都比较简单，可直接修改参数，与数据存储无关。

排序结果问题
#

因为utf8是最常见的字符集，我们测试utf相关的collation排序

create database db_UTF8 ENCODING 'UTF8' template 'template0'; --建一个UTF8的库，collation无所谓
use db_UTF8;
create table tzlz(name varchar(10));
insert into tzlz values('a'),('aa'),('A'),('AA'),('啊'),('阿'),('〇');

不同collation的order by结果：

select name from tzlz where name in ('a','aa','A','AA','啊','阿','〇') order by name;
select name from tzlz where name in ('a','aa','A','AA','啊','阿','〇') order by name collate "C";
select name from tzlz where name in ('a','aa','A','AA','啊','阿','〇') order by name collate "en_US";
select name from tzlz where name in ('a','aa','A','AA','啊','阿','〇') order by name collate "en_US.utf8";
select name from tzlz where name in ('a','aa','A','AA','啊','阿','〇') order by name collate "zh_CN";
select name from tzlz where name in ('a','aa','A','AA','啊','阿','〇') order by name collate "zh_CN.utf8";

顺序	default	C	en_US	en_US.utf8	zh_CN	zh_CN.utf8
1	〇	A	〇	〇	a	a
2	a	AA	a	a	A	A
3	A	a	A	A	aa	aa
4	aa	aa	aa	aa	AA	AA
5	AA	〇	AA	AA	阿	阿
6	啊	啊	啊	啊	啊	啊
7	阿	阿	阿	阿	〇	〇

这里的default是en_US.utf8（字段collation(default)->database collation(en_US.utf8)）

🌟 C、en_US.uft8、zh_CN.uft8排序结果都不同

collate和索引扫描测试：

insert into tzlz values(generate_series(1,10000));
create index idxzlz_default on tzlz(name);
create index idxzlz_C on tzlz(name collate "C");
create index idxzlz_enUS_utf8 on tzlz(name collate "en_US.utf8");

使用collate在索引上的优化：

--不加任何collate关键字，简单的索引扫描，不会额外排序
db_utf8_c=> explain select name from tzlz where name in ('a','aa','A','AA','啊','阿','〇') order by name;
 QUERY PLAN 
---------------------------------------------------------------------------------
 Index Only Scan using idxzlz_default on tzlz (cost=0.29..30.13 rows=8 width=4)
 Index Cond: (name = ANY ('{a,aa,A,AA,啊,阿,〇}'::text[]))

--谓词加collate转换，可以走到正确的索引
db_utf8=> explain select name from tzlz where name collate "C" in ('a','aa','A','AA','啊','阿','〇');
 QUERY PLAN 
---------------------------------------------------------------------------
 Index Only Scan using idxzlz_c on tzlz (cost=0.29..30.12 rows=7 width=4)
 Index Cond: (name = ANY ('{a,aa,A,AA,啊,阿,〇}'::text[]))

db_utf8=> explain select name from tzlz where name collate "en_US.utf8" in ('a','aa','A','AA','啊','阿','〇');
 QUERY PLAN 
-----------------------------------------------------------------------------------
 Index Only Scan using idxzlz_enus_utf8 on tzlz (cost=0.29..30.12 rows=7 width=4)
 Index Cond: (name = ANY ('{a,aa,A,AA,啊,阿,〇}'::text[]))
 
--但是collation的名字必须一致
db_utf8=> explain select name from tzlz where name collate "en_US" in ('a','aa','A','AA','啊','阿','〇');
 QUERY PLAN 
-----------------------------------------------------------------
 Seq Scan on tzlz (cost=0.00..232.63 rows=7 width=4)
 Filter: ((name)::text = ANY ('{a,aa,A,AA,啊,阿,〇}'::text[]))
 
--同时order by也需要加collate转换表达式
--此时使用了正确的索引，但是order by的时候判断为不同的collation（哪怕他们是一样的）
db_utf8=> explain select name from tzlz where name collate "en_US.utf8" in ('a','aa','A','AA','啊','阿','〇') order by name;
 QUERY PLAN 
-----------------------------------------------------------------------------------------
 Sort (cost=30.22..30.23 rows=7 width=4)
 Sort Key: name
 -> Index Only Scan using idxzlz_enus_utf8 on tzlz (cost=0.29..30.12 rows=7 width=4)
 Index Cond: (name = ANY ('{a,aa,A,AA,啊,阿,〇}'::text[]))

--where和order by都加上collate转换，可以小选择正确的索引，且不会在发生排序
db_utf8=> explain select name from tzlz where name collate "en_US.utf8" in ('a','aa','A','AA','啊','阿','〇') order by name collate "en_US.utf8";
 QUERY PLAN 
------------------------------------------------------------------------------------
 Index Only Scan using idxzlz_enus_utf8 on tzlz (cost=0.29..30.12 rows=7 width=42)
 Index Cond: (name = ANY ('{a,aa,A,AA,啊,阿,〇}'::text[]))

索引在指定collation后，sql需要显示使用collate关键字转换表达式，即便default与当前collation一致，pg也不会使用到索引。

like不走索引
#

The drawback of using locales other than C or POSIX in PostgreSQL is its performance impact. It slows character handling and prevents ordinary indexes from being used by LIKE

PostgreSQL原话：使用非C or POSIX会阻止使用普通索引！

db_utf8=> explain select name from tzlz where name like 'a%';

 QUERY PLAN 
--------------------------------------------------------------------------

 Index Only Scan using idxzlz_c on tzlz (cost=0.29..4.31 rows=1 width=4)
 Index Cond: ((name >= 'a'::text) AND (name < 'b'::text))
 Filter: ((name)::text ~~ 'a%'::text)
(3 rows)

db_utf8=> explain select name from tzlz where name collate "en_US.utf8" like 'a%';

 QUERY PLAN 
--------------------------------------------------------------------------

 Index Only Scan using idxzlz_c on tzlz (cost=0.29..4.31 rows=1 width=4)
 Index Cond: ((name >= 'a'::text) AND (name < 'b'::text))
 Filter: ((name)::text ~~ 'a%'::text)

PostgreSQL在索引扫描时把like转化为了>=和<，<还加了一个比输入的值大一号的值，这里就有问题了，collation跟排序强相关，ASCII码中a+1是b，但是汉字又如何？

db_utf8=> explain select name from tzlz where name collate "en_US.utf8" like '阿%';
 QUERY PLAN 
--------------------------------------------------------------------------
 Index Only Scan using idxzlz_c on tzlz (cost=0.29..6.49 rows=1 width=4)
 Index Cond: ((name >= '阿'::text) AND (name < '陿'::text))
 Filter: ((name)::text ~~ '阿%'::text)

果然出现了另一个汉字！

如果是全表扫描，不会出现>= <的情况

db_utf8=> drop index idxzlz_c;
DROP INDEX
db_utf8=> explain select name from tzlz where name collate "en_US.utf8" like '阿%';
 QUERY PLAN 
------------------------------------------------------
 Seq Scan on tzlz (cost=0.00..170.09 rows=1 width=4)
 Filter: ((name)::text ~~ '阿%'::text)

可以创建一个与collation规则无关的索引（pg官方声称无关）

CREATE INDEX idx_pattern ON tzlz (name varchar_pattern_ops);

来看看他的执行计划

db_utf8=> explain select name from tzlz where name like '阿%';

 QUERY PLAN 
-----------------------------------------------------------------------------

 Index Only Scan using idx_pattern on tzlz (cost=0.29..6.49 rows=1 width=4)
 Index Cond: ((name ~>=~ '阿'::text) AND (name ~<~ '陿'::text))
 Filter: ((name)::text ~~ '阿%'::text)

他还是把大1号的字符串自己生成了，这跟collation一定是有关系的···，看上去就是C

所以可以得出结论：

pg在like使用普通索引时，需要把其转换为>= <，此时必须出现一个比当前字符串大1的值。而collation又与大小强相关，此时只能使用同一collation索引才能保证数据正确。pg选择了非本地化的collation C。

临时解决这个问题最快的办法是新建一个collation C或pattern索引:

create index idxzlz_C on tzlz(name collate "C");
CREATE INDEX idx_pattern ON tzlz (name varchar_pattern_ops);

其他调整各级别的默认collation参考上面的章节。

开发习惯在建索引时不会指定collation，如果不是C或pattern，都走不了like，在加上要选择国际字符集utf8，这样在数据库运维时选择的本地化方式就非常少了。字符集为utf8，collation为C

参考
#

https://dbafix.com/what-is-the-impact-of-lc_ctype-on-a-postgresql-database/#:~:text=Having%20LC_CTYPE%20set%20to%20%E2%80%98C%E2%80%99%20implies%20that%20C,Postgres%20on%20top%20of%20these%20libc%20functions%2C%20they%E2%80%99re https://www.postgresql.org/docs/current/charset.html https://www.bookstack.cn/read/rds-best-pratice/bfc0037fe00d87dc.md https://help.aliyun.com/zh/rds/apsaradb-rds-for-postgresql/configure-the-collation-of-a-database-on-an-apsaradb-rds-for-postgresql-instance https://baike.baidu.com/item/%E7%BB%9F%E4%B8%80%E7%A0%81/2985798?fromModule=lemma_inlink&fromtitle=Unicode&fromid=750500 https://baike.baidu.com/item/%E4%B8%AD%E6%97%A5%E9%9F%A9%E8%B6%8A%E7%BB%9F%E4%B8%80%E8%A1%A8%E6%84%8F%E6%96%87%E5%AD%97/1301611?fromModule=lemma_inlink

https://blog.csdn.net/songyundong1993/article/details/128739919

PostgreSQL分区表

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

什么是分区表
#

数据库分区表将表数据分成更小的物理分片，以此提高性能、可用性、易管理性。分区表是关系型数据库中比较常见的对大表的优化方式，数据库管理系统一般都提供了分区管理，而业务可以直接访问分区表而不需要调整业务架构，当然好的性能需要合理的分区访问方式。

分区表是数据库中常见的技术，而PostgreSQL中的分区表有许多专有的特性，比如分区表实现方案多、分区为普通表、分区维护方案、SQL优化还有一些分区表的问题。

分区表的实现
#

PostgreSQL数据库有各式各样的分区实现方式。官方支持的有声明式分区和继承式分区，而三方插件包括pathman、partman等等。在官方声明式分区实现后，基本只推荐一种分区方式：声明式分区。由于再拓展不同实现的分区表的功能、细节、历史等差别会使篇幅过长，且未来意义不大，本篇主要讨论的是声明式分区，其他方式实现的分区功能只会简单介绍。但是由于历史存量和一些功能差异，了解声明分区、继承分区、pathman还是有必要的。

声明分区表
#

声明分区也叫原生分区，从PG10版本开始支持，相当于“官方支持”的分区表，也是最为推荐的分区方式。虽然与继承分区不一样，但是其内部也是用继承表实现的。声明分区只支持3种分区方式：range分区、list分区、hash分区

range分区
#

range分区表以范围进行分区，分区边界为[t1,t2)

CREATE TABLE PUBLIC.LZLPARTITION1
(
 id int,
 name varchar(50) NULL, 
 DATE_CREATED timestamp NOT NULL DEFAULT now()
) PARTITION BY RANGE(DATE_CREATED);

alter table public.lzlpartition1 add primary key(id,DATE_CREATED)

create table LZLPARTITION1_202301 partition of LZLPARTITION1 for values from ('2023-01-01 00:00:00') to ('2023-02-01 00:00:00');

create table LZLPARTITION1_202302 partition of LZLPARTITION1 for values from ('2023-02-01 00:00:00') to ('2023-03-01 00:00:00');

--往分区表添加一些数据
=> INSERT INTO lzlpartition1 SELECT random() * 10000, md5(g::text),g 
FROM generate_series('2023-01-01'::date, '2023-02-28'::date, '1 minute') as g;
INSERT 0 83521

range分区的from t1 to t2，为[t1,t2)范围，下边界包含上边界不包含。

查看分区表，每个分区也是单独的表

lzldb=> \d+ lzlpartition1
 Partitioned table "public.lzlpartition1"
 Column | Type | Collation | Nullable | Default | Storage | Compression | Stats target | Description 
--------------+-----------------------------+-----------+----------+---------+----------+-------------+--------------+-------------
 id | integer | | not null | | plain | | | 
 name | character varying(50) | | | | extended | | | 
 date_created | timestamp without time zone | | not null | now() | plain | | | 
Partition key: RANGE (date_created)
Indexes:
 "lzlpartition1_pkey" PRIMARY KEY, btree (id, date_created)
Partitions: lzlpartition1_202301 FOR VALUES FROM ('2023-01-01 00:00:00') TO ('2023-02-01 00:00:00'),
 lzlpartition1_202302 FOR VALUES FROM ('2023-02-01 00:00:00') TO ('2023-03-01 00:00:00')

lzldb=> \d+ lzlpartition1_202301
 Table "public.lzlpartition1_202301"
 Column | Type | Collation | Nullable | Default | Storage | Compression | Stats target | Description 
--------------+-----------------------------+-----------+----------+---------+----------+-------------+--------------+-------------
 id | integer | | not null | | plain | | | 
 name | character varying(50) | | | | extended | | | 
 date_created | timestamp without time zone | | not null | now() | plain | | | 
Partition of: lzlpartition1 FOR VALUES FROM ('2023-01-01 00:00:00') TO ('2023-02-01 00:00:00')
Partition constraint: ((date_created IS NOT NULL) AND (date_created >= '2023-01-01 00:00:00'::timestamp without time zone) AND (date_created < '2023-02-01 00:00:00'::timestamp without time zone))
Indexes:
 "lzlpartition1_202301_pkey" PRIMARY KEY, btree (id, date_created)
Access method: heap

分区上的主键、索引、字段null/CHECK约束自动创建。由于分区也是独立的表，约束和索引也可以单独在分区上创建。（attach则不会自动创建这些，详见attach一节）

list分区
#

list分区以指定的分区值将数据存放到对应的分区上

CREATE TABLE cities (
 city_id bigserial not null,
 name text,
 population bigint
) PARTITION BY LIST (left(lower(name), 1));

CREATE TABLE cities_ab
 PARTITION OF cities FOR VALUES IN ('a', 'b');
CREATE TABLE cities_null
 PARTITION OF cities (
 CONSTRAINT city_id_nonzero CHECK (city_id != 0)
) FOR VALUES IN (null);

insert into cities(name,population) values('Acity',10);
insert into cities(name,population) values(null,20);

=> SELECT tableoid::regclass,* FROM cities;
 tableoid | city_id | name | population 
-------------+---------+--------+------------
 cities_ab | 1 | Acity | 10
 cities_null | 2 | [null] | 20

list分区表可以创建null分区

hash分区
#

hash分区将数据散列存储在各个分区上，以打散热点数据

CREATE TABLE orders (order_id int,name varchar(10)) PARTITION BY HASH (order_id);
CREATE TABLE orders_p1 PARTITION OF orders
 FOR VALUES WITH (MODULUS 3, REMAINDER 0);
CREATE TABLE orders_p2 PARTITION OF orders
 FOR VALUES WITH (MODULUS 3, REMAINDER 1);
CREATE TABLE orders_p3 PARTITION OF orders
 FOR VALUES WITH (MODULUS 3, REMAINDER 2);

不能创建默认分区，也不能创建超过MODULUS的分区

=> CREATE TABLE orders_p2 PARTITION OF orders
-> FOR VALUES WITH (MODULUS 3, REMAINDER 4);
ERROR: 42P16: remainder for hash partition must be less than modulus
LOCATION: transformPartitionBound, parse_utilcmd.c:3939

=> CREATE TABLE orders_p4 PARTITION OF orders default;
ERROR: 42P16: a hash-partitioned table may not have a default partition
LOCATION: transformPartitionBound, parse_utilcmd.c:3909

插入数据

=>insert into orders values(generate_series(1,10000),'a');
INSERT 0 10000
=>SELECT tableoid::regclass,count(*) FROM orders group by tableoid::regclass;
 tableoid | count 
-----------+-------
 orders_p1 | 3277
 orders_p3 | 3354
 orders_p2 | 3369
 =>select tableoid::regclass,* from orders limit 30;
 tableoid | order_id | name 
-----------+----------+------
 orders_p1 | 2 | a
 orders_p1 | 4 | a
 orders_p1 | 6 | a
 orders_p1 | 8 | a
 orders_p1 | 15 | a
 orders_p1 | 16 | a
 orders_p1 | 18 | a
 orders_p1 | 19 | a
 orders_p1 | 20 | a

hash分区数据散列分布

--插入100条null数据
=> insert into orders values(null,generate_series(1,100)::text);
INSERT 0 100
=> SELECT tableoid::regclass,count(*) FROM orders where order_id is null group by tableoid::regclass;
 tableoid | count 
-----------+-------
 orders_p1 | 100
--null数据全部都放在了remainder 0的分区上
=>\d+ orders_p1
 Table "public.orders_p1"
 Column | Type | Collation | Nullable | Default | Storage | Stats target | Description 
----------+-----------------------+-----------+----------+---------+----------+--------------+-------------
 order_id | integer | | | | plain | | 
 name | character varying(10) | | | | extended | | 
Partition of: orders FOR VALUES WITH (modulus 3, remainder 0)
Partition constraint: satisfies_hash_partition('412053'::oid, 3, 0, order_id)

hash分区表虽然没有null分区的概念，但是可以存放null数据，null数据存放在remainder 0上。

混合分区
#

分区下面也可以建立分区构成级联模式，子分区可以有不同的分区方式，这样的分区成为混合分区。创建一个混合分区：

create table part_1000(id bigserial not null,name varchar(10),createddate timestamp) partition by range(createddate);
create table part_2001 partition of part_1000 for values from ('2023-01-01 00:00:00') to ('2023-02-01 00:00:00') partition by list(name) ;
create table part_2002 partition of part_1000 for values from ('2023-02-01 00:00:00') to ('2023-03-01 00:00:00') partition by list(name) ;
create table part_2003 partition of part_1000 for values from ('2023-03-01 00:00:00') to ('2023-04-01 00:00:00') partition by list(name) ;
create table part_3001 partition of part_2001 FOR VALUES IN ('abc');
create table part_3002 partition of part_2001 FOR VALUES IN ('def');
create table part_3003 partition of part_2001 FOR VALUES IN ('jkl');

\d+只能看到下一级的分区

 \d+ part_1000
 Partitioned table "dbmgr.part_1000"
 Column | Type | Collation | Nullable | Default | Storage | Stats target | Description 
-------------+-----------------------------+-----------+----------+---------------------------------------+----------+--------------+-------------
 id | bigint | | not null | nextval('part_1000_id_seq'::regclass) | plain | | 
 name | character varying(10) | | | | extended | | 
 createddate | timestamp without time zone | | | | plain | | 
Partition key: RANGE (createddate)
Partitions: part_2001 FOR VALUES FROM ('2023-01-01 00:00:00') TO ('2023-02-01 00:00:00'), PARTITIONED,
 part_2002 FOR VALUES FROM ('2023-02-01 00:00:00') TO ('2023-03-01 00:00:00'), PARTITIONED,
 part_2003 FOR VALUES FROM ('2023-03-01 00:00:00') TO ('2023-04-01 00:00:00'), PARTITIONED
=> \d+ part_2001
 Partitioned table "dbmgr.part_2001"
 Column | Type | Collation | Nullable | Default | Storage | Stats target | Description 
-------------+-----------------------------+-----------+----------+---------------------------------------+----------+--------------+-------------
 id | bigint | | not null | nextval('part_1000_id_seq'::regclass) | plain | | 
 name | character varying(10) | | | | extended | | 
 createddate | timestamp without time zone | | | | plain | | 
Partition of: part_1000 FOR VALUES FROM ('2023-01-01 00:00:00') TO ('2023-02-01 00:00:00')
Partition constraint: ((createddate IS NOT NULL) AND (createddate >= '2023-01-01 00:00:00'::timestamp without time zone) AND (createddate < '2023-02-01 00:00:00'::timestamp without time zone))
Partition key: LIST (name)
Partitions: part_3001 FOR VALUES IN ('abc'),
 part_3002 FOR VALUES IN ('def'),
 part_3003 FOR VALUES IN ('jkl') 

此时插入一条数据

=> insert into part_1000 values(random() * 10000,'abc','2023-01-01 08:00:00');
INSERT 0 1
=> SELECT tableoid::regclass,* FROM part_1000;
 tableoid | id | name | createddate 
-----------+------+------+---------------------
 part_3001 | 6385 | abc | 2023-01-01 08:00:00

数据存放在最底层的子分区中

声明分区特性小结
#

没有interval分区。没有自带的自动新增分区功能，对于维护来说比较麻烦
分区表的分区本身也是表，这个特性比较特殊。这不仅仅造成pg可以灵活的操作子分区，更重要的是功能和特性上的影响。
truncate，vacuum，analyze分区表会执行所有分区。truncate only不能在父表上执行，但可以在存数据的子表上执行，仅清除这个子分区。
range，hash分区的分区键可以有多个列，list分区的分区键只能是单个列或表达式。
分区父表本身是空的，最底层子分区可以存储数据
default分区表会接收不在声明的范围中的数据；如果没有default分区，插入范围外的数据会直接报错
如果要新增分区，需要注意default分区中是否有这个新增分区的数据
partition of创建的分区会自动创建分区表上的索引、约束、行级触发器
attach不会处理任何索引、约束等等对象

继承分区表
#

继承分区也是官方支持的，它利用了PGSQL的继承表特性来实现分区表的功能。继承分区表会比声明分区表更灵活。继承分区表的实现需要到了PGSQL中的2个功能：继承表和写入重定向。写入重定向可以通过rule或者trigger来实现。

创建继承分区表
#

创建继承分区表示例： 1.创建父表

CREATE TABLE measurement (
 city_id int not null,
 logdate date not null,
 peaktemp int,
 unitsales int
);

2.创建继承表，指定约束范围

CREATE TABLE measurement_202308 (
 CHECK ( logdate >= DATE '2023-08-01' AND logdate < DATE '2023-09-01' )
) INHERITS (measurement);
CREATE TABLE measurement_202309 (
 CHECK ( logdate >= DATE '2023-09-01' AND logdate < DATE '2023-10-01' )
) INHERITS (measurement);

3.创建规则或触发器，将插入数据重定向到对应的继承表中

CREATE OR REPLACE FUNCTION measurement_insert_trigger()
RETURNS TRIGGER AS $$
BEGIN
 IF ( NEW.logdate >= DATE '2023-08-01' AND
 NEW.logdate < DATE '2023-09-01' ) THEN
 INSERT INTO measurement_202308 VALUES (NEW.*);
 ELSIF ( NEW.logdate >= DATE '2023-09-01' AND
 NEW.logdate < DATE '2023-10-01' ) THEN
 INSERT INTO measurement_202309 VALUES (NEW.*);
 ELSE
 RAISE EXCEPTION 'Date out of range. Fix the measurement_insert_trigger() function!';
 END IF;
 RETURN NULL;
END;
$$
LANGUAGE plpgsql;

CREATE TRIGGER insert_measurement_trigger
 BEFORE INSERT ON measurement
 FOR EACH ROW EXECUTE FUNCTION measurement_insert_trigger();

一个最基本的继承分区表就创建好了。

=>\d+ measurement
 Table "public.measurement"
 Column | Type | Collation | Nullable | Default | Storage | Stats target | Description 
-----------+---------+-----------+----------+---------+---------+--------------+-------------
 city_id | integer | | not null | | plain | | 
 logdate | date | | not null | | plain | | 
 peaktemp | integer | | | | plain | | 
 unitsales | integer | | | | plain | | 
Triggers:
 insert_measurement_trigger BEFORE INSERT ON measurement FOR EACH ROW EXECUTE FUNCTION measurement_insert_trigger()
Child tables: measurement_202308,
 measurement_202309
Access method: heap

测试一下插入和查询数据

--插入范围外的数据会报错
=> insert into measurement values(1001, now() - interval '31' day ,1,1);
ERROR: P0001: Date out of range. Fix the measurement_insert_trigger() function!
CONTEXT: PL/pgSQL function measurement_insert_trigger() line 10 at RAISE
LOCATION: exec_stmt_raise, pl_exec.c:3889
--插入数据会重定向到子表上
=> insert into measurement values(1001,now(),1,1);
INSERT 0 0
--查询父表会查到子表数据
=> select tableoid::regclass,* from measurement;
 tableoid | city_id | logdate | peaktemp | unitsales 
--------------------+---------+------------+----------+-----------
 measurement_202308 | 1001 | 2023-08-03 | 1 | 1

RULE和trigger 除了触发器，PGSQL还可以用rule来重定向插入。 rule语句参考：

CREATE RULE measurement_insert_202308 AS
ON INSERT TO measurement WHERE
 ( logdate >= DATE '2023-08-01' AND logdate < DATE '2023-08-01' )
DO INSTEAD
 INSERT INTO measurement_202308 VALUES (NEW.*);
CREATE RULE measurement_insert_202309 AS
ON INSERT TO measurement WHERE
 ( logdate >= DATE '2023-09-01' AND logdate < DATE '2023-09-01' )
DO INSTEAD
 INSERT INTO measurement_202309 VALUES (NEW.*);

规则和触发器的差异：

rule性能相较trigger更差，但在批量插入时，由于rule只有一次检查，性能会比trigger更好，但其他情况下trigger更好
COPY不会触发rule，但会触发trigger。rule时可以将数据直接COPY到子表中
当插入范围外数据时，rule会将数据插入到父表中，trigger则会直接报错

索引为了提升性能，还需要创建索引和开启constrain_exclusion。分区的索引一般都是必不可少，继承表的索引需要手动在子表上创建。创建索引示例：

CREATE INDEX idx_measurement_202308_logdate ON measurement_202308 (logdate);
CREATE INDEX idx_measurement_202309_logdate ON measurement_202309 (logdate);

插入一些数据查看执行计划：

--'2023-08-04'只有1条数据，让其可以走到索引
=> insert into measurement values(1001,now()+interval '1' day,1,1);
INSERT 0 0
 insert into orders values(generate_series(1,10000),'a');
=> insert into measurement values(generate_series(1,1000),now(),1,1);
INSERT 0 0

=> explain select * from measurement where logdate='2023-08-04';
 QUERY PLAN 
------------------------------------------------------------------------------------------------------------------------------
 Append (cost=0.00..5.17 rows=2 width=16)
 -> Seq Scan on measurement measurement_1 (cost=0.00..0.00 rows=1 width=16)
 Filter: (logdate = '2023-08-04'::date)
 -> Index Scan using idx_measurement_202308_logdate on measurement_202308 measurement_2 (cost=0.14..5.16 rows=1 width=16)
 Index Cond: (logdate = '2023-08-04'::date)

上面的执行计划8月的分区走到了分区上的索引。constraint_exclusion默认打开了继承表的约束排除，上面的查询排除了9月分区，只扫描了8月。然而由于父表没有约束（也加不了）所以父表一定在执行计划里面，但是父表一般都是空的所以影响不大。

constraint_exclusion
#

constraint_exclusion拥有控制优化器是否使用约束来减少非必要的访问表，该参数在继承分区表优化上常见，通过减少子表的访问，提升SQL的性能（该功能跟enable_partition_pruning参数类似，enable_partition_pruning用于控制声明式分区表的分区裁剪）。constraint_exclusion有3个值： on：所有表都会检查约束 partition：继承表和UNION ALL子查询检查约束（默认值） off：不会检查约束约束排除只能发生在生成执行计划时，不会发生在真正执行时（分区裁剪是可以的）。这意味着当使用绑定变量、变量值时不会发生约束排除。例如在使用now()等优化器不知道具体值的函数时，优化器无法排除根本不需要访问的分区：

=> select now();
 now 
-------------------------------
 2023-08-03 17:12:04.772658+08
--优化器没有排除9月的分区
=> explain select * from measurement where logdate<=now();
 QUERY PLAN 
-----------------------------------------------------------------------------------------------------
 Append (cost=0.00..55.98 rows=1628 width=16)
 -> Seq Scan on measurement measurement_1 (cost=0.00..0.00 rows=1 width=16)
 Filter: (logdate <= now())
 -> Seq Scan on measurement_202308 measurement_2 (cost=0.00..21.15 rows=1010 width=16)
 Filter: (logdate <= now())
 -> Bitmap Heap Scan on measurement_202309 measurement_3 (cost=7.44..26.69 rows=617 width=16)
 Recheck Cond: (logdate <= now())
 -> Bitmap Index Scan on idx_measurement_202309_logdate (cost=0.00..7.28 rows=617 width=0)
 Index Cond: (logdate <= now())

另外，约束排除本身需要检查所有子表的约束，如果子表约束过多生成执行计划的效率会受到影响，所以继承分区不建议创建过多的子分区。

添加/删除继承分区表的分区
#

将一个继承分区做成普通表

ALTER TABLE measurement_202308 NO INHERIT measurement;

将一个含有数据的普通表当成子表加入到继承分区表中

CREATE TABLE measurement_202310 
(LIKE measurement INCLUDING DEFAULTS INCLUDING CONSTRAINTS);
ALTER TABLE measurement_202310 ADD CONSTRAINT measurement_202310_logdate_check 
CHECK ( logdate >= DATE '2023-10-01' AND logdate < DATE '2023-11-01' );
--insert into measurement_202310 values(2001,'20231010',3,3);
ALTER TABLE measurement_202310 INHERIT measurement;

继承分区表特性小结
#

继承分区要比声明分区更灵活，但一些声明分区的特性也无法使用
子表会继承父表上的约束，所以如果不是全局约束不要在父表上设置
索引不会继承，索引只能在子表上一个个地创建
声明分区只能有range、list、hash分区，继承分区可以更多，也可以是自定义的分区方式。
删除一个子表不会导致触发器失效。PGSQL没有像ORACLE那样失效对象的概念（索引有失效的概念）
一般来说使用trigger的插入重定向比rule效率更好
新增分区时，如果触发器函数中没有该分区的规则，则需要更新触发器函数。
继承分区可以多重继承
约束排除不能在执行时进行排除，所以建议使用固定值进行查询
使用继承分区表时，同样不要创建太多的子分区

pg_pathman
#

pg_pathman是三方插件实现的分区表功能。github上的pathman readme和使用pg_pathman插件的文章对pathman描述和使用已经非常详细，这里仅摘几个重点汇总和做一些简单的测试。

pg_pathman基本知识
#

不再更新

NOTE: this project is not under development anymore

pg_pathman支持postgres9.5到15，PostgreSQL后续版本不会再支持，已有版本也只做BUG修复，不会再新增功能。 pg_pathman的出现是因为老版本的PostgreSQL分区表功能不完善，而现在原生分区表（也就是声明分区表）已非常成熟，pg_pathman也建议使用原生分区表，存量的pg_pathman分区表也建议转移到原生分区表。曾经被许多用户认可的pg_pathman成为历史，即使不再更新，它的功能也比目前的原生分区表更多。 特性介绍 pg_pathman功能相当强大，一些原生分区表不支持的功能pathman也支持。 pathman虽然强大但也不是完美的，在实际使用过程中问题也很多。pg_pathman特性中比较需要关注的点包括：

pg_pathman可以通过分区管理函数管理分区。支持replace、merge、split分区操作；支持 attach、detach操作；支持interval分区
pg_pathman对分区表执行计划做了很多优化
pg_pathman仅支持range和hash两种分区类型
pathman_config表存储分区表配置信息；提供分区任务视图
分区信息缓存在内存中，以生成执行计划

pg_pathman基本使用
#

创建pathman range分区

--普通表就是父表
CREATE TABLE journal (
 id SERIAL,
 dt TIMESTAMP NOT NULL,
 level INTEGER,
 msg TEXT);

-- 子分区会自动创建父表上的索引
CREATE INDEX ON journal(dt);
--创建分区
select 
create_range_partitions('journal'::regclass, 
 'dt',
 '2023-01-01 00:00:00'::timestamp,
 interval '1 month', 
 6, 
 false) ; 

--查看表定义
=> \d+ journal
 Table "public.journal"
 Column | Type | Collation | Nullable | Default | Storage | Stats target | Description 
--------+-----------------------------+-----------+----------+-------------------------------------+----------+--------------+-------------
 id | integer | | not null | nextval('journal_id_seq'::regclass) | plain | | 
 dt | timestamp without time zone | | not null | | plain | | 
 level | integer | | | | plain | | 
 msg | text | | | | extended | | 
Indexes:
 "journal_dt_idx" btree (dt)
Child tables: journal_1,
 journal_2,
 journal_3,
 journal_4,
 journal_5,
 journal_6
Access method: heap

=> \d+ journal_6
 Table "public.journal_6"
 Column | Type | Collation | Nullable | Default | Storage | Stats target | Description 
--------+-----------------------------+-----------+----------+-------------------------------------+----------+--------------+-------------
 id | integer | | not null | nextval('journal_id_seq'::regclass) | plain | | 
 dt | timestamp without time zone | | not null | | plain | | 
 level | integer | | | | plain | | 
 msg | text | | | | extended | | 
Indexes:
 "journal_6_dt_idx" btree (dt)
Check constraints:
 "pathman_journal_6_check" CHECK (dt >= '2023-06-01 00:00:00'::timestamp without time zone AND dt < '2023-07-01 00:00:00'::timestamp without time zone)
Inherits: journal
Access method: heap

--插入数据
INSERT INTO journal (dt, level, msg)
SELECT g, random() * 10000, md5(g::text)
FROM generate_series('2023-01-01'::date, '2023-02-28'::date, '1 hour') as g;

--插入还未创建对应分区的数据
=> INSERT INTO journal (dt, level, msg) values('2023-07-01'::date,'11','1');
INSERT 0 1
--查看分区数据分布，已成功创建interval分区
=> SELECT tableoid::regclass AS partition, count(*) FROM journal group by partition;
 partition | count 
-----------+-------
 journal_7 | 1
 journal_2 | 649
 journal_1 | 744

--查看执行计划
--已发生分区裁剪
=> explain select * from journal where dt='2023-01-01 22:00:00';
 QUERY PLAN 
-----------------------------------------------------------------------------------------------------
 Append (cost=0.00..5.30 rows=2 width=48)
 -> Seq Scan on journal journal_1 (cost=0.00..0.00 rows=1 width=48)
 Filter: (dt = '2023-01-01 22:00:00'::timestamp without time zone)
 -> Index Scan using journal_1_dt_idx on journal_1 journal_1_1 (cost=0.28..5.29 rows=1 width=49)
 Index Cond: (dt = '2023-01-01 22:00:00'::timestamp without time zone)

创建pathman hash分区

--创建主表
CREATE TABLE items (
 id SERIAL PRIMARY KEY,
 name TEXT,
 code BIGINT);
--创建hash分区
select create_hash_partitions('items'::regclass, 
 'id',
 3, 
 false) ; 
--插入数据 
INSERT INTO items (id, name, code)
SELECT g, md5(g::text), random() * 100000
FROM generate_series(1, 1000) as g;

=> SELECT tableoid::regclass AS partition, count(*) FROM items group by partition;
 partition | count 
-----------+-------
 items_2 | 344
 items_0 | 318
 items_1 | 338
=> \d+ items
 Table "public.items"
 Column | Type | Collation | Nullable | Default | Storage | Stats target | Description 
--------+---------+-----------+----------+-----------------------------------+----------+--------------+-------------
 id | integer | | not null | nextval('items_id_seq'::regclass) | plain | | 
 name | text | | | | extended | | 
 code | bigint | | | | plain | | 
Indexes:
 "items_pkey" PRIMARY KEY, btree (id)
Child tables: items_0,
 items_1,
 items_2
Access method: heap

=> \d+ items_1
 Table "public.items_1"
 Column | Type | Collation | Nullable | Default | Storage | Stats target | Description 
--------+---------+-----------+----------+-----------------------------------+----------+--------------+-------------
 id | integer | | not null | nextval('items_id_seq'::regclass) | plain | | 
 name | text | | | | extended | | 
 code | bigint | | | | plain | | 
Indexes:
 "items_1_pkey" PRIMARY KEY, btree (id)
Check constraints:
 "pathman_items_1_check" CHECK (get_hash_part_idx(hashint4(id), 3) = 1)
Inherits: items
Access method: heap
=> SELECT tableoid::regclass AS partition, count(*) FROM items group by partition;
 partition | count 
-----------+-------
 items_2 | 344
 items_0 | 318
 items_1 | 338

pg分区表的优劣
#

分区表的优势
#

SQL性能提升。在某些场景下，比如把大量的数据分成多个分区，而SQL只需要查那一个分区的数据时，SQL性能可能会极大的提升
分区可以和索引配合使用。比如访问一个分区上的一个索引要比访问一个未分区的大索引要更高效。
删除一个分区比删除多行数据更高效。这在时间范围分区中很常见，删除一个用不到的历史分区是非常快的，但是如果没有分区，delete删除数据不仅慢还需要额外的维护操作
vacuum更快。一个大表在回收旧版本信息或收集统计信息时会非常慢，在vacuum还没执行完的时候可能SQL已经存在问题了。如果有分区的话，vacuum会快很多。
IO分散能力。不同的分区可以放在不同的路径、不同的磁盘上。极少使用数据可以放在便宜的磁盘上。
更多的维护技巧。直接维护一个大表是非常困难的，比如一个极大的表做vacuum时就有很多问题，而分区表的各个分区可以单独运行vacuum。不仅如此，attach/detach、本地索引/约束等可以在很多场景中灵活使用。

分区表的劣势
#

在pgsql中，每个分区表的分区都可以当成普通表来对待。分区表过多会导致SQL解析时间较长和更多的内存负载，甚至报错。参考之前的文章较少的分区也报错too many range table entries
即使分区过多没有报错，且在生成执行计划的时候没有做分区剪裁（执行的时候有可能做），那么explain出来的执行计划会非常多，此时日志中也会打印长长的执行计划影响日志阅读。
一些奇怪的问题：不同用户查看到不同的执行计划

分区表的限制
#

没有原生的自动创建分区功能
只支持分区索引，不支持全局索引
主键必须包含分区键。postgresql目前只能在各自的分区内判断唯一性，所以有这个限制。oracle和mysql都没有这种限制。
唯一索引必须包含分区键。postgresql目前只能在各自的分区内判断唯一性。同理主键
无法创建定义在全局的约束
INSERT的BEFORE ROW触发器不能更新insert的那个分区
临时表分区和普通表分区不能在同一分区表下。
声明式分区的父表子表的列必须一致；继承式分区的子表可以比父表的列更多。
声明式分区CHECK和NOT NULL约束总是继承的，不能单独设置分区的这两种约束
range 不能存储NULL值；hash分区没有null分区的概念，但可以存储null值，null值存放在remainder 0分区上；list分区可以显示创建null分区存放null数据

什么时候该使用分区表？
#

首先使用分区表必须要了解分区表所带来的优劣势和使用限制，比如数据量很大的时候分区可以带来性能提升，冷热数据分离也更好管理分区数据等等。应该结合本身业务情况、硬件资源选择是否分区和如何分区。但是总会有开发人员会问到底多少数据量该分区等等的问题，使用分区表的建议只能给出一个笼统的回答，如果你不知道怎么分区，可以参考以下建议（如果足够了解表分区，请忽略）：

表数据够大，而表上的sql总是或可以是带有分区键字段的时候
冷热数据分离明显。比如新数据都在新的当月分区插入，老的11个月分区都是只读数据的情况
vaccum已经跑不过来了

分区表的权限
#

权限问题是分区表知识点中讨论的比较少的，但是它仍然值得关注。由于PostgreSQL数据库有“分区子表也是普通表”这样的概念，这与其他几个常见的数据库（Oracle、mysql）是不同的。比如在oracle中不需要关心分区子表的权限，但是在pg中却需要关注权限问题。

partition of/attach不会将主表的权限继承给子表

--把分区去表的select授权给一个普通用户
=> grant select on lzlpartition1 to userlzl;
GRANT

--查看权限，只有主表有授权，存量分区子表不会自动授权
=> select grantee,table_schema,table_name,privilege_type from information_schema.table_privileges where grantee='userlzl';
 grantee | table_schema | table_name | privilege_type 
---------+--------------+---------------+----------------
 userlzl | public | lzlpartition1 | SELECT
 
 --partition of方式创建一个分区
 => create table LZLPARTITION1_202303 partition of LZLPARTITION1 for values from ('2023-03-01 00:00:00') to ('2023-04-01 00:00:00');
CREATE TABLE

--attach方式创建一个分区
=> CREATE TABLE lzlpartition1_202304
-> (LIKE lzlpartition1 INCLUDING DEFAULTS INCLUDING CONSTRAINTS);
CREATE TABLE
=> alter table lzlpartition1 attach partition lzlpartition1_202304 for values from ('2023-04-01 00:00:00') to ('2023-05-01 00:00:00');
ALTER TABLE

--再次查看权限，新增的子分区不会自动授权给其他用户（但是新增子分区权限会自动授权给owner）
=> select grantee,table_schema,table_name,privilege_type from information_schema.table_privileges where grantee='userlzl';
 grantee | table_schema | table_name | privilege_type 
---------+--------------+---------------+----------------
 userlzl | public | lzlpartition1 | SELECT

目前来看userlzl 这个用户对所有子表都没有访问权限，但是有主表的权限此时userlzl可以通过主表访问分区数据，但不能通过直接访问子表访问数据

=> \c - userlzl;
You are now connected to database "dbmgr" as user "userlzl".
=> select * from LZLPARTITION1 where date_created='2023-01-02 10:00:00';
 id | name | date_created 
------+----------------------------------+---------------------
 2159 | d05d716da126ff4b44d934344cc4dd7a | 2023-01-02 10:00:00

=> select * from LZLPARTITION1_202301 where date_created='2023-01-02 10:00:00';
ERROR: 42501: permission denied for table lzlpartition1_202301
LOCATION: aclcheck_error, aclchk.c:3466

因为attach/detach不会处理权限，此时如果我们把分区detach出来，这个分区同样不能被userlzl访问

=> alter table lzlpartition1 detach partition lzlpartition1_202303;
ALTER TABLE
=> \dp+ lzlpartition1_202303;
 Access privileges
 Schema | Name | Type | Access privileges | Column privileges | Policies 
--------+----------------------+-------+-------------------+-------------------+----------
 dbmgr | lzlpartition1_202303 | table | | | 
=> select * from LZLPARTITION1_202301 where date_created='2023-01-02 10:00:00';
ERROR: 42501: permission denied for table lzlpartition1_202301 

由此可知

分区子表和主表PostgreSQL在数据库中都是以普通表的形式存在，他们都有各自的权限体系
如果没有子表权限而主表有权限同样可以访问子表数据
partition of、attach/detach都不会处理权限问题

但是，分区表权限并不是仅仅控制是否能够访问，没有分区子表权限可能导致执行计划异常，参考文章：不同用户查看到不同的执行计划这个问题是一个偶发现象，导致超级用户和一般用户看到的sql执行计划不一致，实际上业务SQL执行计划异常却看不出来，比较难定位。分区子表有各自的统计信息，子表权限与父表不一致（即便是partition of创建的分区），导致用户可以通过主表访问子表的数据，却不能查看子表的统计信息。权限问题导致了执行计划产生差异。这与“权限只控制是否能访问表，不控制如何访问表”的一般概念是违背的，所以需要注意这个权限问题。为了提供子表统计信息权限，建议显示对用户授权所有子表查询权限，就可以避免以上问题

grant select on table_partition_allname to username;

分区表的维护
#

分区表ATTACH/DETACH基本操作
#

attach/detach可以将一个已存在的表作为分区添加/分离分区表。attach/detach在维护工作中很有用。先来看看"create table…partition of"方式添加分区和"drop table"删除分区的锁情况

锁矩阵：https://www.postgresql.org/docs/current/explicit-locking.html

申请的锁：https://postgres-locks.husseinnasser.com

partition of新增分区

--session1 开启一个事务，只读数据
=> select * from lzlpartition1 where date_created='2023-01-01 00:00:00';
 id | name | date_created 
------+----------------------------------+---------------------
 8249 | 256ac66bb53d31bc6124294238d6410c | 2023-01-01 00:00:00

--session3 查看锁情况。读取一个分区数据时，要在子分区和主表上同时获得锁
=> select l.locktype,d.datname,r.relname,l.virtualxid,l.transactionid,l.pid,l.mode,l.granted from pg_locks l left join pg_database d on l.database=d.oid left join pg_class r on l.relation=r.oid 
where relname like '%lzlpartition1%';
 locktype | datname | relname | virtualxid | transactionid | pid | mode | granted 
----------+---------+----------------------+------------+---------------+--------+-----------------+---------
 relation | dbmgr | lzlpartition1_202301 | [null] | [null] | 311449 | AccessShareLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 311449 | AccessShareLock | t

--session2 partition of方式添加分区
=> create table LZLPARTITION1_202305 partition of LZLPARTITION1 for values from ('2023-05-01 00:00:00') to ('2023-06-01 00:00:00');
--等待

--session3 再次查看锁
=> select l.locktype,d.datname,r.relname,l.virtualxid,l.transactionid,l.pid,l.mode,l.granted from pg_locks l left join pg_database d on l.database=d.oid left join pg_class r on l.relation=r.oid 
where relname like '%lzlpartition1%';
 locktype | datname | relname | virtualxid | transactionid | pid | mode | granted 
----------+---------+----------------------+------------+---------------+--------+---------------------+---------
 relation | dbmgr | lzlpartition1_202301 | [null] | [null] | 311449 | AccessShareLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 311449 | AccessShareLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 308525 | AccessExclusiveLock | f --此为partition of会话

--session4 再随便来一个查询
=> select * from lzlpartition1 where date_created='2023-01-01 00:00:00';
--等待

--session4再次查看锁
=> select l.locktype,d.datname,r.relname,l.virtualxid,l.transactionid,l.pid,l.mode,l.granted from pg_locks l left join pg_database d on l.database=d.oid left join pg_class r on l.relation=r.oid 
where relname like '%lzlpartition1%';
 locktype | datname | relname | virtualxid | transactionid | pid | mode | granted 
----------+---------+----------------------+------------+---------------+--------+---------------------+---------
 relation | dbmgr | lzlpartition1_202301 | [null] | [null] | 311449 | AccessShareLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 311449 | AccessShareLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 308525 | AccessExclusiveLock | f
 relation | dbmgr | lzlpartition1 | [null] | [null] | 84774 | AccessShareLock | f --查询阻塞

partition of方式新增分区时，会申请主表的 AccessExclusiveLock，等待主表一切事务的同时也会阻塞主表的一切事务。

虽然partition of语句本身执行很快，但是如果遇到主表上有长事务，那么分区表上的所有操作都会长时间停滞。如果没有停机窗口，直接使用partition of方式新增分区是不推荐的。

drop table删除分区

--session1 再次开启只读事务
--session2 删除分区表的子分区
=> drop table lzlpartition1_202305;
--等待

--session3 查看锁情况
=> 
select l.locktype,d.datname,r.relname,l.virtualxid,l.transactionid,l.pid,l.mode,l.granted from pg_locks l left join pg_database d on l.database=d.oid left join pg_class r on l.relation=r.oid 
where relname like '%lzlpartition1%';
 locktype | datname | relname | virtualxid | transactionid | pid | mode | granted 
----------+---------+----------------------+------------+---------------+--------+---------------------+---------
 relation | dbmgr | lzlpartition1_202301 | [null] | [null] | 311449 | AccessShareLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 311449 | AccessShareLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 308525 | AccessExclusiveLock | f

drop table删除子分区时，会申请主表上的AccessExclusiveLock，等待一切和阻塞一切。同样的在生产环境需要谨慎使用。

attach添加分区 attach将一个已存在的普通表附加到分区表上虽然attach跟partition of都可以添加分区，但是需要注意ATTACH不会自动创建索引、约束、默认值、行级触发器，这点跟partition of是不同的。先创建一个表

--减少繁琐的ddl，like方式创建表
CREATE TABLE lzlpartition1_202305
 (LIKE lzlpartition1 INCLUDING DEFAULTS INCLUDING CONSTRAINTS);

再观察attach的是否被阻塞

--session1 开启读写事务
=>begin;
BEGIN
=> insert into lzlpartition1 values('1234','abcd','2023-01-01 01:00:00');
INSERT 0 1
--session3 查看锁情况
=> 
select l.locktype,d.datname,r.relname,l.virtualxid,l.transactionid,l.pid,l.mode,l.granted from pg_locks l left join pg_database d on l.database=d.oid left join pg_class r on l.relation=r.oid 
where relname like '%lzlpartition1%';
 locktype | datname | relname | virtualxid | transactionid | pid | mode | granted 
----------+---------+----------------------+------------+---------------+--------+------------------+---------
 relation | dbmgr | lzlpartition1_202301 | [null] | [null] | 311449 | RowExclusiveLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 311449 | AccessShareLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 311449 | RowExclusiveLock | t
--dml语句会获得分区主表和对应分区子表的RowExclusiveLock

--session2 attach新建的表到分区主表上
=> alter table lzlpartition1 attach partition lzlpartition1_202305 for values from ('2023-05-01 00:00:00') to ('2023-06-01 00:00:00');
ALTER TABLE

attach只会申请SHARE UPDATE EXCLUSIVE锁，比ACCESS EXCLUSIVE低很多。

attach与读写都互不阻塞，所以推荐以attach方式添加分区，不影响业务，可在线执行。

detach删除分区

detach将一个分区脱离分区表，成为一个普通表

--session1 保持dml事务不提交
--session2 detach一个分区
 alter table lzlpartition1 detach partition lzlpartition1_202305;
 --等待

--session3 查看锁情况
 => select l.locktype,d.datname,r.relname,l.virtualxid,l.transactionid,l.pid,l.mode,l.granted from pg_locks l left join pg_database d on l.database=d.oid left join pg_class r on l.relation=r.oid 
where relname like '%lzlpartition1%';
 locktype | datname | relname | virtualxid | transactionid | pid | mode | granted 
----------+---------+----------------------+------------+---------------+--------+---------------------+---------
 relation | dbmgr | lzlpartition1_202301 | [null] | [null] | 311449 | RowExclusiveLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 311449 | RowExclusiveLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 308525 | AccessShareLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 308525 | AccessExclusiveLock | f

detach跟attach不同，detach申请了主表的AccessExclusiveLock，等待一切和阻塞一切。

detach concurrently

PostgreSQL 14开始，detach新增了两种语法CONCURRENTLY 和FINALIZE

ALTER TABLE [ IF EXISTS ] name DETACH PARTITION partition_name [ CONCURRENTLY | FINALIZE ]

detach concurrently内部会开启两次事务，第一次事务会在主表和子表上都申请SHARE UPDATE EXCLUSIVE锁，分区会标记为正在detach的状态，此时会等待分区表上的所有事务提交。一旦这些事务全部都提交了，第二次事务会申请主表上的 SHARE UPDATE EXCLUSIVE锁和那个子表上ACCESS EXCLUSIVE锁，随后detach concurrently完成。

另外，detach concurrently后的子分区，会保留约束，由分区约束转化为check约束保留在detach后的表上

DETACH CONCURRENTLY的限制：

DETACH CONCURRENTLY不能放在事务块中
分区表不能有default分区

concurrently的阻塞情况：

--session1
lzldb=> begin;
BEGIN
lzldb=*> insert into lzlpartition1 values('1234','abcd','2023-01-01 01:00:00');
INSERT 0 1

--session2 detach concurrently
lzldb=> alter table lzlpartition1 detach partition lzlpartition1_202301 concurrently;
--等待

--session3 查看锁
 3691 | insert into lzlpartition1 values('1234','abcd','2023-01-01 01:00:00'); | Client | ClientRead
 3940 | alter table lzlpartition1 detach partition lzlpartition1_202301 concurrently; | Lock | virtualxid
 3947 | select pid,query,wait_event_type,wait_event from pg_stat_activity; | | 
--detach会话是3940，非常奇怪，detach的等待事件是virtualxid，等待事件类型是Lock

--查看锁的情况
lzldb=> select locktype,database,relation,virtualtransaction,pid,mode,granted from pg_locks where pid in (3691,3940);
 locktype | database | relation | virtualtransaction | pid | mode | granted 
---------------+----------+----------+--------------------+------+------------------+---------
 virtualxid | | | 6/9 | 3940 | ExclusiveLock | t
 relation | 16387 | 40969 | 5/179 | 3691 | RowExclusiveLock | t
 relation | 16387 | 40963 | 5/179 | 3691 | RowExclusiveLock | t
 virtualxid | | | 5/179 | 3691 | ExclusiveLock | t
 virtualxid | | | 6/9 | 3940 | ShareLock | f
 transactionid | | | 5/179 | 3691 | ExclusiveLock | t
--此时的detach还没有等待表上的锁，而是在等待virtualxid的ShareLock

--session4 做个插入
lzldb=> insert into lzlpartition1 values('12345','abcd','2023-01-01 01:00:00');
ERROR: no partition of relation "lzlpartition1" found for row
DETAIL: Partition key of the failing row contains (date_created) = (2023-01-01 01:00:00).
lzldb=> insert into lzlpartition1 values('12345','abcd','2023-02-01 01:00:00');
INSERT 0 1
--此时detach的分区已经不能插入，其他分区可以插入
--如果通过分区插入会怎样呢？可以正常插入
lzldb=> insert into lzlpartition1_202301 values('12345','abcd','2023-01-01 01:00:00');
INSERT 0 1
--注意此时它还是个分区表的分区，还不是一个普通表，不过它已经被标记为不可用了

--\d+查看分区处于DETACH PENDING状态
Partitions: lzlpartition1_202301 FOR VALUES FROM ('2023-01-01 00:00:00') TO ('2023-02-01 00:00:00') (DETACH PENDING),
 lzlpartition1_202302 FOR VALUES FROM ('2023-02-01 00:00:00') TO ('2023-03-01 00:00:00')
 

--把insert的session1提交/回滚
lzldb=> rollback;
ROLLBACK

--session2立即完成
lzldb=> alter table lzlpartition1 detach partition lzlpartition1_202301 concurrently;
ALTER TABLE

FINALIZE：

--session1
lzldb=> begin;
BEGIN
lzldb=*> insert into lzlpartition1 values('1234','abcd','2023-01-01 01:00:00');
INSERT 0 1

--session2 detach concurrently，手动cancel
lzldb=> alter table lzlpartition1 detach partition lzlpartition1_202301 concurrently;
^CCancel request sent
ERROR: canceling statement due to user request

--\d+查看分区表，分区处于DETACH PENDING状态
Partitions: lzlpartition1_202301 FOR VALUES FROM ('2023-01-01 00:00:00') TO ('2023-02-01 00:00:00') (DETACH PENDING),
 lzlpartition1_202302 FOR VALUES FROM ('2023-02-01 00:00:00') TO ('2023-03-01 00:00:00')

--DETACH PENDING的分区，SQL已经不会去访问了
lzldb=> explain select * from lzlpartition1;
 QUERY PLAN 
-----------------------------------------------------------------------------------------
 Seq Scan on lzlpartition1_202302 lzlpartition1 (cost=0.00..752.81 rows=38881 width=45)

--finalize使之完成
lzldb=> alter table lzlpartition1 detach partition lzlpartition1_202301 finalize; 
--等待

--查看锁情况
lzldb=> select l.locktype,d.datname,r.relname,l.virtualxid,l.transactionid,l.pid,l.mode,l.granted from pg_locks l left join pg_database d on l.database=d.oid left join pg_class r on l.relation=r.oid 
where relname like '%lzlpartition1%';lzldb-# 
 locktype | datname | relname | virtualxid | transactionid | pid | mode | granted 
----------+---------+----------------------+------------+---------------+------+--------------------------+---------
 relation | lzldb | lzlpartition1 | | | 3691 | RowExclusiveLock | t
 relation | lzldb | lzlpartition1_202301 | | | 3940 | AccessExclusiveLock | f
 relation | lzldb | lzlpartition1 | | | 3940 | ShareUpdateExclusiveLock | t
 relation | lzldb | lzlpartition1_202301 | | | 3691 | RowExclusiveLock | t
--3940，finalize申请了分区主表的ShareUpdateExclusiveLock和子表的AccessExclusiveLock
--由于是插入的是数据的分区刚好是detach的分区，所以发生等待

--session1结束
lzldb=!> rollback;
ROLLBACK
--session2立即完成
lzldb=> alter table lzlpartition1 detach partition lzlpartition1_202301 finalize; 
ALTER TABLE
 

虽然detach的分区会申请8级锁，但是一般业务也没有直接通过子分区写数据的，所以只需要关注分区表的长事务尽快完成就行，一般不需要担心造成该分区子表上的后续阻塞。

在线detach小结：

detach concurrently的阻塞情况跟CIC有点类似，不会阻塞其他事务，但是其本身会等待已有的事务完成，这点在lock上不太容易看出来
在detach concurrently期间分区会处于DETACH PENDING中间状态，该状态有点类似invisible，sql不会找到这个分区
如果是长事务导致的DETACH PENDING，应及时结束长事务；如果是中断导致的DETACH PENDING，可以使用FINALIZE使其完成detach。

利用约束减少attach时间
#

分区数据情况，准备操作一个较大分区的attach操作

=> SELECT tableoid::regclass AS partition, count(*) FROM lzlpartition1 group by partition;
 partition | count 
----------------------+---------
 lzlpartition1_202301 | 2592001
 lzlpartition1_202302 | 38881

注意这个202301的分区有一个partition constraint

=> \d+ lzlpartition1_202301
 Table "public.lzlpartition1_202301"
 Column | Type | Collation | Nullable | Default | Storage | Stats target | Description 
--------------+-----------------------------+-----------+----------+---------+----------+--------------+-------------
id | integer | | not null | | plain | | 
name | character varying(50) | | | | extended | | 
date_created | timestamp without time zone | | not null | now() | plain | | 
Partition of: lzlpartition1 FOR VALUES FROM ('2023-01-01 00:00:00') TO ('2023-02-01 00:00:00')
Partition constraint: ((date_created IS NOT NULL) AND (date_created >= '2023-01-01 00:00:00'::timestamp without time zone) AND (date_created < '2023-02-01 00:00:00'::timestamp without t
Indexes:
 "lzlpartition1_202301_pkey" PRIMARY KEY, btree (id, date_created)
Access method: heap

detach分区

 alter table lzlpartition1 detach partition lzlpartition1_202301;

--detach后，partition constraint就没有了
=> \d+ lzlpartition1_202301
 Table "public.lzlpartition1_202301"
 Column | Type | Collation | Nullable | Default | Storage | Stats target | Description 
--------------+-----------------------------+-----------+----------+---------+----------+--------------+-------------
id | integer | | not null | | plain | | 
name | character varying(50) | | | | extended | | 
date_created | timestamp without time zone | | not null | now() | plain | | 
Indexes:
 "lzlpartition1_202301_pkey" PRIMARY KEY, btree (id, date_created)
Access method: heap

不添加check约束，attach

=> alter table lzlpartition1 attach partition lzlpartition1_202301 for values from ('2023-01-01 00:00:00') to ('2023-02-01 00:00:00');
ALTER TABLE
Time: 343.498 ms

由于要扫描分区数据是否满足分区范围，attach耗时300+ms

添加check约束，attach

=> alter table lzlpartition1 detach partition lzlpartition1_202301;
=> alter table lzlpartition1_202301 add constraint chk_202301 CHECK
-> ((date_created IS NOT NULL) AND (date_created >= '2023-01-01 00:00:00'::timestamp without time zone) AND (date_created < '2023-02-01 00:00:00'::timestamp without time zone));
ALTER TABLE
Time: 355.458 ms

上面添加check约束的耗时跟没有check时的attach操作耗时差不多，因为添加check约束同样也要扫描检查所有数据。 check约束添加完后再attach，此时的attach操作非常快就能完成

=> alter table lzlpartition1 attach partition lzlpartition1_202301 for values from ('2023-01-01 00:00:00') to ('2023-02-01 00:00:00');
ALTER TABLE
Time: 1.480 ms

删除check约束

=> \d+ lzlpartition1_202301;
 Table "public.lzlpartition1_202301"
 Column | Type | Collation | Nullable | Default | Storage | Stats target | Description 
--------------+-----------------------------+-----------+----------+---------+----------+--------------+-------------
 id | integer | | not null | | plain | | 
 name | character varying(50) | | | | extended | | 
 date_created | timestamp without time zone | | not null | now() | plain | | 
Partition of: lzlpartition1 FOR VALUES FROM ('2023-01-01 00:00:00') TO ('2023-02-01 00:00:00')
Partition constraint: ((date_created IS NOT NULL) AND (date_created >= '2023-01-01 00:00:00'::timestamp without time zone) AND (date_created < '2023-02-01 00:00:00'::timestamp without t
Indexes:
 "lzlpartition1_202301_pkey" PRIMARY KEY, btree (id, date_created)
Check constraints:
 "chk_202301" CHECK (date_created IS NOT NULL AND date_created >= '2023-01-01 00:00:00'::timestamp without time zone AND date_created < '2023-02-01 00:00:00'::timestamp without time 
Access method: heap

注意，check constraint和partition constraint是不一样的概念，虽然他俩的约束内容可以是一致的。attach使用了check约束但是不会进行合并，可以显式删除这个多余的check。

=> alter table lzlpartition1_202301 drop constraint chk_202301;
ALTER TABLE

另外，需要关注drop constraint申请了当前子分区上AccessExclusiveLock，这是最高级别的锁，会阻塞任何操作。所以当前子分区上有事务，谨慎执行drop constraint。

=> select l.locktype,d.datname,r.relname,l.virtualxid,l.transactionid,l.pid,l.mode,l.granted from pg_locks l left join pg_database d on l.database=d.oid left join pg_class r on l.relation=r.oid 
where relname like '%lzlpartition1%';
 locktype | datname | relname | virtualxid | transactionid | pid | mode | granted 
----------+---------+----------------------+------------+---------------+--------+---------------------+---------
 relation | dbmgr | lzlpartition1 | [null] | [null] | 448243 | AccessShareLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 448243 | RowExclusiveLock | t
 relation | dbmgr | lzlpartition1_202301 | [null] | [null] | 444399 | AccessShareLock | t
 relation | dbmgr | lzlpartition1_202301 | [null] | [null] | 444399 | AccessExclusiveLock | f --这个就是drop constraint会话
 relation | dbmgr | lzlpartition1_202301 | [null] | [null] | 448243 | RowExclusiveLock | t

so， 在attach分区时，先添加check约束是比较有用，它可以减少attach的执行时间，数据检查在attach前完成就可以了

分区表新增分区的正确姿势
#

我们现在知道，attach可以在线执行，而partition of/drop table/detach都会申请等待和阻塞一切的AccessExclusiveLock so， 建议用attach新建分区。partition of/detach都会等待和阻塞一切事务，而attach不会被只读/DML事务阻塞 所以添加分区应该使用attach，并提前创建check约束，删除约束时需要关注长事务问题。 分区表添加分区的正确姿势：

--减少繁琐的ddl，like方式创建表
CREATE TABLE lzlpartition1_202303
 (LIKE lzlpartition1 INCLUDING DEFAULTS INCLUDING CONSTRAINTS);
--参考其他分区的Partition constraint，添加表的check约束，减少attach检查约束的时间
alter table lzlpartition1_202303 add constraint chk_202303 CHECK ((date_created IS NOT NULL) AND (date_created >= '2023-03-01 00:00:00'::timestamp without time zone) AND (date_created < '2023-04-01 00:00:00'::timestamp without time zone));
--attach方式添加分区
alter table LZLPARTITION1 attach partition LZLPARTITION1_202303 for values from ('2023-03-01 00:00:00') to ('2023-04-01 00:00:00');
--可选。在新分区有事务之前，删除多余的check约束
alter table lzlpartition1_202303 drop constraint chk_202303;

分区索引的锁
#

只读事务时创建/删除分区索引

当分区上有共享锁时AccessShareLock，也就是分区表上有查询事务的情况下 CREATE INDEX ON lzlpartition1创建成功（注意没有加concurrently）；DROP INDEX lzlpartition1失败

--session1 开启事务，读取分区表数据
=> begin;
BEGIN
=> select count(*) from lzlpartition1 where date_created>='2023-01-01 00:00:00' and date_created<='2023-01-02 00:00:00';
 count 
-------
 86401
(1 row)
--session2 创建索引，成功
=> create index idx_datecreated on lzlpartition1(date_created);;
CREATE INDEX

--session2 删除索引，等待
=> drop index idx_datecreated;

--session3 查看锁
=> select l.locktype,d.datname,r.relname,l.virtualxid,l.transactionid,l.pid,l.mode,l.granted from pg_locks l left join pg_database d on l.database=d.oid left join pg_class r on l.relation=r.oid 
where relname like '%lzlpartition1%';
 locktype | datname | relname | virtualxid | transactionid | pid | mode | granted 
----------+---------+---------------------------+------------+---------------+--------+---------------------+---------
 relation | dbmgr | lzlpartition1_202301_pkey | [null] | [null] | 300371 | AccessShareLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 99598 | AccessExclusiveLock | f
 relation | dbmgr | lzlpartition1_202301 | [null] | [null] | 300371 | AccessShareLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 300371 | AccessShareLock | t

create index没有申请表上的AccessExclusiveLock，但是drop index申请了表上的AccessExclusiveLock。从这个的例子可以得出： 只读事务不会阻塞创建索引，但会阻塞删除索引

更新事务时创建/删除分区索引

--session1 开启更新事务
=> begin;
BEGIN
=> update lzlpartition1 set name='abc' where date_created='2023-01-01 10:00:00';
UPDATE 1
--session2 创建分区索引，等待
=> create index idx_datecreated on lzlpartition1(date_created);

--session3 查看锁情况
=>select l.locktype,d.datname,r.relname,l.virtualxid,l.transactionid,l.pid,l.mode,l.granted from pg_locks l left join pg_database d on l.database=d.oid left join pg_class r on l.relation=r.oid 
-> where relname like '%lzlpartition1%';
 locktype | datname | relname | virtualxid | transactionid | pid | mode | granted 
----------+---------+---------------------------+------------+---------------+--------+------------------+---------
 relation | dbmgr | lzlpartition1_202301_pkey | [null] | [null] | 300371 | RowExclusiveLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 99598 | ShareLock | f
 relation | dbmgr | lzlpartition1_202301 | [null] | [null] | 300371 | RowExclusiveLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 300371 | AccessShareLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 300371 | RowExclusiveLock | t

create index会话（99598）申请分区主表的ShareLock锁，DML事务会话（300371 ）持有该子分区和主表的RowExclusiveLock

create index（无concurrently）会话申请主表ShareLock；只读事务会话申请主表和子表的AccessShareLock；更新事务会话申请主表和子表的RowExclusiveLock； ==> AccessShareLock不阻塞ShareLock，所以查询不阻塞create index（无concurrently）； RowExclusiveLock阻塞ShareLock，所以DML阻塞create index（无concurrently）；

concurrently创建分区索引

注意：在分区表上不能用concurrently创建索引

=> create index concurrently idx_datecreated on lzlpartition1(date_created);
ERROR: 0A000: cannot create index on partitioned table "lzlpartition1" concurrently
LOCATION: DefineIndex, indexcmds.c:665

有个patch https://commitfest.postgresql.org/35/2815/在解决这个问题。

目前可以在分区子表上concurrently创建索引。

--session1 仍然使用之前的DML事务
--session2 concurrently方式在子表上创建索引，等待
=> create index concurrently idx_datecreated_202301 on lzlpartition1_202301(date_created);

--session3 查询锁情况
=> select l.locktype,d.datname,r.relname,l.virtualxid,l.transactionid,l.pid,l.mode,l.granted from pg_locks l left join pg_database d on l.database=d.oid left join pg_class r on l.relation=r.oid 
where relname like '%lzlpartition1%';
 locktype | datname | relname | virtualxid | transactionid | pid | mode | granted 
----------+---------+---------------------------+------------+---------------+--------+--------------------------+---------
 relation | dbmgr | lzlpartition1_202301_pkey | [null] | [null] | 300371 | RowExclusiveLock | t
 relation | dbmgr | lzlpartition1_202301 | [null] | [null] | 99598 | ShareUpdateExclusiveLock | t
 relation | dbmgr | lzlpartition1_202301 | [null] | [null] | 300371 | RowExclusiveLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 300371 | AccessShareLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 300371 | RowExclusiveLock | t

concurrently申请的锁降低了一级，跟ROW EXCL不冲突了。锁都不冲突了，但是为什么concurrently本身还是被阻塞了呢？

it must wait for all existing transactions that could potentially modify or use the index to terminate.

官方文档解释concurrently需要等待潜在修改/使用索引的事务完成，我们这里的update语句更新了索引字段，所以concurrently需要等待它完成。 虽然concurrently本身因为之前的DML语句没有完成，但是这也有一个好处：concurrently不会阻塞后续的DML语句。

--concurrently没有完成的情况下
--session4 更新一条记录
=> update lzlpartition1 set name='abc' where date_created='2023-01-01 12:00:00';
UPDATE 1

汇总分区索引的锁问题：

分区表上只读/读写/创建索引时的锁跟普通表是差不多的，只需要注意事务会在分区主表和子表上都会加锁，所以后续阻塞链的锁更重时，会影响所有分区
只读事务不会阻塞create index，但是会阻塞drop index
DML会阻塞create index，也会阻塞create index concurrently，但是concurrently不会阻塞DML
虽然在分区表上create index可以自动在各个分区和未来分区上创建索引，但是由于阻塞问题不建议在生产直接使用
不能在分区主表上直接使用concurrently，所以需要在各个分区子表上concurrently创建索引
concurrently不会阻塞后续的事务，但本身会被之前的长事务阻塞，也可能导致创建的索引失效，所以需要关注长事务问题

创建分区索引的正确姿势
#

虽然不能以concurrently方式在分区表上创建索引，但可以在分区子表用concurrently创建索引，需要用到语法： CREATE INDEX ON ONLY ：在主表上创建一个无效索引，不会在子分区自动创建索引 CREATE INDEX CONCURRENTLY ：concurrently方式在子分区上创建索引 ALTER INDEX .. ATTACH PARTITION：将分区索引ATTACH到主索引上，所有子分区索引ATTACH后，分区主表索引自动标记为有效。不过在执行这些命令时仍然需要关注锁的情况

下面观察上面两个语句申请锁和阻塞的情况：（过程中全程开启session1的DML显示事务）

ONLY创建索引的阻塞情况

=> CREATE INDEX IDX_DATECREATED ON ONLY lzlpartition1(date_created);
--等待

--查看锁情况
 locktype | datname | relname | virtualxid | transactionid | pid | mode | granted 
----------+---------+----------------------+------------+---------------+--------+------------------+---------
 relation | dbmgr | lzlpartition1_202301 | [null] | [null] | 448243 | RowExclusiveLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 448243 | RowExclusiveLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 444399 | ShareLock | f

ONLY创建索引会申请ShareLock锁，ShareLock跟RowExclusiveLock是相互阻塞的。所以，虽然ONLY本身执行会很快，但是ONLY创建索引也不是无脑使用。

--将DML事务结束后，ONLY创建索引完成
 "idx_datecreated" btree (date_created) INVALID

CREATE INDEX ON ONLY在分区主表上创建了一个失效索引，且不会在子分区创建索引。

ATTACH索引的阻塞情况

--将ONLY索引创建完成后，再开启session1的DML显示事务
=> begin;
BEGIN
=> insert into lzlpartition1 values('1111','abc','2023-01-01 00:00:00');
INSERT 0 1

--session2 concurrently创建子分区的索引
=> create index concurrently idx_datecreated_202302 on lzlpartition1_202302(date_created);
CREATE INDEX --202302分区索引创建完成
=> create index concurrently idx_datecreated_202304 on lzlpartition1_202304(date_created);
CREATE INDEX --202302分区索引创建完成
=> create index concurrently idx_datecreated_202301 on lzlpartition1_202301(date_created);
----创建202302分区索引等待

concurrently会等待潜在使用索引的事务完成，我们这里的显示事务只插入了202301分区，也只有这个分区的concurrently创建索引没有完成。

--完成session1的DML显示事务，等待索引完成后，然后再次开启事务
=> commit;
COMMIT
=> begin;
BEGIN
=> insert into lzlpartition1 values('1111','abc','2023-01-01 00:00:01');
INSERT 0 1
--session2 attach索引
 => ALTER INDEX idx_datecreated ATTACH PARTITION idx_datecreated_202302;
ALTER INDEX --成功ATTACH
=> \d+ idx_datecreated
 Partitioned index "public.idx_datecreated"
 Column | Type | Key? | Definition | Storage | Stats target 
--------------+-----------------------------+------+--------------+---------+--------------
 date_created | timestamp without time zone | yes | date_created | plain | 
btree, for table "public.lzlpartition1", invalid
Partitions: idx_datecreated_202302 --202302子分区索引已经attach，索引仍为invalid
Access method: btree
--将剩余的子分区索引全部attach
=> ALTER INDEX idx_datecreated ATTACH PARTITION idx_datecreated_202301;
ALTER INDEX --成功ATTACH
=> ALTER INDEX idx_datecreated ATTACH PARTITION idx_datecreated_202304;
ALTER INDEX --成功ATTACH 
--完成所有子分区索引attach后，主表索引自动有效
=> \d+ idx_datecreated
 Partitioned index "public.idx_datecreated"
 Column | Type | Key? | Definition | Storage | Stats target 
--------------+-----------------------------+------+--------------+---------+--------------
 date_created | timestamp without time zone | yes | date_created | plain | 
btree, for table "public.lzlpartition1"
Partitions: idx_datecreated_202301,
 idx_datecreated_202302,
 idx_datecreated_202304
Access method: btree

attach不会被DML阻塞，直接完成。此时用partition of创建的新分区也会自动创建子分区索引。

综上所述，

CREATE INDEX ON ONLY会申请ShareLock锁，跟DML申请的RowExclusiveLock是相互阻塞的
CREATE INDEX CONCURRENTLY会申请ShareUpdateExclusiveLock锁，不会阻塞DML申请的RowExclusiveLock，但是CREATE INDEX CONCURRENTLY需要等待DML事务完成才能完成（concurrently可以获得锁，但不能完成）
ALTER INDEX .. ATTACH PARTITION会申请AccessShareLock，这是最轻的锁，跟DML申请的RowExclusiveLock相互不阻塞。
查询申请的是AccessShareLock最轻的锁，除非DDL申请AccessExclusiveLock最重的锁，不然不会发生阻塞

所以，直接在分区上create index会阻塞DML，是不可取的 创建分区索引的正确姿势：

--ONLY方式在分区主表上创建失效索引。快，会阻塞后续dml，会影响业务，需要关注长事务
CREATE INDEX IDX_DATECREATED ON ONLY lzlpartition1(date_created);
--CONCURRENTLY在各个分区子表上创建索引。慢，不会阻塞后续dml，不会影响业务，但需要关注DML长事务防止本身失败
create index concurrently idx_datecreated_202302 on lzlpartition1_202302(date_created);
--所有索引attach。快，不会发生业务阻塞
 ALTER INDEX idx_datecreated ATTACH PARTITION idx_datecreated_202302;

分区表添加主键和唯一索引
#

“主键索引”功能上等于“唯一索引+null约束”（但是主键只能有一个）。分区表创建唯一索引可以参考上面的索引创建最佳实践：only创建主表索引、concurrently创建子表索引、attach。而主键虽然支持普通表using index语法，但是目前不支持分区表这样使用：

=> ALTER TABLE lzlpartition1 ADD CONSTRAINT pk_id_date_created PRIMARY KEY USING INDEX idx_uniq;
ERROR: 0A000: ALTER TABLE / ADD CONSTRAINT USING INDEX is not supported on partitioned tables
LOCATION: ATExecAddIndexConstraint, tablecmds.c:8032

也就是说可以通过提前创建not null约束+attach索引的方式创建一个非空的唯一索引，但是最后一步using index添加主键却不行。

下面看下直接添加/删除主键的阻塞情况

直接删除主键

--session 1 
=> begin;
BEGIN
Time: 0.318 ms
=> select * from lzlpartition1 where date_created='2023-01-01 22:00:00';
 id | name | date_created 
------+----------------------------------+---------------------
 7715 | beee680a86e1d12790489e9ab4a4351b | 2023-01-01 22:00:00
 --session2 删除主键等待
 => alter table lzlpartition1 drop constraint lzlpartition1_pkey;
 
 --session3 观察
 => select l.locktype,d.datname,r.relname,l.virtualxid,l.transactionid,l.pid,l.mode,l.granted from pg_locks l left join pg_database d on l.database=d.oid left join pg_class r on l.relation=r.oid 
where relname like '%lzlpartition1%';
 locktype | datname | relname | virtualxid | transactionid | pid | mode | granted 
----------+---------+---------------------------+------------+---------------+-------+---------------------+---------
 relation | dbmgr | lzlpartition1_202301_pkey | [null] | [null] | 21659 | AccessShareLock | t
 relation | dbmgr | lzlpartition1_202301 | [null] | [null] | 21659 | AccessShareLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 95016 | AccessShareLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 95016 | AccessExclusiveLock | f
 relation | dbmgr | lzlpartition1 | [null] | [null] | 21659 | AccessShareLock | t

删除主键申请的是AccessExclusiveLock，阻塞一切

直接添加主键

--session1事务结束，session2的删除主键完成
--session1再次开启只读事务
--session2在分区表上添加主键，等待
=> ALTER TABLE lzlpartition1 ADD PRIMARY KEY(id, date_created);

--session3 观察锁
=> select l.locktype,d.datname,r.relname,l.virtualxid,l.transactionid,l.pid,l.mode,l.granted from pg_locks l left join pg_database d on l.database=d.oid left join pg_class r on l.relation=r.oid 
where relname like '%lzlpartition1%';
 locktype | datname | relname | virtualxid | transactionid | pid | mode | granted 
----------+---------+----------------------+------------+---------------+-------+---------------------+---------
 relation | dbmgr | lzlpartition1_202301 | [null] | [null] | 21659 | AccessShareLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 95016 | AccessShareLock | t
 relation | dbmgr | lzlpartition1 | [null] | [null] | 95016 | AccessExclusiveLock | f --添加主键的会话
 relation | dbmgr | lzlpartition1 | [null] | [null] | 21659 | AccessShareLock | t

添加主键在主表上申请AccessExclusiveLock，阻塞一切。分区表上添加索引很慢，主键又会造成后续的阻塞，目前没有影响较小的在分区表上添加主键的办法。虽然没有达到目的，可以考虑用“attach唯一索引+非空约束”的办法；或者只能申请较长的停分区表业务，等待创建索引完成；或者通过第三方同步工具将数据插入一个带主键的分区表。

hash分区表添加分区
#

如果新增后的分区数为之前的整数倍，那么我们将会知道新分区的数据来自哪个老分区。比如将原本只有3个分区的hash分区表做成6个分区的，我们可以知道分区数据来源

虽然了解了这种简单的数据特性，但实际情况可能没有什么用，因为新分区的hash分区总是被暴力插入的。从操作上“3->4”的新增分区操作和“3->6”的新增分区操作没有什么区别。目前成熟的数据同步工具已经非常多了，比如使用dts把表插入到新表中然后做表切换，停机时间会很短，生产环境应优先选择这个方案。下面是主要是测试和观察hash分区表手动新增整数倍分区时的操作：

分区信息

SELECT tableoid::regclass,count(*) FROM orders group by tableoid::regclass;
 tableoid | count 
-----------+-------
 orders_p1 | 3377
 orders_p3 | 3354
 orders_p2 | 3369

2. detach分区
 3个分区的hash原生分区表再添加3个分区

ALTER TABLE orders DETACH PARTITION orders_p1;
ALTER TABLE orders DETACH PARTITION orders_p2;
ALTER TABLE orders DETACH PARTITION orders_p3;

rename分区

ALTER TABLE orders_p1 RENAME TO bak_orders_p1;
ALTER TABLE orders_p2 RENAME TO bak_orders_p2;
ALTER TABLE orders_p3 RENAME TO bak_orders_p3;

在老表上创建6个hash分区

CREATE TABLE orders_p1 PARTITION OF orders FOR VALUES WITH (MODULUS 6, REMAINDER 0);
CREATE TABLE orders_p2 PARTITION OF orders FOR VALUES WITH (MODULUS 6, REMAINDER 1);
CREATE TABLE orders_p3 PARTITION OF orders FOR VALUES WITH (MODULUS 6, REMAINDER 2);
CREATE TABLE orders_p4 PARTITION OF orders FOR VALUES WITH (MODULUS 6, REMAINDER 3);
CREATE TABLE orders_p5 PARTITION OF orders FOR VALUES WITH (MODULUS 6, REMAINDER 4);
CREATE TABLE orders_p6 PARTITION OF orders FOR VALUES WITH (MODULUS 6, REMAINDER 5);

查看分区信息注意分区约束使用的函数

\d+ orders_p1
 Table "public.orders_p1"
 Column | Type | Collation | Nullable | Default | Storage | Stats target | Description 
----------+-----------------------+-----------+----------+---------+----------+--------------+-------------
 order_id | integer | | | | plain | | 
 name | character varying(10) | | | | extended | | 
Partition of: orders FOR VALUES WITH (modulus 6, remainder 0)
Partition constraint: satisfies_hash_partition('412053'::oid, 6, 0, order_id)
Access method: heap

计算老分区数据需要插入到哪个新分区上例如原先为modulus 3，remainder 0的分区，需要把数据分别插入到modulus 6，remainder0和3两个分区中。

 select count(*) from bak_orders_p1 where satisfies_hash_partition('412053'::oid, 6, 0, order_id)=true;
 count 
-------
 1776
 select count(*) from bak_orders_p1 where satisfies_hash_partition('412053'::oid, 6, 3, order_id)=true;
 count 
-------
 1601
 select count(*) from bak_orders_p1;
 count 
-------
 3377

6.通过分区子表插入数据可以直接把数据插入对应的分区子表上，而不是通过分区主表插入

INSERT INTO orders_p1 SELECT * FROM bak_orders_p1 where satisfies_hash_partition('412053'::oid, 6, 0, order_id)=true;
INSERT INTO orders_p2 SELECT * FROM bak_orders_p2 where satisfies_hash_partition('412053'::oid, 6, 1, order_id)=true;
INSERT INTO orders_p3 SELECT * FROM bak_orders_p3 where satisfies_hash_partition('412053'::oid, 6, 2, order_id)=true;
INSERT INTO orders_p4 SELECT * FROM bak_orders_p1 where satisfies_hash_partition('412053'::oid, 6, 3, order_id)=true;
INSERT INTO orders_p5 SELECT * FROM bak_orders_p2 where satisfies_hash_partition('412053'::oid, 6, 4, order_id)=true;
INSERT INTO orders_p6 SELECT * FROM bak_orders_p3 where satisfies_hash_partition('412053'::oid, 6, 5, order_id)=true;

验证3个老分区的数据已插入到6个新分区中

SELECT tableoid::regclass,count(*) FROM orders group by tableoid::regclass;
tableoid | count 
-----------+-------
orders_p3 | 1665
orders_p5 | 1678
orders_p1 | 1776
orders_p6 | 1689
orders_p4 | 1601
orders_p2 | 1691

修改分区字段长度索引会重建
#

修改字段需要考虑三个方面：表重写、索引重建、统计信息丢失

修改字段类型、字段长度减少都会重写表
字段长度增加仅会丢失统计信息，一个例外情况是将长度改小（或者int4改int8）会重写表
字段长度增加不会重建索引，一个例外情况是分区表字段长度增加会重建索引（如果这个字段有索引）

修改字段，参考PostgreSQL学徒。

这里主要测试分区表将字段改长的场景，如果存在索引的话，可能会引起分区表上的事务阻塞。普通表，将有索引的字段改长：

--新建普通表和索引
=> create table t111(id int,name varchar(50));
CREATE TABLE
=> insert into t111 values(1001,'abc');
INSERT 0 1
=> create index idx111 on t111(name);
CREATE INDEX

--索引文件relfilenode为417728
 select pg_relation_filepath('idx111');
 pg_relation_filepath 
----------------------
 base/16398/417728
(1 row)

--将字段改长
=> alter table t111 alter column name type varchar(60);
ALTER TABLE
--索引文件relfilenode为417728，未发生变化，普通表索引未重建
=> select pg_relation_filepath('idx111');
 pg_relation_filepath 
----------------------
 base/16398/417728

分区表，将有索引的字段改长：

--在分区表上创建一个索引
=> create index idx_name on lzlpartition1(name);
CREATE INDEX
--查看其中一个分区上的索引
=> \d+ lzlpartition1_202301
 Table "dbmgr.lzlpartition1_202301"
 Column | Type | Collation | Nullable | Default | Storage | Stats target | Description 
--------------+-----------------------------+-----------+----------+---------+----------+--------------+-------------
 id | integer | | | | plain | | 
 name | character varying(50) | | | | extended | | 
 date_created | timestamp without time zone | | not null | now() | plain | | 
Partition of: lzlpartition1 FOR VALUES FROM ('2023-01-01 00:00:00') TO ('2023-02-01 00:00:00')
Partition constraint: ((date_created IS NOT NULL) AND (date_created >= '2023-01-01 00:00:00'::timestamp without time zone) AND (date_created < '2023-02-01 00:00:00'::timestamp without time zone))
Indexes:
 "lzlpartition1_202301_name_idx" btree (name)
Access method: heap

=> select pg_relation_filepath('lzlpartition1_202301_name_idx') idx,pg_relation_filepath('lzlpartition1_202301') tbl;
 idx | tbl 
-------------------+-------------------
 base/16398/417810 | base/16398/417800
(1 row)

--将索引字段改大，分区表索引重建
=> alter table lzlpartition1 alter column name type varchar(60);
ALTER TABLE
=> select pg_relation_filepath('lzlpartition1_202301_name_idx') idx,pg_relation_filepath('lzlpartition1_202301') tbl;
 idx | tbl 
-------------------+-------------------
 base/16398/417814 | base/16398/417800

--将索引字段改小，分区表重写
=> alter table lzlpartition1 alter column name type varchar(40);
ALTER TABLE
Time: 609.585 ms
=> select pg_relation_filepath('lzlpartition1_202301_name_idx') idx,pg_relation_filepath('lzlpartition1_202301') tbl;
 idx | tbl 
-------------------+-------------------
 base/16398/417828 | base/16398/417825

--将索引字段保持原样，分区表索引重建
=> alter table lzlpartition1 alter column name type varchar(40);
ALTER TABLE
=> select pg_relation_filepath('lzlpartition1_202301_name_idx') idx,pg_relation_filepath('lzlpartition1_202301') tbl;
 idx | tbl 
-------------------+-------------------
 base/16398/417834 | base/16398/417825

普通表改大字段长度只需要关注统计信息会丢失（int到bigint除外）；但是分区表在改大字段长度时，如果这个字段上有索引，不仅会丢失统计信息，还会重建索引。由于alter修改字段是8级锁，所以重建索引期间会导致长时间阻塞。建议：先把索引删除，修改完字段后，“父表ONLY+子表CIC+ATTACH”的方式建索引。

分区表维护小结
#

partition of/drop table/DETACH需要 ACCESS EXCLUSIVE锁；推荐ATTACH/DETACH CONCURRENTLY，它们不会造成阻塞，DETACH CONCURRENTLY需关注已有长事务
attach表分区前可以提前在分区上创建约束，这样会减去在attach时扫描分区数据的时间
目前不支持分区表CIC创建索引，可以通过在“主表上only+子表上concurrently+attach索引”的方式创建分区索引，减少业务阻塞时间
分区表不支持using index方式创建主键
需要关注分区表修改字段长度这个例外情况

分区表的优化
#

分区裁剪
#

分区裁剪（Partition Pruning）可以为声明式分区提升性能，是分区表优化非常重要的特性。如果没有分区裁剪，那么查询会扫描所有分区。当有分区裁剪时，优化器可以通过where条件过滤那些不需要访问的分区分区裁剪依赖于分区约束Partition constraint(\d+可以看到），也就是说查询必须带有分区键条件才能进行裁剪。这个约束不同于一般约束constraint，它在分区创建时自动创建。分区裁剪由enable_partition_pruning参数控制，默认为on。

--没有分区裁剪时，会访问所有分区
=> set enable_partition_pruning=off;
SET

=> explain select count(*) from lzlpartition1 where date_created='2023-01-01';
 QUERY PLAN 
--------------------------------------------------------------------------------------------------
 Aggregate (cost=1872.08..1872.09 rows=1 width=8)
 -> Append (cost=0.00..1872.07 rows=4 width=0)
 -> Seq Scan on lzlpartition1_202301 lzlpartition1_1 (cost=0.00..992.30 rows=1 width=0)
 Filter: (date_created = '2023-01-01 00:00:00'::timestamp without time zone)
 -> Seq Scan on lzlpartition1_202302 lzlpartition1_2 (cost=0.00..864.12 rows=1 width=0)
 Filter: (date_created = '2023-01-01 00:00:00'::timestamp without time zone)
 -> Seq Scan on lzlpartition1_202304 lzlpartition1_3 (cost=0.00..15.62 rows=2 width=0)
 Filter: (date_created = '2023-01-01 00:00:00'::timestamp without time zone)

--有分区裁剪时，不需要访问的分区被排除
=> set enable_partition_pruning=on;
SET

=> explain select count(*) from lzlpartition1 where date_created='2023-01-01';
 QUERY PLAN 
------------------------------------------------------------------------------------------
 Aggregate (cost=992.30..992.31 rows=1 width=8)
 -> Seq Scan on lzlpartition1_202301 lzlpartition1 (cost=0.00..992.30 rows=1 width=0)
 Filter: (date_created = '2023-01-01 00:00:00'::timestamp without time zone)
(3 rows)

（官方文档说生成执行计划时发生裁剪，那么explain有Subplans Removed字样，经测试有时候没有，就像上面的explain例子） 分区裁剪可能发生在两个阶段：生成执行计划时、真正执行时 为什么会发生这样的情况呢？因为有时候只有执行时才会知道那些分区可以裁剪。有两种情况：

Parameterized Nested Loop Joins: The parameter from the outer side of the join can be used to determine the minimum set of inner side partitions to scan.
Initplans: Once an initplan has been executed we can then determine which partitions match the value from the initplan.

模拟执行时发生裁剪：从其他表拿数据优化器肯定不知道数据是什么，就无法以此为依据在执行计划时发生分区裁剪：

--创建一个其他表
=> create table x(date_created timestamp);
CREATE TABLE

=> insert into x values('2023-01-01 09:00:00');
INSERT 0 1

--仅生成执行计划，不执行，没有发生裁剪
=> explain select count(*) from lzlpartition1 where date_created=(select date_created from x);
 QUERY PLAN 
--------------------------------------------------------------------------------------------------
 Aggregate (cost=1904.68..1904.69 rows=1 width=8)
 InitPlan 1 (returns $0)
 -> Seq Scan on x (cost=0.00..32.60 rows=2260 width=8)
 -> Append (cost=0.00..1872.07 rows=4 width=0)
 -> Seq Scan on lzlpartition1_202301 lzlpartition1_1 (cost=0.00..992.30 rows=1 width=0)
 Filter: (date_created = $0)
 -> Seq Scan on lzlpartition1_202302 lzlpartition1_2 (cost=0.00..864.12 rows=1 width=0)
 Filter: (date_created = $0)
 -> Seq Scan on lzlpartition1_202304 lzlpartition1_3 (cost=0.00..15.62 rows=2 width=0)
 Filter: (date_created = $0)
(10 rows)

--执行sql，发生裁剪。关键字never executed
=> explain analyze select count(*) from lzlpartition1 where date_created=(select date_created from x);
 QUERY PLAN 
--------------------------------------------------------------------------------------------------------------------------------------------
 Aggregate (cost=1904.68..1904.69 rows=1 width=8) (actual time=5.680..5.682 rows=1 loops=1)
 InitPlan 1 (returns $0)
 -> Seq Scan on x (cost=0.00..32.60 rows=2260 width=8) (actual time=0.013..0.014 rows=1 loops=1)
 -> Append (cost=0.00..1872.07 rows=4 width=0) (actual time=0.029..5.676 rows=2 loops=1)
 -> Seq Scan on lzlpartition1_202301 lzlpartition1_1 (cost=0.00..992.30 rows=1 width=0) (actual time=0.008..5.652 rows=2 loops=1)
 Filter: (date_created = $0)
 Rows Removed by Filter: 45382
 -> Seq Scan on lzlpartition1_202302 lzlpartition1_2 (cost=0.00..864.12 rows=1 width=0) (never executed)
 Filter: (date_created = $0)
 -> Seq Scan on lzlpartition1_202304 lzlpartition1_3 (cost=0.00..15.62 rows=2 width=0) (never executed)
 Filter: (date_created = $0)
 Planning Time: 0.157 ms
 Execution Time: 5.732 ms
(13 rows)

partition wise join
#

partition wise join可以减少分区连接的代价。假设有两个分区表t1、t2，他们都有3个分区(p1,p2,p3)且分区定义一致，t1的每个分区10条数据，t2的每个分区20条数据：

	t1	t2
p1	10 rows	20 rows
p2	10 rows	20 rows
p3	10 rows	20 rows
此时t1和t2表进行连接，

正常情况下需要把所有两个分区数据取出进行连接，他们的行的连接比较次数为： (10+10+10)*(20+20+20)=180次
有partition wise join的情况下，因为结构差不多，只需要连接对应的分区，如 t1.p1<=>t2.p1， t1.p2<=>t2.p2， t1.p3<=>t2.p3，此时的连接比较次数为： (10*20)*3=90次

在分区特别多的情况下，partition wise join的代价会小很多。参数enable_partitionwise_join：是否开启partition wise join，默认关闭

partition wise join的前提条件非常苛刻：

连接条件必须包含分区键
分区键必须是相同的数据类型
分区必须一一对应

看上去条件苛刻，两个不同的用途的表能产生partition wise join的情况是也是比较少的，比较常见的应该是两个表都是range时间分区。还有一种情况，如果是分区表自我连接，也符合partition wise join的前提：

--未开启partition wise join的情况
=> explain select p1.*,p2.name from lzlpartition1 p1,lzlpartition1 p2 where p1.date_created=p2.date_created and p2.name='256ac66bb53d31bc6124294238d6410c';
 QUERY PLAN 
----------------------------------------------------------------------------------------------------------------
 Hash Join (cost=546.64..9256.34 rows=182252 width=288)
 Hash Cond: (p1.date_created = p2.date_created)
 -> Append (cost=0.00..2085.46 rows=85364 width=150)
 -> Seq Scan on lzlpartition1_202301 p1_1 (cost=0.00..878.84 rows=45384 width=150)
 -> Seq Scan on lzlpartition1_202302 p1_2 (cost=0.00..765.30 rows=39530 width=150)
 -> Seq Scan on lzlpartition1_202304 p1_3 (cost=0.00..14.50 rows=450 width=150)
 -> Hash (cost=541.30..541.30 rows=427 width=146)
 -> Append (cost=7.17..541.30 rows=427 width=146)
 -> Bitmap Heap Scan on lzlpartition1_202301 p2_1 (cost=7.17..284.30 rows=227 width=146)
 Recheck Cond: ((name)::text = '256ac66bb53d31bc6124294238d6410c'::text)
 -> Bitmap Index Scan on lzlpartition1_202301_name_idx (cost=0.00..7.12 rows=227 width=0)
 Index Cond: ((name)::text = '256ac66bb53d31bc6124294238d6410c'::text)
 -> Bitmap Heap Scan on lzlpartition1_202302 p2_2 (cost=6.95..248.52 rows=198 width=146)
 Recheck Cond: ((name)::text = '256ac66bb53d31bc6124294238d6410c'::text)
 -> Bitmap Index Scan on lzlpartition1_202302_name_idx (cost=0.00..6.90 rows=198 width=0)
 Index Cond: ((name)::text = '256ac66bb53d31bc6124294238d6410c'::text)
 -> Bitmap Heap Scan on lzlpartition1_202304 p2_3 (cost=2.66..6.35 rows=2 width=146)
 Recheck Cond: ((name)::text = '256ac66bb53d31bc6124294238d6410c'::text)
 -> Bitmap Index Scan on lzlpartition1_202304_name_idx (cost=0.00..2.66 rows=2 width=0)
 Index Cond: ((name)::text = '256ac66bb53d31bc6124294238d6410c'::text)
(20 rows)

--开启partition wise join的情况
=> set enable_partitionwise_join =on;
SET

M=> explain select p1.*,p2.name from lzlpartition1 p1,lzlpartition1 p2 where p1.date_created=p2.date_created and p2.name='256ac66bb53d31bc6124294238d6410c';
 QUERY PLAN 
----------------------------------------------------------------------------------------------------------------
 Append (cost=287.14..2529.83 rows=438 width=288)
 -> Hash Join (cost=287.14..1338.49 rows=232 width=288)
 Hash Cond: (p1_1.date_created = p2_1.date_created)
 -> Seq Scan on lzlpartition1_202301 p1_1 (cost=0.00..878.84 rows=45384 width=150)
 -> Hash (cost=284.30..284.30 rows=227 width=146)
 -> Bitmap Heap Scan on lzlpartition1_202301 p2_1 (cost=7.17..284.30 rows=227 width=146)
 Recheck Cond: ((name)::text = '256ac66bb53d31bc6124294238d6410c'::text)
 -> Bitmap Index Scan on lzlpartition1_202301_name_idx (cost=0.00..7.12 rows=227 width=0)
 Index Cond: ((name)::text = '256ac66bb53d31bc6124294238d6410c'::text)
 -> Hash Join (cost=250.99..1166.55 rows=202 width=288)
 Hash Cond: (p1_2.date_created = p2_2.date_created)
 -> Seq Scan on lzlpartition1_202302 p1_2 (cost=0.00..765.30 rows=39530 width=150)
 -> Hash (cost=248.52..248.52 rows=198 width=146)
 -> Bitmap Heap Scan on lzlpartition1_202302 p2_2 (cost=6.95..248.52 rows=198 width=146)
 Recheck Cond: ((name)::text = '256ac66bb53d31bc6124294238d6410c'::text)
 -> Bitmap Index Scan on lzlpartition1_202302_name_idx (cost=0.00..6.90 rows=198 width=0)
 Index Cond: ((name)::text = '256ac66bb53d31bc6124294238d6410c'::text)
 -> Hash Join (cost=6.37..22.60 rows=4 width=288)
 Hash Cond: (p1_3.date_created = p2_3.date_created)
 -> Seq Scan on lzlpartition1_202304 p1_3 (cost=0.00..14.50 rows=450 width=150)
 -> Hash (cost=6.35..6.35 rows=2 width=146)
 -> Bitmap Heap Scan on lzlpartition1_202304 p2_3 (cost=2.66..6.35 rows=2 width=146)
 Recheck Cond: ((name)::text = '256ac66bb53d31bc6124294238d6410c'::text)
 -> Bitmap Index Scan on lzlpartition1_202304_name_idx (cost=0.00..2.66 rows=2 width=0)
 Index Cond: ((name)::text = '256ac66bb53d31bc6124294238d6410c'::text)
(25 rows)

在没有开启partition wise join的情况下，优化器需要先访问分区表p2的所有分区数据（符合条件的）放一起(append)，然后与分区表p1的所有分区数据通过分区键连接(Hash Join)。在开启partition wise join的情况下，优化器将p1、p2两个分区表（实际上是一个，访问了两次）所对应的分区相连接： p1_1<=>p2_1 Hash Join p1_2<=>p2_2 Hash Join p1_3<=>p2_3 Hash Join 然后再把数据合到一起（append）。如果数据分区足够多，再加上分区裁剪，partition wise join会有很好的优化效果。

partition wise grouping/aggregation
#

分区表在进行分区数据聚合计算时，分区可以各自算各自的，不需要扫描所有分区数据进行聚合计算，只需要各自分区的数据聚合计算完成后汇总返回即可。没有partition wise grouping本质上是“先扫描所有分区，再聚合计算”；有partition wise grouping是“先分区聚合计算，再汇合数据”。

partition wise grouping的优势如下：

分区在foreign server时，可以将聚合算子下推到foreign server
聚合到hash表时，每个分区而不是所有分区去使用内存hash表的空间，可以减少内存使用
聚合算法下方到各自的分区可以更好的使用索引、并行等等特性
更少的数据对比。虽然数据扫描都是一样的，但是减少了数据对比，比如最后一个分区的数据不需要与第一个分区的数据进行对比

参数enable_partitionwise_aggregate：是否开启partition wise grouping/aggregation，默认关闭

partition wise aggregate示例：

=> vacuum (analyze) lzlpartition1;

--未开启wise agg
=> set enable_partitionwise_aggregate =off;
SET
=> explain select date_created,min(id),count(*) from lzlpartition1 group by date_created order by 1,2,3;
 QUERY PLAN 
-------------------------------------------------------------------------------------------------------------
 Sort (cost=10354.94..10562.89 rows=83180 width=20)
 Sort Key: lzlpartition1.date_created, (min(lzlpartition1.id)), (count(*))
 -> HashAggregate (cost=2725.69..3557.49 rows=83180 width=20)
 Group Key: lzlpartition1.date_created
 -> Append (cost=0.00..2085.46 rows=85364 width=12)
 -> Seq Scan on lzlpartition1_202301 lzlpartition1_1 (cost=0.00..878.84 rows=45384 width=12)
 -> Seq Scan on lzlpartition1_202302 lzlpartition1_2 (cost=0.00..765.30 rows=39530 width=12)
 -> Seq Scan on lzlpartition1_202304 lzlpartition1_3 (cost=0.00..14.50 rows=450 width=12)


--开启wise agg
=> set enable_partitionwise_aggregate =on;
SET
=> explain select date_created,min(id),count(*) from lzlpartition1 group by date_created order by 1,2,3;
 QUERY PLAN 
-------------------------------------------------------------------------------------------------------------
 Sort (cost=10356.08..10564.32 rows=83296 width=20)
 Sort Key: lzlpartition1.date_created, (min(lzlpartition1.id)), (count(*))
 -> Append (cost=1219.22..3548.31 rows=83296 width=20)
 -> HashAggregate (cost=1219.22..1663.09 rows=44387 width=20)
 Group Key: lzlpartition1.date_created
 -> Seq Scan on lzlpartition1_202301 lzlpartition1 (cost=0.00..878.84 rows=45384 width=12)
 -> HashAggregate (cost=1061.77..1448.86 rows=38709 width=20)
 Group Key: lzlpartition1_1.date_created
 -> Seq Scan on lzlpartition1_202302 lzlpartition1_1 (cost=0.00..765.30 rows=39530 width=12)
 -> HashAggregate (cost=17.88..19.88 rows=200 width=20)
 Group Key: lzlpartition1_2.date_created
 -> Seq Scan on lzlpartition1_202304 lzlpartition1_2 (cost=0.00..14.50 rows=450 width=12)
(12 rows)

无wise aggregate时，先扫描所有数据再合并（Append），合并后再聚合计算（HashAggregate）； partition wise aggregate先在分区聚合计算（HashAggregate），然后在合并结果（Append）。

partial aggregation 聚合算法可以下放到分区上进行计算，此时聚合后的数据分为两种情况：聚合数据不重复（group包含分区键），聚合数据有重复（group不包含分区键）。当聚合数据不重复时，只需要把各自分区算出来的聚合数据简单的加到一起（append）即可（就像上面的案例）；当各自分区算出来的聚合数据重复时，仍然需要再聚合计算一次（Finalize Aggregate）。不包含分区键的聚合计算就是partial aggregation。

partial aggregation示例：

--group by不是分区键时
=> show enable_partitionwise_aggregate;
 enable_partitionwise_aggregate 
--------------------------------
 on
=> explain select id,count(*) from lzlpartition1 group by id ;
 QUERY PLAN 
------------------------------------------------------------------------------------------------------------
 Finalize HashAggregate (cost=2474.80..2573.80 rows=9900 width=12)
 Group Key: lzlpartition1.id
 -> Append (cost=1105.76..2377.47 rows=19467 width=12)
 -> Partial HashAggregate (cost=1105.76..1202.28 rows=9652 width=12)
 Group Key: lzlpartition1.id
 -> Seq Scan on lzlpartition1_202301 lzlpartition1 (cost=0.00..878.84 rows=45384 width=4)
 -> Partial HashAggregate (cost=962.95..1059.10 rows=9615 width=12)
 Group Key: lzlpartition1_1.id
 -> Seq Scan on lzlpartition1_202302 lzlpartition1_1 (cost=0.00..765.30 rows=39530 width=4)
 -> Partial HashAggregate (cost=16.75..18.75 rows=200 width=12)
 Group Key: lzlpartition1_2.id
 -> Seq Scan on lzlpartition1_202304 lzlpartition1_2 (cost=0.00..14.50 rows=450 width=4)

group by不包含分区键，也可以进行聚合计算，但是必须在稍后总聚合Finalize HashAggregate

即使没有group by，也可能发生Partial Aggregate：

=> show enable_partitionwise_aggregate;
 enable_partitionwise_aggregate 
--------------------------------
 on
=> explain select count(*) from lzlpartition1;
 QUERY PLAN 
------------------------------------------------------------------------------------------------------------
 Finalize Aggregate (cost=1872.10..1872.11 rows=1 width=8)
 -> Append (cost=992.30..1872.10 rows=3 width=8)
 -> Partial Aggregate (cost=992.30..992.31 rows=1 width=8)
 -> Seq Scan on lzlpartition1_202301 lzlpartition1 (cost=0.00..878.84 rows=45384 width=0)
 -> Partial Aggregate (cost=864.12..864.13 rows=1 width=8)
 -> Seq Scan on lzlpartition1_202302 lzlpartition1_1 (cost=0.00..765.30 rows=39530 width=0)
 -> Partial Aggregate (cost=15.62..15.63 rows=1 width=8)
 -> Seq Scan on lzlpartition1_202304 lzlpartition1_2 (cost=0.00..14.50 rows=450 width=0)

=> explain select max(date_created) from lzlpartition1;
 QUERY PLAN 
------------------------------------------------------------------------------------------------------------
 Finalize Aggregate (cost=1872.10..1872.11 rows=1 width=8)
 -> Append (cost=992.30..1872.10 rows=3 width=8)
 -> Partial Aggregate (cost=992.30..992.31 rows=1 width=8)
 -> Seq Scan on lzlpartition1_202301 lzlpartition1 (cost=0.00..878.84 rows=45384 width=8)
 -> Partial Aggregate (cost=864.12..864.13 rows=1 width=8)
 -> Seq Scan on lzlpartition1_202302 lzlpartition1_1 (cost=0.00..765.30 rows=39530 width=8)
 -> Partial Aggregate (cost=15.62..15.63 rows=1 width=8)
 -> Seq Scan on lzlpartition1_202304 lzlpartition1_2 (cost=0.00..14.50 rows=450 width=8)
 

触发Partial Aggregate的前提不是group。应从Partial Aggregate的目的去考虑，它的目的是把聚合下放到分区，那么没有group的聚合其实也可以这么做，就像上面两个例子：他们都是在分区上聚合计算后（Partial Aggregate），汇总到一起再聚合计算一次（ Finalize Aggregate）；如果没有打开参数，这些聚合发生在扫描完所有分区后。

分区表的历史
#

声明式分区经过了多个版本的增强，如今已非常成熟。对于历史版本的声明式分区，功能增强如下：

PG9.6以前

只能继承表实现分区功能

PG10

支持声明式分区
支持range、list分区
支持attach/detach表分区
支持分区裁剪

PG11

增加支持HASH分区
支持创建主键、外键、索引、触发器
支持update分区键、自动创建分区上的索引
支持default分区
支持attach索引
支持FOR EACH ROW触发器，自动在已有/未来的子分区上创建
新增enable_partition_pruning参数；裁剪增强
支持partition wise join
支持partition wise aggregation

PG12

增强查询、插入、pruning、COPY性能
支持外键约束to分区表
支持非阻塞分区表ATTACH:ALTER TABLE ATTACH PARTITION

PG13

增强pruning
增强partition wise join
支持BEFORE triggers
支持发布分区表；支持订阅写入分区表

PG14

增强update、delete性能
支持非阻塞分区表DETACH：ALTER TABLE ... DETACH PARTITION ... CONCURRENTLY
支持reindex分区表的索引

PG15

增强执行计划生成，减少多分区时执行计划生成时间
增强排序
支持cluster分区表

PG16

增强generated列的限制，主表有generated列子分区也必须包含。
增强查找range、list分区

参考
#

《PostgreSQL修炼之道》

https://mp.weixin.qq.com/s/NW8XOZNq0YlDZvx24H737Q https://www.postgresql.org/docs/current/ddl-partitioning.html https://www.postgresql.org/docs/current/ddl-inherit.html https://www.postgresql.org/docs/13/sql-altertable.html https://github.com/postgrespro/pg_pathman https://developer.aliyun.com/article/62314 https://hevodata.com/learn/postgresql-partitions https://www.postgresql.fastware.com/postgresql-insider-prt-ove https://www.buckenhofer.com/2021/01/postgresql-partitioning-guide/ https://www.depesz.com/2018/05/01/waiting-for-postgresql-11-support-partition-pruning-at-execution-time/ https://blog.csdn.net/horses/article/details/86164273

http://www.pgsql.tech/article_0_10000102

https://brandur.org/fragments/postgres-partitioning-2022

PostgreSQL内存浅析

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

体系结构
#

（https://www.postgresql.fastware.com/blog/lets-get-back-to-basics-postgresql-memory-components）

（http://geekdaxue.co/read/fcant@sql/qts5is)

共享内存
#

linux的共享内存实现
#

(https://momjian.us/main/writings/pgsql/inside_shmem.pdf)

linux上的共享内存 共享内存是基于 Unix 的操作系统（包括 Linux）支持的 IPC（进程间通信）机制。它是一种内存类型，多个进程可以同时使用它们来相互通信。共享内存是最快的IPC（inter-process communication)机制之一，因为它不需要进程间相互copy数据。进程可以通过自己的地址空间访问到共享内存。

共享内存的两种形式 共享内存的一种形式是内存映射文件。一旦多个进程将同一文件映射到其地址空间，它们就可以访问文件的内容，并直接使用映射的内存同时更新文件。共享内存的另一种形式是匿名内存。它是指程序分配的共享内存区域，而不将其与文件或持久存储机制相关联。

mmap() map file 到一个进程的地址空间使用的是mmap()，匿名内存也可以用mmap()。mmap是标准C库里的。匿名内存使用的flag应是MAP_ANONYMOUS orMAP_ANON，此时fd为空或者-1，offset应该为0。

http://www.tutorialsdaddy.com/courses/linux-device-driver/lessons/mmap/

pg中的共享内存
#

https://www.interdb.jp/pg/pgsql02.html

pg中有许多共享内存：shared buffers、wal buffer、clog buffer、lock space等

shared buffer pg缓存数据的共享内存区，类似oracle的SGA。当数据命中shared buffer时，直接从内存中读取而不需要发生磁盘IO。 PostgreSQL 将表中的页面和索引从持久存储加载到该区域，并直接操作它们。

wal buffer 为确保服务器故障不会丢失任何数据，PostgreSQL 支持 WAL 机制。WAL 数据（也称为 XLOG 记录）是 PostgreSQL 中的事务日志。WAL BUFFER是写入持久性存储之前 WAL 数据的缓冲区。

CLOG BUFFER 提交日志（CLOG）为并发控制机制保留所有事务（例如，in_progress、已提交、已中止）的状态。相应的CLOG BUFFER是CLOG写入磁盘前的缓冲区。

pg的共享内存相关参数
#

shared_buffers 默认128M，建议配置为25%总内存。因为PostgreSQL的私有内存一般会占的比较多，而且依赖cache，必须给OS留足内存，所以不建议像oracle那样把SGA调到一个比较大的值（相对总内存来说）。

shared_memory_type 指定共享内存的实现方法，不仅是shared_buffer也包含其他共享数据的区域。共享内存的实现方式因平台而不同，（看上去）linux的默认为mmap。其他值有：

posix (for POSIX shared memory allocated using shm_open)
sysv (for System V shared memory allocated via shmget)
windows (for Windows shared memory)
mmap (to simulate shared memory using memory-mapped files stored in the data directory)

默认情况下，PostgreSQL使用极少量的System V共享内存，绝大部分都是mmap共享内存。由于POSIX和System V的IPC区别，信号实现不同，可显式将shared_memory_type参数调整IPC实现机制：

设置system V IPC（默认是mmap）：在Linux和FreeBSD系统中默认共享内存系统设置一般足够了，shared_memory_type设置为sysv在这2个系统上也不生效（System V semaphores are not used on this platform）。 OpenBSD系统上，如果将shared_memory_type设置为sysv，默认的共享内存系统参数就不够，需要通过sysctl调整。
设置POSIX IPC： POSIX semaphores在Linux和FreeBSD上有效。

dynamic_shared_memory_type 动态共享内存的机制，默认为posix，该参数对并行查询很重要。关于/dev/shm的社区邮件描述：

PostgreSQL creates segments in /dev/shm for parallel queries (via
shm_open()), not for shared buffers. The amount used is controlled by
work_mem. Queries can use up to work_mem for each node you see in the
EXPLAIN plan, and for each process, so it can be quite a lot if you
have lots of parallel worker processes and/or lots of
tables/partitions being sorted or hashed in your query.

翻译：

并行查询用的是POSIX，会在/dev/shm创建segment
并行查询不是使用的shared buffers
每个查询的plan node由work_mem限制！

min_dynamic_shared_memory 被并行查询使用的内存初始大小，在server启动时分配，与huge_pages，dynamic_shared_memory_type相关

huge_pages 该参数控制主共享内存区是否使用大页，也就是说私有内存、操作上的内存不受这个限制。pg使用大页目前只支持linux和windows系统；在linux系统中，只支持shared_memory_type设置为mmap时！

可用设置	描述
try	default, 尝试申请大页
on	用大页内存，没申请到大页不会启动server
off	不使用大页

huge_page_size 控制大页的大小。默认为0，表示pg使用的是操作系统提供的大页大小。只在linux上支持设置非默认值。

pg_shmem_allocations视图
#

pg_shmem_allocations是pg13开始提供的视图，可查看主要的共享内存段的分配情况，包括postgres本身和插件的。

> select sum(allocated_size)/1024/1024/1024 gb from pg_shmem_allocations;
 gb 
--------------------
 2.7658920288085938
 
 >select * from pg_shmem_allocations order by 4 desc;
 name | off | size | allocated_size 
-------------------------------------+------------+------------+----------------
 Buffer Blocks | 38575360 | 2415919104 | 2415919104
 [null] | 2729553280 | 240300672 | 240300672
 <anonymous> | [null] | 240198528 | 240198528
 Buffer Descriptors | 19700992 | 18874368 | 18874368
 XLOG Ctl | 171008 | 16803472 | 16803584
 Backend Activity Buffer | 2707733248 | 10680320 | 10680320
...

NULL表示未使用的内存，anonymous表示匿名页的分配 pg_shmem_allocations视图的大部分内存模块都挺难理解的，直接搜源码也能找到，不过没有一个直观的解释，只是把源码相关init内存模块的数据展示出来。

示例buffer blocks：直接源码搜索“buffer blocks”：

//初始化shared buffer pool
//只调用一次，在shared memory初始化时
void
InitBufferPool(void)
{
	bool		foundBufs,
				foundDescs,
				foundIOCV,
				foundBufCkpt;

	/* Align descriptors to a cacheline boundary. */
	BufferDescriptors = (BufferDescPadded *)
		ShmemInitStruct("Buffer Descriptors",
						NBuffers * sizeof(BufferDescPadded),
						&foundDescs);

	BufferBlocks = (char *)
		ShmemInitStruct("Buffer Blocks",
						NBuffers * (Size) BLCKSZ, &foundBufs);

	/* Align condition variables to cacheline boundary. */
	BufferIOCVArray = (ConditionVariableMinimallyPadded *)
		ShmemInitStruct("Buffer IO Condition Variables",
						NBuffers * sizeof(ConditionVariableMinimallyPadded),
						&foundIOCV);

//Checkpoint BufferIds是用来在shared memory中排序checkpoint的
	CkptBufferIds = (CkptSortItem *)
		ShmemInitStruct("Checkpoint BufferIds",
						NBuffers * sizeof(CkptSortItem), &foundBufCkpt);
}

InitBufferPool()函数是初始化shared buffer的
shared buffer有4个子池：Buffer Descriptors，Buffer Blocks，Buffer IO Condition Variables，Checkpoint BufferIds

私有内存
#

私有内存是pg为每个session或进程分配的内存区域，它们通常不像shared buffer那样只有一个。每个进程的私有内存是不能相互访问的。

temp_buffers temp buffer用于缓存临时表数据，默认8m。temp_buffers是私有内存，所以临时表只能当前session可见。

work_mem 查询操作（query operation）所使用的最大内存，如排序、hash表，默认4m。 each query or each plan node？ 官方文档：

Note that a complex query might perform several sort and hash operations at the same time, with each operation generally being allowed to use as much memory as this value specifies before it starts to write data into temporary files.

关于/dev/shm的社区邮件：

Queries can use up to work_mem for each node you see in the
EXPLAIN plan,

该参数是针对查询中的每个operation(plan node)，而不是each query。一个query可以有很多并行的operation，所以一个查询也可能占用很多内存。所以work_mem的设置需要很谨慎，不能设置的过高导致操作系统内存被耗尽，如最坏的情况：多个会话、会话有多个plan node、plan node使用的大量消耗work mem的operation。 哪些operation会使用到work mem？： 对于sort操作有：ORDER BY、DISTINCT、merge joins；对于使用hash表有： hash joins、hash-based aggregation、memoize nodes、基于hash的in子查询

hash_mem_multiplier 用于限制基于hash-based operations的内存大小，限制是hash_mem_multiplier*work mem。hash_mem_multiplier默认为2。虽然可以限制work mem，但是无法限制query使用了多少个hash操作，所以pg13增加了这个参数。也就是说12（含）以前，是很难限制hash table的内存的。 我们在9.6的生产环境中找到消耗300G内存的一个会话，罪魁祸首就是低版本没有hash table限制和执行计划错误的使用hash table

maintenance_work_mem VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY等操作使用的内存区域，这些都是会话发起的操作，有独立的进程，使用私有内存。在一个会话中这些maintenance操作是不能并行的，而且一把并发量也不高，所以这个参数可以调整比较大。 autovacuum也可能用到这个内存区域和限制，参考autovacuum_work_mem解释

autovacuum_work_mem 每个autovacuum worker process使用的最大内存，默认-1，表示使用maintenance_work_mem参数来限制autovacuum worker。vacuum最多使用1GB的内存，autovacuum同样是这个限制，所以vacuum/autovacuumd的内存限制设置到超过1G没有意义。

vacuum_buffer_usage_limit 限制VACUUM、ANALYZE从共享内存中访问的page数，以防太多的page被evict。default为256kb，0表示没有限制。在使用VACUUM、ANALYZE命令时可指定BUFFER_USAGE_LIMIT，此时的设置优先级高于GUI参数vacuum_buffer_usage_limit

max_stack_depth 执行堆栈的最大安全深度，一般意味着单个backend进程上执行一个递归函数的堆栈深度。默认为2MB。操作系统kernel stack limit应设置的比这个max_stack_depth大一点。递归函数超过堆栈深度会报如下错误：

ERROR: stack depth limit exceeded HINT: 
Increase the configuration parameter max_stack_depth (currently 2048kB), 
after ensuring the platform’s stack depth limit is adequate.

logical_decoding_work_mem pg13以前，逻辑解析最多会在内存中保留4096条变更（max_changes_in_memory代码中写死）。pg13引入参数logical_decoding_work_mem，如果逻辑解析持有的数据大过这个内存值，会写入磁盘。默认64MB。

each replication connection only uses a single buffer of this size,

一般来说逻辑复制链路不会很多，所以logical_decoding_work_mem设置大一点也没有关系

xxCache
#

xxCache也是私有内存，例如pg会将relation的元数据缓存到relcache。在官方文档中相关描述比较少，但是PG的内存问题往往跟这个相关。例如catalog cache导致每个backend process都占用了很多内存而且不释放的问题，在许多环境中都出现了。这里是2016年德哥提的关于catalog cache占用较多内存的社区邮件

Every PostgreSQL session holds system data in own cache. Usually this cache is pretty small (for significant numbers of users). But can be pretty big if your catalog is untypically big and you touch almost all objects from
catalog in session. A implementation of this cache is simple - there is not
delete or limits. There is not garabage collector (and issue related to
GC), what is great, but the long sessions on big catalog can be problem.
The solution is simple - close session over some time or over some number of operations. Then all memory in caches will be released.

社区对于catalog cache解释：

每个会话都有自己的cache缓存系统数据（元数据等）
一般这个cache很小。当catalog很大且会话访问过所有catalog时，cache会变的很大
cache的管理很简单，没有删除机制和limit限制（其实有invalidation消息）
关闭会话会释放cache

Tom Lane大佬的解决方案也是简单粗暴——加硬件资源：

I do not think you should complain if that takes a great deal of memory.Either rethink why you need so many tables, or buy hardware commensurate with the size of your problem.

其实cache也有很多知识点需要关注，了解其原理后cache导致的内存问题解决办法可能不只是一种。 xxCache有很多种类，如relcache、syscache、plancache等等。由于资料比较少，理解xxcache只有翻看源码了。xxCache主要源码都在src/backend/utils/cache下。 源码结构:

inval.c				--私有cache的invalidation消息分发器。对应的share cache的invalidation消息处理为sinval.c
relfilenodemap.c	--relfilenode to oid mapping cache
ts_cache.c			--Tsearch（文本搜索）相关对象的cache
relmapper.c			--catalog to relfilenode mapping cache
typcache.c			--type cache
spccache.c			--tablespace cache
evtcache.c			--event trigger cache
attoptcache.c		--attribute cache
plancache.c			--plan cache 
relcache.c			--relation cache 							 							*本次重点*
catcache.c			--system catalog cache 					 					*本次重点*
syscache.c			--在catcache上一层，也是system catalog cache	 *本次重点*
lsyscache.c			--为了方便查询catalog cache的routines，l应该指lookup
partcache.c			--操作在relcache中的分区信息的routines

处理各类cache外，还包含一些操作、消息的源码。下面重点关注的是relcache、catcache/syscache和invalidation消息。

relcache
#

relcache条目数据保存了什么？ 在src/include/utils/rel.h中定义relcache的条目：

* POSTGRES relation descriptor (a/k/a relcache entry) definitions.

其中RelationData是relcache条目最主要的数据结构：

typedef struct RelationData
{
	RelFileNode rd_node;		/* relation的物理标识 */
	SMgrRelation rd_smgr;		/* 缓存的文件句柄，没有则为NULL, or NULL */
	int			rd_refcnt;		/* reference count */
	BackendId	rd_backend;		/* 如果是临时relation，它的所有者backend id */
	bool		rd_islocaltemp; /* 是不是当前会话的temp rel */
	bool		rd_isnailed;	/* 是否已经nail再cache中 */
	bool		rd_isvalid;		/* relcache条目是否有效 */
	bool		rd_indexvalid;	/* relation上的索引是否有效 */
	bool		rd_statvalid;	/* relation上的统计信息是否有效 */
...
	/* 一些子事务信息 */
	SubTransactionId rd_createSubid;	/* rel was created in current xact */
	SubTransactionId rd_newRelfilenodeSubid;	/* highest subxact changing rd_node to current value */
	SubTransactionId rd_firstRelfilenodeSubid;	/* highest subxact changing rd_node to any value */
	SubTransactionId rd_droppedSubid;	/* dropped with another Subid set */

	Form_pg_class rd_rel;		/* RELATION的在pg_class上的元组指针 */
	TupleDesc	rd_att;			/* 元组的描述信息 */
	Oid			rd_id;			/* relation的oid */
	LockInfoData rd_lockInfo;	/* relation上的锁信息 */
	RuleLock *rd_rules;		/* rewrite rules */
	MemoryContext rd_rulescxt;	/* rd_rules的私有memory cxt */
	TriggerDesc *trigdesc;		/* 触发器信息，rel上没有为NULL */
...
	/* 外键信息 */
	List	 *rd_fkeylist;	/* list of ForeignKeyCacheInfo (see below) */
	bool		rd_fkeyvalid;	/* true if list has been computed */
	/* 分区信息 */
	PartitionKey rd_partkey;	/* partition key, or NULL */
	MemoryContext rd_partkeycxt;	/* private context for rd_partkey, if any */
...
	List	 *rd_indexlist;	/* 所有索引的OID列表 */
	Oid			rd_pkindex;		/* 主键的oid */
	Oid			rd_replidindex; /* replica identity index的oid */

	List	 *rd_statlist;	/* extended stats的oid列表 */
...

	PublicationDesc *rd_pubdesc;	/* publication descriptor, or NULL */
...
	bytea	 *rd_options;		/* parsed pg_class.reloptions */
...
	Form_pg_index rd_index;		/* 索引在pg_index元组的描述 */
	struct HeapTupleData *rd_indextuple;	/* 所有pg_index元组 */
	MemoryContext rd_indexcxt;	/* index的cxt */
...
	void	 *rd_amcache;		/* available for use by index/table AM */
...
	struct FdwRoutine *rd_fdwroutine;	/* cached function pointers, or NULL */

...
} RelationData;

RelationData包含了非常多的relation相关的元数据：oid、pg_class、分区表、子事务、行安全策略、统计信息、索引元数据、am等等。

relcache的ROUTINES ROUTINES源码位于src/backend/utils/cache/relcache.c 主要有5个阶段

RelationCacheInitialize - 初始化relcache，初始化为空的
RelationCacheInitializePhase2 - 初始化共享的catalog
RelationCacheInitializePhase3 - 完成初始化relcache
RelationIdGetRelation - 通过relation id获得rel描述
RelationClose - 关闭一个relation

这5个阶段是relcache中的5个主要逻辑，相当于一个rel entry的生命周期，而不是relcache的生命周期。前三个阶段都是relcache的初始化，他们会初始化relcache，加载一些系统表和其索引；后两个阶段是获得reldesc的逻辑和关闭relation的逻辑，relcache本身还是存在的。

第一阶段：RelationCacheInitialize RelationCacheInitialize 初始化relcache：

//定义初始大小400
#define INITRELCACHESIZE		400

void
RelationCacheInitialize(void)
{
	HASHCTL		ctl;
	int			allocsize;

	/*
	 * make sure cache memory context exists
	 */
	 //检查是否有cache mctx，没有则创建一个
	if (!CacheMemoryContext)
		CreateCacheMemoryContext();

	 //创建索引到relcache的哈希表
	ctl.keysize = sizeof(Oid);
	ctl.entrysize = sizeof(RelIdCacheEnt);
	RelationIdCache = hash_create("Relcache by OID", INITRELCACHESIZE,
								 &ctl, HASH_ELEM | HASH_BLOBS);
...
	// 初始化relation mapper
	RelationMapInitialize();
}

RelationCacheInitialize没有分配任何rel的操作，只是对relcache做初始化内存、hash表、mapper等

第二阶段：RelationCacheInitializePhase2

void
RelationCacheInitializePhase2(void)
{
	MemoryContext oldcxt;
	
	//初始化 relation mapper
	RelationMapInitializePhase2();

	//如果是bootstrap模式，共享catalog还不存在，所以可以什么也不做
	if (IsBootstrapProcessingMode())
		return;

	 //switch到当前的cache mctx
	oldcxt = MemoryContextSwitchTo(CacheMemoryContext);

	 //尝试加载共享的relcache file
	if (!load_relcache_init_file(true))//如果没有加载初始化文件
	{
		formrdesc("pg_database", DatabaseRelation_Rowtype_Id, true,
				 Natts_pg_database, Desc_pg_database);
		formrdesc("pg_authid", AuthIdRelation_Rowtype_Id, true,
				 Natts_pg_authid, Desc_pg_authid);
		formrdesc("pg_auth_members", AuthMemRelation_Rowtype_Id, true,
				 Natts_pg_auth_members, Desc_pg_auth_members);
		formrdesc("pg_shseclabel", SharedSecLabelRelation_Rowtype_Id, true,
				 Natts_pg_shseclabel, Desc_pg_shseclabel);
		formrdesc("pg_subscription", SubscriptionRelation_Rowtype_Id, true,
				 Natts_pg_subscription, Desc_pg_subscription);

#define NUM_CRITICAL_SHARED_RELS	5	/* fix if you change list above */
	}

	MemoryContextSwitchTo(oldcxt);
}

init file分为了shared 和local cache init file，load_relcache_init_file()就是尝试从这两种文件中load数据到relcache中（这里应该只加载共享的）。如果load失败，则创建pg_database、pg_authid等5个基本的系统表的描述信息。

第三阶段： RelationCacheInitializePhase3初始化的第三阶段，内容也是最多的：

void
RelationCacheInitializePhase3(void)
{
	HASH_SEQ_STATUS status;
	RelIdCacheEnt *idhentry;
	MemoryContext oldcxt;
	bool		needNewCacheFile = !criticalSharedRelcachesBuilt;

	RelationMapInitializePhase3();

	//切换到CacheMemoryContext
	oldcxt = MemoryContextSwitchTo(CacheMemoryContext);

	//跟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);

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

	MemoryContextSwitchTo(oldcxt);
...
	//如果我们还没有获得关键的系统索引，现在就做 
	//因为catcache and/or opclass cache依赖relcache中的关键系统索引
	if (!criticalRelcachesBuilt)//如果未load关键索引
	{
		load_critical_index(ClassOidIndexId,
							RelationRelationId);
...
		load_critical_index(TriggerRelidNameIndexId,
							TriggerRelationId);

#define NUM_CRITICAL_LOCAL_INDEXES	7	/* fix if you change list above */

		criticalRelcachesBuilt = true; //打个标记，关键系统表索引已获得
	}

	//继续处理共享的关键系统表索引。这些共享关键系统表在某些情况（autovacuum、客户端认证等）下需要
	if (!criticalSharedRelcachesBuilt)
	{
		load_critical_index(DatabaseNameIndexId,
							DatabaseRelationId);
...
		load_critical_index(SharedSecLabelObjectIndexId,
							SharedSecLabelRelationId);

#define NUM_CRITICAL_SHARED_INDEXES 6	/* fix if you change list above */

		criticalSharedRelcachesBuilt = true;//打个标记，共享关键系统表索引已获得
	}

	 //扫描relcache中的所有条目并更新那些在formrdesc 或init file中有错误的
	 //如果有错误，读pg_class数据然后替换错误条目
	 //因为cache file中没有rule、trigger、安全策略，同时也从pg_class中获取
...
	while ((idhentry = (RelIdCacheEnt *) hash_seq_search(&status)) != NULL)
	{
		Relation	relation = idhentry->reldesc;
		bool		restart = false;


		//确保正在使用的relation不要flush
		RelationIncrementReferenceCount(relation);

		 //如果是错误的条目，从pg_class中读元组
		if (relation->rd_rel->relowner == InvalidOid)
		{
		...
			memcpy((char *) relation->rd_rel, (char *) relp, CLASS_TUPLE_SIZE);

			//更新rd_option
			if (relation->rd_options)
				pfree(relation->rd_options);
			RelationParseRelOptions(relation, htup);
...
			ReleaseSysCache(htup);
...
			restart = true;
		}

		//修复那些不在init file中的数据
		//例如relhasrules、relhastriggers可能已经过时或错误了
		if (relation->rd_rel->relhasrules && relation->rd_rules == NULL)
		{
			RelationBuildRuleLock(relation);
			if (relation->rd_rules == NULL)
				relation->rd_rel->relhasrules = false;
			restart = true;
		}
		if (relation->rd_rel->relhastriggers && relation->trigdesc == NULL)
		{
			RelationBuildTriggers(relation);
			if (relation->trigdesc == NULL)
				relation->rd_rel->relhastriggers = false;
			restart = true;
		}

		 //reload行安全策略，因为init文件里没有
		if (relation->rd_rel->relrowsecurity && relation->rd_rsdesc == NULL)
		{
			RelationBuildRowSecurity(relation);

			Assert(relation->rd_rsdesc != NULL);
			restart = true;
		}

		//如果需要reload tableam
		if (relation->rd_tableam == NULL &&
			(RELKIND_HAS_TABLE_AM(relation->rd_rel->relkind) || relation->rd_rel->relkind == RELKIND_SEQUENCE))
		{
			RelationInitTableAccessMethod(relation);
			Assert(relation->rd_tableam != NULL);

			restart = true;
		}

		//持有数计数-1
		RelationDecrementReferenceCount(relation);

...
	//最后，如果需要，更新init file（毕竟可能有reload，别浪费了）
	if (needNewCacheFile)
	{
		InitCatalogCachePhase2();

		/* now write the files */
		write_relcache_init_file(true); //写global init file
		write_relcache_init_file(false); //写private init file
	}
}

RelationCacheInitializePhase3()相比于2阶段加载的5个系统表，加载了更多的系统表，比如pg_class、pg_proc等，以及加载这些表上的索引。当然这些rel加载的前提是cache中没有或者已过期。reload完成后，再把“新”的catalog写入到init file中。最后写入init file时，看下对应的write_relcache_init_file函数源码，便可以知道传入参数true和false的含义：

static void
write_relcache_init_file(bool shared)
{
···
	if (shared)
	{
		snprintf(tempfilename, sizeof(tempfilename), "global/%s.%d",
				 RELCACHE_INIT_FILENAME, MyProcPid);
		snprintf(finalfilename, sizeof(finalfilename), "global/%s",
				 RELCACHE_INIT_FILENAME);
	}
	else
	{
		snprintf(tempfilename, sizeof(tempfilename), "%s/%s.%d",
				 DatabasePath, RELCACHE_INIT_FILENAME, MyProcPid);
		snprintf(finalfilename, sizeof(finalfilename), "%s/%s",
				 DatabasePath, RELCACHE_INIT_FILENAME);
	}
...
}

true表示写入到global init file false表示写入到local init file

其中RELCACHE_INIT_FILENAME参数宏定义：

#define RELCACHE_INIT_FILENAME "pg_internal.init"

so，写入的init file为：

shared：global/pg_internal.init
local：DatabasePath/pg_internal.init 和 DatabasePath/pg_internal.init.myPID

我们看下真实的init文件路径：

[postgres]$ find ./ -name *init*
./global/pg_internal.init #shared
./base/1/pg_internal.init #local
./base/13577/pg_internal.init #local
./base/13578/pg_internal.init	#local
./base/16398/pg_internal.init	#local
./base/16811/pg_internal.init	#local
./base/17674/pg_internal.init	#local

初始化三阶段的调用示意图：（https://blog.japinli.top/2022/07/postgres-relcache-and-syscache/）

第四阶段：RelationIdGetRelation 通过OID找到reldesc。caller只需要拿到OID 的AccessShareLock，也要自己加减rel的持有数。

Relation
RelationIdGetRelation(Oid relationId)
{
	Relation	rd;

	//确保在事务里
	Assert(IsTransactionState());

	//首次尝试在reldesc中找到cache
	RelationIdCacheLookup(relationId, rd);

	if (RelationIsValid(rd))
	{
		//已删除的relation返回null
		if (rd->rd_droppedSubid != InvalidSubTransactionId)
		{
			Assert(!rd->rd_isvalid);
			return NULL;
		}

		RelationIncrementReferenceCount(rd);
		if (!rd->rd_isvalid)//如果cache中的rel是无效的，重新让他有效
		{
			if (rd->rd_rel->relkind == RELKIND_INDEX ||
				rd->rd_rel->relkind == RELKIND_PARTITIONED_INDEX) //索引信息直接加载
				RelationReloadIndexInfo(rd);
			else //如果是非索引，则清理reldesc
				RelationClearRelation(rd, true);
...
		}
		return rd;
	}

	//没有reldesc了，新建一个reldesc 
	rd = RelationBuildDesc(relationId, true);
	if (RelationIsValid(rd))
		RelationIncrementReferenceCount(rd);
	return rd;
}

RelationIdGetRelation 比较简单，就是通过OID拿到reldesc和索引信息

第五阶段：RelationClose RelationClose的代码也比较简单：

void
RelationClose(Relation relation)
{
	//不需要锁的操作，直接简单的refcount-1
	RelationDecrementReferenceCount(relation);

	 //如果没有会话打开relation，可以删除分区描述信息（partition descriptors）
	if (RelationHasReferenceCountZero(relation))
	{
		if (relation->rd_pdcxt != NULL &&
			relation->rd_pdcxt->firstchild != NULL)
			MemoryContextDeleteChildren(relation->rd_pdcxt);

		if (relation->rd_pddcxt != NULL &&
			relation->rd_pddcxt->firstchild != NULL)
			MemoryContextDeleteChildren(relation->rd_pddcxt);
	}

#ifdef RELCACHE_FORCE_RELEASE
	if (RelationHasReferenceCountZero(relation) &&
		relation->rd_createSubid == InvalidSubTransactionId &&
		relation->rd_firstRelfilenodeSubid == InvalidSubTransactionId)
		RelationClearRelation(relation, false);
#endif
}

RelationClose 是对关闭访问relation的操作，一般来说这个函数只会将访问relation的会话数refcount减少。但是也有例外情况：

当refcount为0时，会执行MemoryContextDeleteChildren()，这个MemoryContextDeleteChildren()函数，将删除其子分区描述相关的mctx，这个是会释放内存的。
当refcount为0且有标记宏定义DRELCACHE_FORCE_RELEASE时，使用RelationClearRelation()函数删除hash表的entry，这一步不会释放内存。这个DRELCACHE_FORCE_RELEASE宏没有找到（只有显示编译才会有？）。

relcache也不是完全没有释放内存的逻辑，不过触发条件比较苛刻，且删除的内存也不是relcache中的所有内存。

syscache/catcache
#

CatCache缓存的是系统表中的Tuple，基于CatCache基础之上还有一层SysCache（KV接口），本质上可以认为CatCache和SysCache一起把系统表中的数据在内存中按照KV方式重新组织。 syscache/catcache要更复杂一点，这里简单提炼一点容易解读的内容，主要是为了了解syscache的缓存内容和load机制。进一步的源码解读可参阅postgreSQL源码分析——存储管理——内存管理（3）和 PostgreSQL RelCache 和 SysCache 缓存

catcache结构体

typedef struct catcache
{
	int			id;				//cache id,id定义在syscache.h中
	int			cc_nbuckets;	//这个cache的hash桶个数
	TupleDesc	cc_tupdesc;		//元组描述，由reldesc拷贝而来
...
	const char *cc_relname;		//元组对应的系统表名
	Oid			cc_reloid;		//系统表的OID
	Oid			cc_indexoid;	//cache key的索引OID
	bool		cc_relisshared; //表是否跨db共享？
...
	//catcache使用的统计信息
#ifdef CATCACHE_STATS
	long		cc_searches;	//查询该catcache的次数
	long		cc_hits;		//命中次数
	long		cc_neg_hits;	//negative entry的命中次数
...
#endif
} CatCache;

catcache条目

typedef struct catctup
{
	int			ct_magic;		//标识catctup条目
#define CT_MAGIC 0x57261502

	uint32		hash_value;		//这个tuple的hash键值
...

	//不会返回死元组，但是在refcount变成零时，会从catcache中删除
	int			refcount;		//元组的refcount，标志是否有访问
	bool		dead;			//死元组，但是还没有清理
	bool		negative;		//是否是negative cache entry? 
	HeapTupleData tuple;		//元组头结构

...
	CatCache *my_cache;		//链接到该元组所属的catcache
} CatCTup;

SearchCatCacheMiss()函数 SearchCatCacheMiss()是catcache hit miss的主要函数,并且在miss后会产生访问字典中的元组

static pg_noinline HeapTuple
SearchCatCacheMiss(CatCache *cache,
				 int nkeys,
				 uint32 hashValue,
				 Index hashIndex,
				 Datum v1,
				 Datum v2,
				 Datum v3,
				 Datum v4)
{
	ScanKeyData cur_skey[CATCACHE_MAXKEYS];
	Relation	relation;
	SysScanDesc scandesc;
	HeapTuple	ntp;
	CatCTup *ct;
	Datum		arguments[CATCACHE_MAXKEYS];

...
	
	//cache中未找到元组,所以需要尝试直接从表中找
	//找到就加到cache中
	//没有找到就加一个negative cache条目
	relation = table_open(cache->cc_reloid, AccessShareLock);

	scandesc = systable_beginscan(relation,
								 cache->cc_indexoid,
								 IndexScanOK(cache, cur_skey),
								 NULL,
								 nkeys,
								 cur_skey);

	ct = NULL;
	//元组有效时,创建一个条目
	while (HeapTupleIsValid(ntp = systable_getnext(scandesc)))
	{
		ct = CatalogCacheCreateEntry(cache, ntp, arguments,
									 hashValue, hashIndex,
									 false); //创建一个条目
		//refcount立即+1
		ResourceOwnerEnlargeCatCacheRefs(CurrentResourceOwner);
		ct->refcount++;
		ResourceOwnerRememberCatCacheRef(CurrentResourceOwner, &ct->tuple);
		break;					/* assume only one match */
	}

	systable_endscan(scandesc);

	table_close(relation, AccessShareLock);

	/*
	//如果没有找到元组,需要创建一个negative cache条目,相当于假元组
	//假元组有key column,其余都是null的
	//,因为在启动阶段invalidation机制未激活且在元组真的在稍后创建后无法清理他们
	//所以这个阶段,不会创建negative条目
	if (ct == NULL) //如果没有找到元组,进入以下逻辑
	{
		if (IsBootstrapProcessingMode()) //如果是启动阶段直接返回NULL
			return NULL;

		ct = CatalogCacheCreateEntry(cache, NULL, arguments,
									 hashValue, hashIndex,
									 true); //创建条目

		CACHE_elog(DEBUG2, "SearchCatCache(%s): Contains %d/%d tuples",
				 cache->cc_relname, cache->cc_ntup, CacheHdr->ch_ntup);
		CACHE_elog(DEBUG2, "SearchCatCache(%s): put neg entry in bucket %d",
				 cache->cc_relname, hashIndex);

		//negative条目不返回给caller,refcount也是0
		return NULL;
	}
...
	return &ct->tuple;
}

这里的假元组negative cache entry很精彩，将一个不存在的元组缓存在catcache中，下次再发生访问就不需要再到数据字典中找元组了，避免了无意义的多次查数据字典。

cache validation消息
#

当元组发生update或delete后，由于事务可见性规则，这些在事务结束后不可见的元组需要被告知给cache，使cache中的元组invalidated，在下次读取时再load。同样，因为insert而产生新元组时,cache中的negative cache entry也可能需要flush出去以匹配新元组。其中一个比较常见的常见是DDL，DDL可能导致元数据中的某些tuple失效，此时就需要发送cache validation给各个私有cache让他们清理cache条目。这个cache validation机制适用于syscache、relcache等私有cache池的管理。由于idle的backend不会读sinval events,所以需要主动send消息让lag backend能“catch up”。当完成事务时，必须要将invalidation events通过SI message queue广播给其他backends。

源码分为两块，sinval和inval

Invalidation interface: src/include/utils/inval.h
Invalidation dispatch: src/backend/utils/cache/inval.c
Invalidation message sharing interface: src/include/storage/sinval.h
Invalidation message sharing dispatch: src/backend/storage/ipc/sinval.c
Invalidation message sharing data structures interface: src/include/storage/sinvaladt.h
Invalidation message sharing data structures: src/backend/storage/ipc/sinvaladt.c

在src/backend/utils/cache/inval.c中包含shared-invalidation消息结构体：

typedef union
{
	int8		id;				/* type field --- must be first */
	SharedInvalCatcacheMsg cc;
	SharedInvalCatalogMsg cat;
	SharedInvalRelcacheMsg rc;
	SharedInvalSmgrMsg sm;
	SharedInvalRelmapMsg rm;
	SharedInvalSnapshotMsg sn;
} SharedInvalidationMessage;

shared-invalidation消息包含如下种类：

使指定catcache条目失效
使某个系统catalog的整个catcache条目失效
使指定relcache条目失效
使所有relcache条目失效
使某个对应物理relation的smgr的cache条目失效
使 mapped-relation 失效
使扫描过relation的保存了的快照失效

消息位于共享内存队列中，直到所有其他进程读取它们。通常，接收进程仅在特定时间读取消息，因此，如果接收进程处于空闲状态（即不处理任何用户请求）或忙于执行其他操作，以至于它们没有时间读取这些消息，则消息可能会无限期地继续留在共享内存中。在不幸的情况下，如果此共享内存空间不再可用于进程来存储新消息，则该进程将不得不承担清理任务。（实际上，这种清理是主动完成的，因此很少会用完空间）若要丢弃旧消息，必须确保所有其他进程都已读取它们。如果某些进程由于上述原因无法做到这一点，它必须明确地向滞后的进程发送信号，要求它们赶上。一旦滞后进程赶上来，就可以随意丢弃这些消息。处理消息时，首先检查消息中指定的目录元组当前是否在缓存中（消息中还指定了 syscache 标识），如果是，则将其从缓存的哈希表中删除。下次请求该元组时，将从基础目录表中重新读取该元组并将其添加到哈希表中，因此后续访问将读取新值。如果进程已锁定特定数据库对象，阻止并发进程再修改它，则它可以继续使用缓存的元组，直到释放锁定。

xxCache的问题小结
#

xxCache有许多种类，其中比较著名的有plancache、relcache、syscache。这些cache属于私有内存，存在于每个backend进程中。这些cache没有lru机制来淘汰过期的数据，他们通过invalidation消息清理全局都不需要的快照、元数据信息，比如对象被删除了的时候。

relcache是最有可能占用较多内存的地方，relcache会加载元数据信息，初始化过程中会读取*.init文件以加快加载元数据到relcache中。后续在需要读取到其他元数据时，也会进行加载。
catcache缓存数据字典的元组信息，syscache是基于catcache上一层的，可理解为他俩一起实现这个数据字段缓存。如果元组不存在，则会生成一个negative条目，以访下次访问还要访问数据字典。同样的，catcache miss也会去读数据字典中的元组。
cache validation消息是为了告知cache中缓存的元组、快照信息已经过久，它可以使对应的relcache、catcache条目失效。条目会从从缓存的哈希表中删除，这一步会释放内存。

由于cache的内存释放机制很少，当元数据较多的时候（很多的表、分区表），relcache、catcache可能会占用很多内存，而且是每个backend多有可能这样。 可能的解决办法：

global cache。像oracle的dictionary cache那样，缓存在一个地方，共享访问。如PolarDB的Global RelCache已实现此功能
LRU。需要适合cache的LRU机制将冷热端分离，过旧的cache条目从hash table中清理即可。此时可能需要cache limit参数限制cache的大小，最好每个cache来一个···
线程模式。内存对于线程来说都共享的访问的，天然的优势
定期断开长连接。以上都是空了吹。
不要建太多的表、分区（注意pg中分区表的分区也是表）

memory contexts
#

PostgresSQL通过memory context机制来管理内存。之前有做过一篇memory contexts的译文，大致总结如下：

C语言必须显示释放内存，为了减少内存泄漏的风险，PostgreSQL实现了memory contexts来管理私有内存
memory contexts不需要每次用完都释放内存，而是通过删除某个context来实现内存释放
memory contexts是一个层级结构，父级context的释放会递归删除所有子contexts
除了调试之外，memory contexts的内存使用情况是比较难观察的。pg14开始有pg_backend_memory_contexts视图可以观察当前会话的当前memory_context使用情况

SQL操作产生memory context的时机：

（https://www.pgcon.org/2019/schedule/attachments/514_introduction-memory-contexts.pdf)

源码分析
#

在 PostgreSQL 中，所有内存的申请、释放和重置都是在内存上下文中进行的，因此不会直接使用 malloc()、realloc() 和 free() 系统调用函数，而是使用 palloc()、repalloc() 和 pfree() 来实现内存的分配、重分配和释放。

C库的内存函数 C库动态内存分配函数有如下几个：

malloc()：C库的malloc()函数（memory allocation）用于分配大块内存
calloc()：C库的calloc()函数（contiguous allocation）用于分配连续内存
free()：用于释放内存。malloc()，calloc()不会释放内存，动态分配内存后都需要用free()释放内存
realloc()：用于重新分配内存（re-allocation）

另外还有一个C库函数memset()，用来给内存块填充具体的值。

pg代码定义的内存函数 真正被PostgreSQL源码大量调用的内存申请、释放等函数是palloc()、palloc0()，repalloc()，pfree()。他们大部分情况下不会直接跟操作系统内存（C库函数）交互，只有某些情况下会调用C库内存函数。相当于对操作系统内存操作做了一层保护，对于小内存的操作由pg自己完成。 palloc(): palloc()主要是调用MemoryContext的方法alloc。alloc是对MemoryContextAlloc函数的调用，而MemoryContextAlloc函数实际上是调用了当前内存上下文的methods字段中所指定的AllocSetAlloc函数

void *
palloc(Size size)
{
	/* duplicates MemoryContextAlloc to avoid increased overhead */
	void	 *ret;
	MemoryContext context = CurrentMemoryContext;
...
	ret = context->methods->alloc(context, size);
....
	return ret;
}

palloc0()：

void *
palloc0(Size size)
{
...
	ret = context->methods->alloc(context, size);
...
	MemSetAligned(ret, 0, size);

	return ret;
}

MemSetAligned是宏定义的，实际上就是调用C库的memset做内存填充，不过MemSetAligned传入的value是0

#define MemSetAligned(start, val, len)\
...\
	memset(_start, _val, _len); \
...	

palloc0相对pallo，除了都调用alloc(context, size)，palloc0还会把内存的内容置0。

repalloc(): realloc()主要是调用MemoryContext的方法realloc，realloc函数指针对应于AllocSetRealloc函数

/*
 * repalloc
 *		Adjust the size of a previously allocated chunk.
 */
void *
repalloc(void *pointer, Size size)
{
	MemoryContext context = GetMemoryChunkContext(pointer);
...
	ret = context->methods->realloc(context, pointer, size);
...
	return ret;
}

pfree(): pfree将调用内存片所属的内存上下文的methods字段中的free_p函数指针来释放内存片的空间。目前，PG中free_p指针实际指向AllocSetFree函数

/*
 * pfree
 *		Release an allocated chunk.
 */
void
pfree(void *pointer)
{
	MemoryContext context = GetMemoryChunkContext(pointer);

	context->methods->free_p(context, pointer);
	VALGRIND_MEMPOOL_FREE(context, pointer);
}

AllocSetAlloc分配内存 查看其中的alloc方法，alloc最终指向AllocSetAlloc函数。AllocSetAlloc看上去比较复杂，分段看的话比较好理解：

static void *
AllocSetAlloc(MemoryContext context, Size size)
{
	AllocSet	set = (AllocSet) context;
	AllocBlock	block;
	AllocChunk	chunk;
	int			fidx;
	Size		chunk_size;
	Size		blksize;
...

	//如果申请的内存大小超过chunk的最大值，分配整个内存block
	if (size > set->allocChunkLimit)
	{
...
		block = (AllocBlock) malloc(blksize);
...
	}

	//如果申请的内存大小小于chunk，从free list中找是否有free chunk可以使用
	fidx = AllocSetFreeIndex(size);
	chunk = set->freelist[fidx];
	if (chunk != NULL) //freelist中有chunk可以使用
	{
		Assert(chunk->size >= size);

		set->freelist[fidx] = (AllocChunk) chunk->aset;

		chunk->aset = (void *) set;
...
		return AllocChunkGetPointer(chunk);
	}

...
	 //如果有空间，尝试把chunk放到allocation block，如果没有，需要新建一个block
	if ((block = set->blocks) != NULL)
	{
		Size		availspace = block->endptr - block->freeptr;

		if (availspace < (chunk_size + ALLOC_CHUNKHDRSZ))
		{
...
			block = NULL;
		}
	}
	//没有空间，创建新block
	if (block == NULL)
	{
		Size		required_size;

...
		//申请的block大小为2的冥，不超过 maxBlockSize
		required_size = chunk_size + ALLOC_BLOCKHDRSZ + ALLOC_CHUNKHDRSZ;
		while (blksize < required_size)
			blksize <<= 1;

		//使用malloc分配块，size为2的冥
		block = (AllocBlock) malloc(blksize);

...
}

（https://smartkeyerror.com/PostgreSQL-MemoryContext）

palloc()=>AllocSetAlloc()只有在申请的内存超过chunk大小限制或者freelist中没有空闲block的时候，才会调用malloc()去向操作系统申请内存；其余情况都是在freelist中拿已有的free chunk。

pfree()也是类似的（不示例了）： pfree()=>AllocSetFree()释放一个内存上下文中指定的内存片，如果指定要释放的内存片是内存块中唯一的一个内存片，则将调用free()直接释放该内存块。否则，将指定的内存片加入到Freelist链表中以便下次分配

查看mcxt内存大小
#

pg14+：pg_backend_memory_contexts 视图直接在库内查看mcxt内存

lzldb=> SELECT * FROM pg_backend_memory_contexts ORDER BY used_bytes DESC LIMIT 5;
 name | ident | parent | level | total_bytes | total_nblocks | free_bytes | free_chunks | used_bytes 
-------------------------+-------+------------------+-------+-------------+---------------+------------+-------------+------------
 CacheMemoryContext | | TopMemoryContext | 1 | 1048576 | 8 | 508216 | 1 | 540360
 Timezones | | TopMemoryContext | 1 | 104120 | 2 | 2616 | 0 | 101504
 TopMemoryContext | | | 0 | 97680 | 5 | 12904 | 7 | 84776
 ExecutorState | | PortalContext | 3 | 49208 | 4 | 4424 | 3 | 44784
 WAL record construction | | TopMemoryContext | 1 | 49768 | 2 | 6360 | 0 | 43408

pg14+：pg_log_backend_memory_contexts函数输出内存信息到log文件，输出类似MemoryContextStats(TopMemoryContext)的log输出

SELECT pg_log_backend_memory_contexts(9293);

通用-gdb MemoryContextStats(TopMemoryContext)

gdb调用MemoryContextStats(TopMemoryContext)：

gdb 
(gdb) attach 9293
(gdb) p MemoryContextStats(TopMemoryContext)
$2 = void

log输出：

TopMemoryContext: 97680 total in 5 blocks; 16856 free (16 chunks); 80824 used
 TableSpace cache: 8192 total in 1 blocks; 2088 free (0 chunks); 6104 used
 RowDescriptionContext: 8192 total in 1 blocks; 6888 free (0 chunks); 1304 used
 MessageContext: 8192 total in 1 blocks; 6888 free (1 chunks); 1304 used
 Operator class cache: 8192 total in 1 blocks; 552 free (0 chunks); 7640 used
...
 Relcache by OID: 16384 total in 2 blocks; 3504 free (2 chunks); 12880 used
 CacheMemoryContext: 524288 total in 7 blocks; 90840 free (0 chunks); 433448 used
 index info: 2048 total in 2 blocks; 904 free (0 chunks); 1144 used: pg_statistic_ext_relid_index
...
 index info: 2048 total in 2 blocks; 824 free (0 chunks); 1224 used: pg_database_oid_index
 index info: 2048 total in 2 blocks; 824 free (0 chunks); 1224 used: pg_authid_rolname_index
 WAL record construction: 49768 total in 2 blocks; 6360 free (0 chunks); 43408 used
 PrivateRefCount: 8192 total in 1 blocks; 2616 free (0 chunks); 5576 used
 MdSmgr: 8192 total in 1 blocks; 7592 free (0 chunks); 600 used
 LOCALLOCK hash: 8192 total in 1 blocks; 552 free (0 chunks); 7640 used
 Timezones: 104120 total in 2 blocks; 2616 free (0 chunks); 101504 used
 ErrorContext: 8192 total in 1 blocks; 7928 free (3 chunks); 264 used

小结
#

references
#

src/backend/utils/mmgr/mcxt.c

src/backend/utils/mmgr/README

https://momjian.us/main/writings/pgsql/inside_shmem.pdf

https://www.interdb.jp/pg/pgsql02.html

https://www.postgresql.org/docs/current/runtime-config-resource.htm

https://www.postgresql.org/docs/16/kernel-resources.html

https://blog.csdn.net/weixin_45644897/article/details/121340327

https://help.aliyun.com/zh/polardb/polardb-for-postgresql/global-cache

https://www.cnblogs.com/feishujun/p/PostgreSQLSourceAnalysis_cache02.html

https://blog.japinli.top/2022/07/postgres-relcache-and-syscache/

https://amitlan.com/2019/06/14/caches-inval.html

https://www.cybertec-postgresql.com/en/memory-context-for-postgresql-memory-management/

https://www.geeksforgeeks.org/dynamic-memory-allocation-in-c-using-malloc-calloc-free-and-realloc/

https://www.cnblogs.com/feishujun/p/PostgreSQLSourceAnalysis_mmgr01.html

https://www.cnblogs.com/feishujun/p/PostgreSQLSourceAnalysis_mmgr02.html

https://smartkeyerror.com/PostgreSQL-MemoryContext

https://jnidzwetzki.github.io/2022/05/28/postgres-memory-context.html

https://www.pgcon.org/2019/schedule/attachments/514_introduction-memory-contexts.pdf

PostgreSQL事务浅析

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

PG的事务

为了保证事务的ACID特性，rdbms必须要实现并发控制。pg和oracle、mysql(innodb)数据库都使用MVCC来实现并发控制。MVCC通过数据变化时不断生成新版本对象和可查询一定范围的老版本对象来实现并发，MVCC保存数据在某个时间点的快照，读数时选择一个版本进行读取。

oracle、mysql都通过undo来记录老版本对象，pg没有undo，而是在DML时在直接将历史数据写在原表上（update会创建新行，delete标记行），并在表中记录额外的列xmin,xmax来记录事务号，通过对比事务号和一些其他信息来实现mvcc机制。

在众多关系型数据库中，pg的事务机制非常有特色，了解pg的事务机制是了解pg数据库运行原理的关键。

事务隔离级别
#

一般关系型数据库都可以设置多个不同的事务隔离级别。在不步的事务隔离级别下，事务并发行为有所不同

设置事务隔离级别
#

pg支持设置4种事务隔离级别（实际上只会生效有3个）

{ SERIALIZABLE | REPEATABLE READ | READ COMMITTED | READ UNCOMMITTED }

事务隔离级别参数

default_transaction_isolation：设置全局事务的默认隔离级别

transaction_isolation:设置当前会话的事务隔离级别

默认隔离级别read committed

修改全局事务的默认隔离级别

直接修改default_transaction_isolation参数，然后reload即可

修改完成后，每个新的事物都会使用default_transaction_isolation隔离级别

postgres=# alter system set default_transaction_isolation to 'serializable';
ALTER SYSTEM
postgres=# select pg_reload_conf();
 pg_reload_conf 
----------------
 t
 (1 row)
 postgres=# show transaction_isolation;
 transaction_isolation 
-----------------------
 serializable

设置当前会话的隔离级别

注意参数transaction_isolation只是展示当前会话的隔离级别，这个参数是不可以直接修改的

lzldb=# alter system set transaction_isolation to 'REPEATABLE READ';
ERROR: parameter "transaction_isolation" cannot be changed

通过SET SESSION修改会话的隔离级别，例如：

lzldb=# SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SET
lzldb=# show transaction_isolation ;
-[ RECORD 1 ]---------+----------------
transaction_isolation | repeatable read

设置事务的隔离级别

pg可以指定事务本身的隔离级别

可通过在开启事务时设置事务的隔离级别，例如：

lzldb=# BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN
lzldb=# start TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION

或者开启事务后set transaction

lzldb=# begin;
BEGIN
lzldb=*# set transaction ISOLATION LEVEL REPEATABLE READ;
SET

ANSI92的事务隔离级别
#

在ANSI SQL-92事务隔离级别标准中包含4种隔离级别：

Serializable(可串行化或称可序列号)

系统中所有的事务串行化执行，事务之间互不影响。

以串行地方式逐个执行，能避免所有数据不一致情况。

早期以排他锁来控制并发事务，串行化执行方式会导致事务排队，系统的并发量大幅下，不过ANSI 92后出现更多序列化实现方法，并发性和性能均有较大提升。

Repeatable read(可重复读)

一个事务一旦开始，事务过程中所读取的所有数据不允许被其他事务修改。可重复读是mysql的默认隔离级别。

注意，在ANSI SQL中可重复读级别可发生幻读，但是pg的可重复读不会发生幻读

Read Committed(已提交读)

一个事务能读取到其他事务提交过的数据。

事务在处理过程中如果重复读取某一个数据，而且这个数据恰好被其他事务修改并提交了，那么当前重复读取数据的事务就会出现同一个数据前后不同的情况。已提交读是oracle、pg的默认隔离级别

在这个隔离级别会发生“不可重复读”和”幻读“的场景。

Read Uncommitted(未提交读)

一个事务能读取到其他事务修改过，但是还没有提交的(Uncommitted)的数据。

数据被其他事务修改过，但还没有提交，就存在着回滚的可能性，这时候读取这些“未提交” 数据的情况就是“脏读”。

在这个隔离级别会发生“脏读”场景。

pg没有未提交读这个隔离级别，设置未提交读会被当做已提交读

标准的一致性读和隔离级别矩阵

事务隔离级别	脏读	不可重复读	幻影读
未提交读	可能	可能	可能
已提交读	不可能	可能	可能
可重复读	不可能	不可能	可能
序列化	不可能	不可能	不可能

pg的一致性度和隔离级别矩阵

事务隔离级别	脏读	不可重复读	幻影读
未提交读	不可能	可能	可能
已提交读	不可能	可能	可能
可重复读	不可能	不可能	不可能
序列化	不可能	不可能	不可能

事务隔离级别的历史
#

ANSI SQL-92定义的隔离级别和异常现象确实对数据库行业影响深远，甚至30年后的今天，绝大部分工程师对事务隔离级别的概念还停留在此，甚至很多真实的数据库隔离级别实现也停留在此。但后ANSI92时代对事物隔离有许多讨论甚至批评，针对隔离级别和异常现象的论文、博客、文章、讨论非常多，这里概况一下事务的比较重要发展历史：

1992年，由于数据库行业处于混沌的事务状态，美国国家标准学会定义ANSI SQL-92标准。也就是广泛流传的4种隔离级别和4种异常现象
1995年，snapshot isolation等隔离级别提出和更多的异常现象。微软工程师等提出snapshot isolation隔离级别，并对ANSI SQL-92做出批判，92标准定义模糊，而且有许多隔离级别和异常现象未定义。参考《对ANSI SQL隔离级别的批判》.

此时隔离级别已不止4个，异常现象也更多，其中也包括写偏序异常。
1999年，由于锁模式的不同发展出过多的隔离级别，Atul Adya的论文整理了这些现象，并根据异常现象和功能将众多隔离级别回溯到ANSI SQL92标准进行对应。
2005年，由于绝大部分数据库声称他们是可串行化的，但他们实际上是快照隔离， Alan Fekete et al 提出“使快照隔离可序列化”。在snapshot isolation级别基础上实现可序列化，消除快照隔离的异象。
2008年，Fekete 扩展了可序列化，并提出数据库层面实现“使快照隔离可序列化”，称之为快照隔离可序列化SSI (Serializable Snapshot Isolation)
2012年，postgresql第一个在数据库中实现SSI ，参考postgresql数据库实现SSI的论文

其中，95年《对ANSI SQL隔离级别的批判》中的隔离级别和异常现象

各种数据库支持的隔离级别
#

很多数据库的声称他们”完全支持ACID“特性，但是没有可串行化是不能完全实现ACID的（特别是一致性）。然而许多数据库在不支持可串行化级别下声称他们支持ACID。其实他们绝大部分都没有完全实现，包括数据库老大哥oracle。

可串行化
#

人们对可串行化存在许多误解。

可串行化的含义：如果每个事务本身是正确的，即满足某些完整性条件，那么包括这些事务的任何串行执行的时间表是正确的（其事务仍然满足其条件）：“串行”意味着事务在时间上不重叠，并且不能相互干扰，即彼此之间存在完全隔离。

1970年代可串行化（serializable）通过严格两阶段锁（SS2PL）实现，读写相互阻塞，直到事务结束。SS2PL丢失高可用性但消除了异常现象。

除了SS2PL实现可串行化，还有其他方式，比如可串行化快照隔离（SSI）。

为了保证没有异常，可串行化会丢失一些并发性（不同实现方式有所不同），但可以真正保证数据的一致性（ACID中的consistency）。也就是说没有实现串行化的数据库，其实没有完全支持ACID特性

可串行化在数学上已经证明可以实现，但是真实的数据库世界有点”不正常“。实际上，可串行化是事务隔离级别中最高级的，也是所有学者和大佬强力推荐的隔离级别，不过绝大部分数据库在RC或快照隔离级别上运行

为什么弱隔离级别在学术上有问题，实际上没出现严重问题？
#

1.非可串行化隔离级别的异常现象，一般都需要再高并发情况下才会发生，一般低并发数据库不太会出现问题

2.异常现象真的发生的时候，有些应用可能没发现异常现象或没检查到异常对他们不重要。

3.有可能数据异常了，但应用只是返回报错，并进入数据异常处理程序。

4.成本过高。不仅是数据库序列化隔离级别开发成本高，应用对可序列化也需要适应成本。光是理解这部分复杂的理论就不是一件容易的事

5.高级别的隔离会丢失一些性能。大量的改造工作可能是吃力不讨好的，应用需要在“高并发”和“无异常现象”间做抉择

6.业务基于机制开发，而不是规则开发。业务多少有点适应弱隔离级别的异常现象，特别是RC或快照隔离级别

快照隔离
#

ANSI SQL92并未定义快照隔离snapshot isolation(SI)，这个隔离级别随着数据库行业发展才出现。

引自wiki定义：在快照隔离下执行的事务是在事务开始时拍摄的数据库的快照上操作的。当事务结束时，只有当事务更新的值自快照拍摄以来没有外部更改时，它才会成功提交。这样写冲突将导致事务中止。

快照隔离级别顾名思义就是就是使用了快照，存在于使用了MVCC的数据库中，多版本并发机制支持用户并发执行事务。

1992年 ANSI SQL92标准基于数据库的锁而定义，所以没有快照隔离级别这个定义。直到1995年《批判》的出现才被提出。

快照隔离串行化
#

由于快照隔离的广泛应用，而可序列化是学术上的数据库需要达到的隔离级别目标，可序列化快照隔离Serializable Snapshot Isolation (SSI) 随即产生。顾名思义，在快照隔离的基础上实现可序列化。

由于ANSI92标准的模糊性，虽然没有定义快照隔离，但许多数据库实际上就是使用的快照隔离。而快照隔离同样存在一些异常现象（包括写偏序），SSI的出现就是为了解决这些异常现象。

主流数据库通过基于S2PL或MVCC实现并发控制。在S2PL下写操作会阻塞其他事务读写，因此不会有写偏序异常问题。而MVCC实现了读写互不阻塞，只有写写冲突。在并发RW模式模式下会导致写偏序问题。SSI在pg9.1开始已经嵌入快照隔离SI中（pg只有快照隔离，哪怕是在可序列化级别下），解决了写偏序等异常。

写偏序
#

由于某些冲突构成环，会出现串行化异常**。**其中比较容易理解的一个就是写偏序(write skew)。

写偏序只发生在rw模型，ww、wr均不会发生写偏序，并且事务必须在并发条件下才会出现。前一个事务写入依赖后一个事务写入才会形成依赖环。

有许多现实案例可以出现写偏序异常，我们用一个经典的黑白球问题来理解写偏序

袋中有10个球，5个白球和5个黑球。此时有两个事务，P和Q。P将所有黑球改成白球，Q将所有白球改成黑球。此时可以有两个串行执行，P，Q或Q，P。在这两种情况下，最终结果是袋中有10个白球或者10个黑球。但是，快照隔离允许另一种结果：

事务 P 拿出5个黑球
事务 Q 拿出5个白球
事务 P 将手中所有黑球改成白球，放回袋中
事务 Q 将手中所有白球改成黑球，放回袋中

此时袋中还是5个黑球和5个白球，这在任何一个串行执行中都是不可能的。但这在快照隔离中是有效：每个事务都维护数据库的一致视图，并且其写集不与任何并发事务的写集重叠，如此白球黑球发生交换。

黑白球问题说明：快照隔离执行结果与串行化执行结果不一致，快照隔离下发生写偏序异常，数据结果与预期不一致。

pg中的SSI
#

postgresql数据库是首个在数据库中实现SSI的数据库。

引用wiki的黑白球代码示例

create table dots
 (
 id int not null primary key,
 color text not null
 );
 insert into dots
 with x(id) as (select generate_series(1,10))
 select id, case when id % 2 = 1 then 'black'
 else 'white' end from x;

set default_transaction_isolation = ‘serializable’;	set default_transaction_isolation = ‘serializable’;
begin; update dots set color = ‘black’ where color = ‘white’;
	begin; update dots set color = ‘white’ where color = ‘black’;
commit
	commit
(pg SSI先提交者成功提交，后提交者抛出报错 )	ERROR: could not serialize access due to read/write dependencies among transactions DETAIL: Reason code: Canceled on identification as a pivot, during commit attempt. HINT: The transaction might succeed if retried.

（已提交读和可重复读级别，均不会出现报错，黑白球颜色交换，不再展示测试结果）

严格两阶段提交（S2PL）也可以实现可串行化，但S2PL需要很重的读写锁，直到事务提交为止。S2PL会极大的影响并发性能，而且用户一般不会接受读写互相阻塞的情况，所以pg没有采用S2PL。

SSI是可序列化的另一种方案。它仍然会使用快照隔离，只是会额外检查是否有异常现象发生。

两个方案的处理方式也不同：在异常现象发生时，S2PL会阻塞事务，而SSI会中断事务以打破循环。

人们没有使用可串行化，原因之一有可串行化会降低数据库性能。这其实可以理解，因为有”检查异常现象“的SSI必定比什么检查都没有的弱隔离级别性能低。不过经过SSI实现理论的发展和pg本身对只读事务的优化，SSI的性能已于SI相差无几。

可序列化能极大的简化应用对一致性的担心，而pg9.1已实现ssi并加以优化。期待应用有一天真的能使用可串行化隔离级别。

事务隔离级别参考
#

https://wiki.postgresql.org/wiki/SSI

https://en.wikipedia.org/wiki/Serializability

https://en.wikipedia.org/wiki/Snapshot_isolation

https://justinjaffray.com/what-does-write-skew-look-like/

http://www.bailis.org/blog/when-is-acid-acid-rarely/

https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf 95年SI隔离级别以及对SQL92标准的批评

https://www.cse.iitb.ac.in/infolab/Data/Courses/CS632/2009/Papers/p492-fekete.pdf SSI论文

https://drkp.net/papers/ssi-vldb12.pdf postgresql实现SSI

https://ristret.com/s/f643zk/history_transaction_histories 事务隔离级别的历史

事务的处理
#

事务块
#

从事务形态划分可分为隐式事务和显示事务。隐式事务是一个独立的SQL语句，执行完成后默认提交。显示事务需要显示声明一个事务，多个sql语句组合到一起称为一个事务块。

事务块通过begin，begin transaction，start transaction开始

通过COMMIT,END或ABORT,ROLLBACK结束，其中COMMIT=END，ABORT=ROLLBACK

BEGIN;
select * from lzl1 limit 1;
update lzl1 set a=2;
END;

如果事务块执行过程中一旦有报错，由于事务必须满足原子性，事务只能回退

lzldb=# begin;
BEGIN
lzldb=*# select * from lzl2;
ERROR: relation "lzl2" does not exist
LINE 1: select * from lzl2;
^
lzldb=!# commit;
ROLLBACK

事务处理函数
#

事务处理函数分为3个层次：顶层事务函数、中层事务函数、底层事务函数顶层事务函数，处理事务块命令，比如BEGIN, COMMIT, ROLLBACK, SAVEPOINT等，有如下函数

BeginTransactionBlock	启动事务块
EndTransactionBlock	结束事务块
UserAbortTransactionBlock	用户显示结束事务块
DefineSavepoint	生成保存点
RollbackToSavepoint	回滚到某保存点
ReleaseSavepoint	释放保存点

中层事务函数，每个sql在执行前后都会调用中层事务函数，包括检测到异常后，有如下函数

StartTransactionCommand	启动事务命令
CommitTransactionCommand	完成事务命令，注意不是提交命令
AbortCurrentTransaction	退出当前事务

底层事务函数，真正的事务处理函数，负责维护事务状态、事务资源分配和回收等，有如下函数

StartTransaction	启动事务
CommitTransaction	提交事务
AbortTransaction	回滚/中断事务
CleanupTransaction	清理事务
StartSubTransaction	启动子事务
CommitSubTransaction	提交子事务
AbortSubTransaction	回滚/中断子事务
CleanupSubTransaction	清理子事务

其实这上面几个函数还是比较好分辨的。抛开几个特殊的函数（上层相关savepoint，中层abort函数），其实上、中、下三层事务层分成了：*Block（事务块函数），*Command（command函数），*Transaction（真正的事务处理函数）。然后把savepoint子事务当做事务块函数（后面会介绍，子事务可以在事务块中回退，所以这里把子事务放在事务块一级理所当然），把abort命令当做command级函数就可以了。

事务块状态
#

上层函数和中层函数同时控制事务块状态，底层函数控制事务状态

事务块状态和事务状态均在src/backend/access/transam/xact.c

typedef enum TBlockState
{
/* 不在事务块中的状态 */
TBLOCK_DEFAULT, /* 空闲状态，事务开始或结束后都处于此状态 */
TBLOCK_STARTED, /* 刚开始进入事务块时的状态，由TBLOCK_DEFAULT转换到此状态，此状态存在时间较短 */
 
/* 事务块状态 */
TBLOCK_BEGIN, /* 启动事务块，此时才启动数据块，进入数据块级状态 */
TBLOCK_INPROGRESS, /* 活跃的事务，BEGIN以后事务块一直处于此状态，直到事务结束 */
TBLOCK_IMPLICIT_INPROGRESS, /* 隐式BEGIN的活跃事务 */
TBLOCK_PARALLEL_INPROGRESS, /* 并行执行的活跃事务 */
TBLOCK_END, /* 收到COMMIT命令 */
TBLOCK_ABORT, /* 事务失败，等待ROLLBACK */
TBLOCK_ABORT_END, /* 事务失败，收到ROLLBACK */
TBLOCK_ABORT_PENDING, /* 活跃事务，收到ROLLBACK */
TBLOCK_PREPARE, /* 活跃事务，收到PREPARE（显式2PC） */

/* 子事务状态（仍然是事务块级状态） */
TBLOCK_SUBBEGIN, /* 启动子事务 */
TBLOCK_SUBINPROGRESS, /* 活跃的子事务 */
TBLOCK_SUBRELEASE, /* 收到RELEASE（释放保存点） */
TBLOCK_SUBCOMMIT, /* 当子事务还在运行的时候（SUBINPROGRESS），收到父事务COMMIT */
TBLOCK_SUBABORT, /* 失败子事务，等待rollback命令 */
TBLOCK_SUBABORT_END, /* 失败子事务，收到rollback命令 */
TBLOCK_SUBABORT_PENDING, /* 活跃子事务，收到rollback命令 */
TBLOCK_SUBRESTART, /* 活跃子事务，收到rollback to命令 */
TBLOCK_SUBABORT_RESTART /* 失败子事务，收到ROLLBACK TO命令 */
} TBlockState;

大部分状态是显而易见的。需要补充说明的是事务回滚（rollback）和事务失败(ABORT)两者后续行为是相似的，他们都要把清理事务资源和退出当前事务。但是pg把他们分为了两种行为，设置了两种状态TBLOCK_ABORT，TBLOCK_ABORT_END（子事务亦然），为什么会这样呢？

在src/backend/access/transam/README中对此现象作了详细的说明：

场景 1 场景 2

1) 用户输入 BEGIN 1) 用户输入 BEGIN

2) 用户执行某些命令 2) 用户执行某些命令

3) 用户不喜欢她所看到的东西，输入ABORT 3) 事务系统因为某些原因中断（语法错误等）

场景1中，我们想中断事务并把事务回退到default状态。

场景2中，可能后续还会有更多的命令，这些命令也是当前事务块的一部分，我们不得不忽略这些命令，直到我们看见COMMIT or ROLLBACK。

AbortCurrentTransaction处理事务内部中断，UserAbortTransactionBlock处理事务用户中断。两个函数都依赖AbortTransaction来处理所有真正的工作。唯一区别在于AbortTransaction工作结束后我们进入了什么状态:

* AbortCurrentTransaction leaves us in TBLOCK_ABORT

* UserAbortTransactionBlock leaves us in TBLOCK_ABORT_END（原文如此，不过用户输入结束应该进入TBLOCK_ABORT_PENDING状态）

场景 1	场景 2
1) 用户输入 `BEGIN`	1) 用户输入 `BEGIN`
2) 用户执行某些命令	2) 用户执行某些命令
3) 用户不喜欢她所看到的东西，输入`ABORT`	3) 事务系统因为某些原因中断（语法错误等）

底层事务中断处理分为两个阶段：

* 一旦我们意识到事务失败，就会执行AbortTransaction。这应该释放所有共享资源（锁等），以防不必要的增加其他backends的延迟。

* 当我最终看到用户COMMIT或者ROLLBACK时，执行CleanupTransaction；该函数将清理资源并让我们完全跳出事务。特别是，在此之前我们不能破坏TopTransactionContext。

事务状态
#

事务状态一目了然(注意跟事务块状态是不同的)

typedef enum TransState
{
TRANS_DEFAULT, /* 空闲 */
TRANS_START, /* 事务启动 */
TRANS_INPROGRESS, /* 活跃的事务 */
TRANS_COMMIT, /* 事务提交 */
TRANS_ABORT, /* 退出事务 */
TRANS_PREPARE /* prepare事务（2pc） */
} TransState;

事务状态流转
#

事务块中的一个个命令，调用事务函数，事务函数转变事务、事务块的状态以一个最简单的事务块举例（参考readme）

1)BEGIN
2)SELECT * FROM foo
3)INSERT INTO foo VALUES (...)
4)COMMIT

命令调用关系：

 	/ StartTransactionCommand; --中层事务命令启动函数
 / StartTransaction; --底层真正处理启动事务函数
1)< ProcessUtility; --ProcessUtility处理BEGIN命
 \ BeginTransactionBlock; --顶层事务块启动函数
 \ CommitTransactionCommand; --中层完成命令函数 
 		 
 / StartTransactionCommand; --中层事务命令启动函数
2) / PortalRunSelect; --SELECT语句执行
 \ CommitTransactionCommand; --中层完成命令函数
 \ CommandCounterIncrement; --中层完成命令函数
 
 / StartTransactionCommand; --中层事务命令启动函数
3) / ProcessQuery; --INSERT语句执行
 \ CommitTransactionCommand; --中层完成命令函数
 \ CommandCounterIncrement; --命令计数器计数+1

 / StartTransactionCommand; --中层事务命令启动函数
 / ProcessUtility; --ProcessUtility处理commit命令
 4) < EndTransactionBlock; --调用顶层事务块结束函数
 \ CommitTransactionCommand; --中层完成命令函数
 \ CommitTransaction; --底层真正处理提交事务函数

事务块的每一个命令，都会以中层函数StartTransactionCommand和CommitTransactionCommand开始和结束
在以上两个中层函数中间，可以看成真正执行的命令处理

2)SELECT和3)INSERT事务块状态都是TBLOCK_INPROGRESS，BEGIN和COMMIT状态块转换流程如下：

事务函数参考
#

《postgresql技术内幕》 src/backend/access/transam/README

事务ID
#

pg中每个事务都会分配事务ID，事务ID分为虚拟事务ID和持久化事务ID。pg的事务ID非常重要，是理解事务、数据可见性、事务ID回卷等等的重要知识点。

虚拟事务ID
#

只读事务不会分配事务ID，事务ID是很宝贵的资源，比如简单的select语句不会申请事务ID。本身不需要把事务ID持久化到磁盘，但是为了在共享锁等情况下对事务进行标识，需要一种非持久化的事务ID，这个就是虚拟事务ID（vxid) VXID由两部分组成：backendID 和backend本地计数器。源码：src/include/storage/lock.h

 typedef struct
{
BackendId backendId; /* backendId from PGPROC */
LocalTransactionId localTransactionId; /* lxid from PGPROC */
} VirtualTransactionId;

(PGPROC是一种存储进程信息的结构体，后面会介绍）

pg_locks可以看到vxid，查询pg_locks本身就是一个sql，会产生vxid

lzldb=# begin;
BEGIN
lzldb=*# select locktype,virtualxid,virtualtransaction,mode from pg_locks;
 locktype | virtualxid | virtualtransaction | mode 
------------+------------+--------------------+-----------------
 relation		| 		 | 4/16 | AccessShareLock
 virtualxid | 4/16 	 | 4/16 | ExclusiveLock
(2 rows)
 
lzldb=*# savepoint p1;
SAVEPOINT
lzldb=*# select locktype,virtualxid,virtualtransaction,mode from pg_locks;
 locktype 	| virtualxid | virtualtransaction | mode 
------------+------------+--------------------+-----------------
 relation 	| 		 | 4/16 | AccessShareLock
 virtualxid | 4/16 | 4/16 | ExclusiveLock
lzldb=*# rollback;
ROLLBACK
lzldb=# select locktype,virtualxid,virtualtransaction,mode from pg_locks;
 locktype 	| virtualxid | virtualtransaction | mode 
------------+------------+--------------------+-----------------
 relation 	| 	 | 4/17 | AccessShareLock
 virtualxid | 4/17 | 4/17 | ExclusiveLock

此时\q退出会话再立即登录，计数仍然继续4/19

另开一个窗口，backendID+1

lzldb=# select locktype,virtualxid,virtualtransaction,mode from pg_locks;
 locktype | virtualxid | virtualtransaction | mode 
------------+------------+--------------------+-----------------
 relation | | 5/3 | AccessShareLock
 virtualxid | 5/3 | 5/3 | ExclusiveLock

从以上测试能看出：

VXID的backendID不是真正的进程号PID，也只是一个简单的递增的编号
VXID的bakendID和命令编号都是递增的
子事务没有自己的VXID，他们用父事务的VXID
VXID也有回卷，不过问题不严重，因为没有持久化，实例重启后VXID从头开始计数

永久事务ID
#

32位的TransactionId
#

当发生数据变化的事务开始时，事务管理器会为事务分配一个唯一标识TransactionId。TransactionId是32位无符号整型，总共可以存储 2^32=4294967296，42亿多个事务。32位无符号整型能存储的数据范围为：0~2^32-1

3个特殊的事务ID

src/include/access/transam.h中宏定义几个事务ID

#define InvalidTransactionId ((TransactionId) 0)
#define BootstrapTransactionId ((TransactionId) 1)
#define FrozenTransactionId ((TransactionId) 2)
#define FirstNormalTransactionId ((TransactionId) 3)
#define MaxTransactionId ((TransactionId) 0xFFFFFFFF)

0 代表无效TransactionID

1 代表启动事务ID，只在初始化数据库时才会使用。比所有正常事务都旧

2 代表冻结事务ID。比所有正常事务都旧

#define TransactionIdIsNormal(xid) ((xid) >= FirstNormalTransactionId)

事务ID>=3时是正常事务id。

最大事务ID MaxTransactionId是0xFFFFFFFF=4294967295=2^32-1 所以正常事务id能分配到的范围为:3~2^32-1

64位的FullTransactionId
#

事务ID是顺序递增的，PostgreSQL一直使用32位事务ID。在PostgreSQL 7.2之前，当32位事务ID用完时，必须dump然后恢复数据库。而64位的事务ID几乎是用不完的。源码中定义64位FullTransactionId为结构体

/*
 *一个64位的值，包含一个epoch和一个TransactionId。它被封装在一个结构中，以防止隐式转换为TransactionId。
 *并非所有值都表示有效的正常XID。
 */
typedef struct FullTransactionId
{
uint64 value;
} FullTransactionId;

由上面的源码可知，64位的由epoch和32位的TransactionId组成，通过以下函数转化

#define EpochFromFullTransactionId(x)	((uint32) ((x).value >> 32))
#define XidFromFullTransactionId(x)		((uint32) (x).value)

epoch是FullTransactionId右移32位，xid（TransactionId）是FullTransactionId取模。这相当于把32位的TransactionId看成“环”，循环重复使用；64位的FullTransactionId是一直递增的“线”，几乎取不完。

full的事务id可以超过2^32：

事务ID分配
#

做几个小实验来看下事务id是怎么分配的。其中用到两个返回事务id的function

pg_current_xact_id ()：返回当前事务id，如果当前事务还没有分配事务id，那么分配一个事务id。pg12及以前用txid_current ()

pg_current_xact_id_if_assigned () ：返回当前事务id，如果当前事务还没有分配事务id，那么返回NULL。pg12及以前用txid_current_if_assigned ()

事务id顺序分配

lzldb=# select pg_current_xact_id();
 pg_current_xact_id 
--------------------
 612
lzldb=# select pg_current_xact_id();
 pg_current_xact_id 
--------------------
 613
lzldb=# select pg_current_xact_id();
 pg_current_xact_id 
--------------------
 614

begin不会立即分配事务id

lzldb=# begin; --显示开启事务
BEGIN
lzldb=*# select pg_current_xact_id_if_assigned () ; --begin不会立即分配事务id
 pg_current_xact_id_if_assigned 
-------------------------------- 

(1 row)
lzldb=*# select * from lzl1; --begin后立即查询
 a 
---

(0 rows)
lzldb=*# select pg_current_xact_id_if_assigned () ; --查询不会分配事务id
 pg_current_xact_id_if_assigned 
-------------------------------- 

(1 row)
lzldb=*# insert into lzl1 values(1); --插入数据，做一个数据变更
INSERT 0 1
lzldb=*# select pg_current_xact_id_if_assigned () ; --begin后的第一个非查询语句分配事务id
 pg_current_xact_id_if_assigned 
--------------------------------
 611
lzldb=*# commit;
COMMIT
lzldb=# select xmin, pg_current_xact_id_if_assigned () from lzl1; --insert事务写入到xmin
 xmin | pg_current_xact_id_if_assigned 
------+--------------------------------
 611

系统表中的有些记录，在数据库初始化时分配了BootstrapTransactionId=1

postgres=# select xmin,count(*) from pg_class where xmin=1 group by xmin;
 xmin | count 
------+-------
 1 | 184

以上实验得出以下结论

数据库初始化时分配特殊事务id 1，可以在系统表中看到
事务id是递增分配的
begin不会立即分配事务id，begin后的第一个非查询语句分配事务id
当一个事务插入了一tuple后，会将事务的txid写入这个tuple的xmin。

事务ID对比
#

pg事务新旧通过事务ID来对比。在src/backend/access/transam/transam.c定义了4种事务ID对比函数，分别是<,<=,>,>=

bool TransactionIdPrecedes()
bool TransactionIdPrecedesOrEquals()
bool TransactionIdFollows()
bool TransactionIdFollowsOrEquals()

内容都差不多，拿TransactionIdPrecedes()代表来看

bool
TransactionIdPrecedes(TransactionId id1, TransactionId id2)
{
/*
 * If either ID is a permanent XID then we can just do unsigned
 * comparison. If both are normal, do a modulo-2^32 comparison.
 */
int32 diff;
 
if (!TransactionIdIsNormal(id1) || !TransactionIdIsNormal(id2))
return (id1 < id2);
 
diff = (int32) (id1 - id2);
return (diff < 0);
}

该段源码的知识点

TransactionIdIsNormal()是已经在header中宏定义了的判断正常事务的函数，FirstNormalTransactionId是常量3。也就是说正常事务ID是>=3的

#define TransactionIdIsNormal(xid) ((xid) >= FirstNormalTransactionId)

int32是有符号的整型，第一位0表示正数，第一位-1表示负数，取值范围-2*31~2^31-1
数值溢出，意思数值超过数据存储范围，比如2^31对于int32是刚好数值溢出的。为了保证数据在范围内，对数值加减模长

对比事务ID源码分为2段理解

非正常事务ID对比：

if (!TransactionIdIsNormal(id1) || !TransactionIdIsNormal(id2))
return (id1 < id2);

当id1=2，id2=100时，return(2<100)，precede为真，正常事务较新

当id1=100，id2=2时，return (100<2)，precede为假，正常事务较新

所以，txid为1、2时比正常事务要旧

正常事务ID对比：

diff = (int32) (id1 - id2);
return (diff < 0);

id1-id2可以是负数，所以diff不能是unsign int，转换有符号型的int。然后最关键的来了

由于int32是-2*31~2^31-1，

当id1=2^31+99，id2=100，id1-id2=2^31-1。这没问题，int32刚好可以存放 =>大txid较新

当id1=2^31+100，id2=100，id1-id2=2^31。这有问题，刚好超出int32存储范围，此时的值为2^31-2^32=-2^31<0 =>小txid较新

当id1=100，id2=2^31+100，id1-id2=-2^31。这没问题，int32刚好可以存放 =>大txid较新

当id1=100，id2=2^31+101，id1-id2=-2^31-1。这有问题，刚好超出int32存储范围，此时的值为-2^31-1+2^32=2^31-1>0 =>小txid较新

以上分析可以看出，当发生数值溢出时，txid大的事务看不见更小的txid事务，本身数值溢出是一个异常事件，这无可厚非。为了解决这个问题，pg将40亿事务id分成两半，一半事务是可见的，另一半事务是不可见的。

比如，txid 100的事务，它过去的20亿事务是它可见的，它未来的20亿事务是它不可见的。所以，在pg数据库中最大事务和最小事务（数据库年龄）之差最大为|-2^31|=2^31，20亿左右

事务ID回卷
#

什么是事务ID回卷？

理解事务ID回卷本身不难，但是刚开始了解回卷时，发现了事务ID回卷有两种定义：

pg官方定义：

由于事务ID的大小有限（32位），一个长时间运行的集群（超过40亿个事务）将遭遇事务ID的回卷：XID计数器回卷到零，突然之间，过去的事务似乎在未来，这意味着它们变得不可见。简而言之，就是灾难性的数据丢失。（事实上，数据仍然存在，但如果你无法获得数据。）

interdb解释：

元组中t_xmin记录了当前元组的最小事务，如果这个元组一直没有变化，这个t_xmin不会变。假如一个元组tuple_1由txid=100事务创建，它的t_xmin=100。如果数据库事务向前推进了2^31个，到了2^31+100，此时tuple_1是可见的。此时再启动一个事务，txid推进至2^31+101，txid=100的事务属于未来，tuple_1是不可见的，此时便发生了严重的数据丢失问题，这就是事务回卷。

是的，对事物回卷的定义，官方文档与有些经典文章不太一样，他俩确实是在说两个事情。我把这个当成是翻译问题：他俩的行为在英语语义里面都是wraparound。如果重新思考“回卷”（wraparound）的含义，其实它俩都是回卷。

不过回卷形式还是有些区别：前者是事务ID（2^32）全部用完，回卷到0重新计数；后者是把事务ID分成两半，“最老的事务ID“与”最新的事务ID“只差大于2^31。

pg官方定义的事务id回卷是为了引出“事务ID是一个环”这个概念
一般认为的事务id回卷问题，是“把环分成两半，一半为可见，一半为不可见”这个概念，出现“超过一半”的事务id就是事务id回卷

实际上真正需要关心的回卷问题是后者：最新和最旧的事务id相差不能超过21亿（2^31)。

21亿事务到底要跑多久？

21亿个事务看上去是挺多，但是仍然可能用完。

比如一个tps为100的pg库（不算select语句，因为单纯的select不会分配事务id），1天会使用8640000个事务，只需要历时2147483648/8640000≈248天就可以把21亿个事务id耗尽发生事务回卷；如果每秒1000个事务，不到1个月时间就可以把21亿事务id用完。所以事务回卷问题是pg数据库中必须要关注的。

事务id冻结
#

为了解决事务回卷引起严重的数据丢失问题，pg引入事务冻结的概念。

xid会循环使用，并分成2半，一半可见一半不可见。如xid=100的元组，如果不经过任何操作，事务id一直往前推进，那么这个可见的元组最终将不可见。

之前介绍有个冻结事务id，此时给xid=100的元组标记为冻结事务id，那么他将仍然可见。

这个就是事务冻结的作用。

事务id FrozenTransactionIdn=2，并且比所有正常事务都旧。也就是说txid=2对于所有正常事务(txid>=3)都是可见的。当t_xmin比当前txid-vacuum_freeze_min_age(默认5000w）更旧时，该元组将重写为冻结事务id 2。在9.4及以后的版本，用t_infomask中的xmin_frozen来表示冻结元组，而不是重写t_xmin为2。

事务ID回卷问题有许多优化方案，不过都绕不过事务冻结处理回卷问题，而事务冻结这个操作,会有非常大的IO消耗以及cpu消耗(所有表的所有行读一遍,重置标记)无从避免回卷，甚至数据库会拒绝所有操作，直至冻结操作结束，这也是俗称的“冻结炸弹”。业务系统越繁忙，事务越多的库,越容易触发。（后面再开章节展开事务冻结优化）

64位的事务id
#

事务id耗尽回卷问题终极解决方案就是使用64位的事务ID。32位事务id有2^32个，64位事务id有2^64个。即使每秒10000个事务，每天864000000个事务，也要5849万年才能把事务id消耗光。如果拥有64位事务id，事务id几乎是取之不尽用之不竭，就不需要考虑事务id回卷问题，也不需要事务冻结操作，也就没有“冻结炸弹”的概念…

为什么还没有实现64位事务id？

请注意，64为事务id已经在pg库中了（就像前面介绍的FullTransactionId）。但因为元组存储结构有限，元组中的xmin、xmax等等仍然用的是32位的XID，事务id对比大小仍然依赖32位的XID。xmin，xmax可以简单理解为插入事务和删除事务的事务id，保存在每个元组的header中（元组结构章节将介绍该部分内容），而header空间是有限的。32位事务id有8个字节，64位事务有16个字节，存储xmin、xmax两个事务id将需要额外的16字节空间，目前header无法保存这么大的数据。社区讨论过两种实现方案

1.扩展header。直接将64位事务id存储进去

2.header大小不变。内存中保留64位事务id，增加epoch概念来位移转换两者的关系。

第一种方案已基本放弃，对比其他系统，pg的tuple header已经够大了。

第二种方案epoch已经有了，fulltransactionid转换transactionid已经有了，怎么把元组中的transactionid转换为fulltransactionid是关键（不过怎么也得多一些存储来保存epoch吧，不然怎么实现？）

参考社区邮件

https://www.postgresql.org/message-id/CAEYLb_UfC+HZ4RAP7XuoFZr+2_ktQmS9xqcQgE-rNf5UCqEt5A@mail.gmail.com

https://www.postgresql.org/message-id/flat/DA1E65A4-7C5A-461D-B211-2AD5F9A6F2FD%40gmail.com

2014年社区就提出了64位事务永久解决freeze问题，并于2017年开始讨论如何实践64位事务id，不过经过了多个pg版本也只是只闻其声不见其人。由于数据库对于数据的敏感性和重要性，而事务id的改造对于数据库来说牵扯的东西太多，稍微不注意可能导致数据丢失或者触发未知bug，64位事务id改造的问题pg走的很谨慎。不过社区还是在考虑这个问题，期待有一天在某个pg版本中事务id回卷问题彻底解决。

事务id参考
#

《Postgresql指南内幕探索》 https://www.interdb.jp/pg/pgsql05.html https://www.interdb.jp/pg/pgsql06.html https://www.slideshare.net/masahikosawada98/introduction-vauum-freezing-xid-wraparound?from_action=save https://www.modb.pro/db/427012 https://www.modb.pro/db/377530 https://www.postgresql.org/docs/13/routine-vacuuming.html https://blog.csdn.net/weixin_30916255/article/details/112365965 https://wiki.postgresql.org/wiki/FullTransactionId https://www.bookstack.cn/read/aliyun-rds-core/bd7e1c1955b35f7d.md https://github.com/digoal/blog/blob/master/201605/20160520_01.md

事务相关的元组结构
#

元组结构中包含很多pg的mvcc所必要的信息，下面的内容将梳理xmin,xmax,t_ctid,cmin,cmax,combo cid,tuple id的含义和关系

物理结构
#

HeapTupleHeaderData相当于tuple的header，其结构在src/include/access/htup_details.h中定义

typedef struct HeapTupleFields
{
	TransactionId t_xmin;		/* 插入事务的ID */
	TransactionId t_xmax;		/* 擅长或锁定事务的ID */

	union
	{
		CommandId	t_cid;		/* 插入或删除的命令ID */
		TransactionId t_xvac;	/* VACUUM FULL的事务ID */
	}			t_field3;
} HeapTupleFields;

typedef struct DatumTupleFields
{
...
} DatumTupleFields;

struct HeapTupleHeaderData
{
	union
	{
		HeapTupleFields t_heap;
		DatumTupleFields t_datum;
	}			t_choice;
	ItemPointerData t_ctid;		/* 当前元组或更新元组的TID */
...
};

HeapTupleHeaderData中有5个定义对MVCC及其重要。其中x代表transaction，c代表command，t代表tuple，便于分类理解

t_xmin：表示插入该元组的事务ID
t_xmax：表示删除该元组的事务ID或者回滚事务ID。如果没有被删除或更新元组，xmax是0；如果删除或更新元组后回滚，xmax是回滚事务ID。
t_xvac:元组被vacuum时设置的xid，此时元组已脱离了原来的事务
t_cid：表示命令标识(command id,cid)，一个事务可以包含多个SQL，事务中的命令从0开始编号，cid依次递增。CommandId是uint32类型，最大支持2^32 - 1个命令，为了节省资源，而且查询不会影响行的事务顺序，查询不会增加cid（这点类似事务id分配）
t_ctid：保存指向自身或新元组标识符(tid）,tid是标识表中元组的，是元组的物理地址。如果一条记录被修改多次，那么该记录会存在多个版本。各个版本通过t_cid串联，形成一个版本链。通过这个版本链，可以找到最新的版本

系统列
#

每个元组都有6个系统列（每个tuple都有，可以直接查到），它们是tableoid,xmin,xmax,cmin,cmax,ctid 。tableoid是表的oid，在查询和dml时是不会变化的，这里重点讲其余5个系统列

lzldb=# select xmin,xmax,cmin,cmax,ctid from lzl1;

 xmin | xmax | cmin | cmax | ctid 

------+------+------+------+-------

 616 | 619 | 0 | 0 | (0,3)

cmin：插入元组的cid，command id
cmax：删除元组的cid，command id

其中xmin,xman,xvac是物理存储的，定义在struct HeapTupleFields中，但是cmin和cmax没有定义在HeapTupleFields结构体中的，结构体有关于command的t_cid，cmin、cmax就是从t_cid取数

cmin，cmax的源码还是在src/include/access/htup_details.h中

/* SetCmin is reasonably simple since we never need a combo CID */
#define HeapTupleHeaderSetCmin(tup, cid) \
do { \
	Assert(!((tup)->t_infomask & HEAP_MOVED)); \
	(tup)->t_choice.t_heap.t_field3.t_cid = (cid); \
	(tup)->t_infomask &= ~HEAP_COMBOCID; \
} while (0)

/* SetCmax must be used after HeapTupleHeaderAdjustCmax; see combocid.c */
#define HeapTupleHeaderSetCmax(tup, cid, iscombo) \
do { \
	Assert(!((tup)->t_infomask & HEAP_MOVED)); \
	(tup)->t_choice.t_heap.t_field3.t_cid = (cid); \
	if (iscombo) \
		(tup)->t_infomask |= HEAP_COMBOCID; \
	else \
		(tup)->t_infomask &= ~HEAP_COMBOCID; \
} while (0)


/*
 * HeapTupleHeaderGetRawCommandId will give you what's in the header whether
 * it is useful or not. Most code should use HeapTupleHeaderGetCmin or
 * HeapTupleHeaderGetCmax instead, but note that those Assert that you can
 * get a legitimate result, ie you are in the originating transaction!
 */
#define HeapTupleHeaderGetRawCommandId(tup) \
( \
	(tup)->t_choice.t_heap.t_field3.t_cid \
)

combocid
#

在8.3以前cmin和cmax是分开的。后来考虑到同事务对一条数据既插入又删除的情况比较少，而且事务结束后cmin、cmax都不需要，同时为了节省header空间，cmin、cmax合并到一起称为combo command id即combocid

combocid源码位置src/backend/utils/time/combocid.c

/* Key and entry structures for the hash table */
typedef struct
{
	CommandId	cmin;
	CommandId	cmax;
} ComboCidKeyData;
/* comboid的结构为cmin和cmax*/
static CommandId
GetComboCommandId(CommandId cmin, CommandId cmax)
{
...
/*
 * 当第一次使用到combo cid时才会生成hash表 
 */
if (comboHash == NULL)
{
	HASHCTL		hash_ctl;

	/* 生成数组、hash表 */
	comboCids = (ComboCidKeyData *)
		MemoryContextAlloc(TopTransactionContext,
						 sizeof(ComboCidKeyData) * CCID_ARRAY_SIZE);
	sizeComboCids = CCID_ARRAY_SIZE;
	usedComboCids = 0;

	memset(&hash_ctl, 0, sizeof(hash_ctl));
...
	comboHash = hash_create("Combo CIDs",
							CCID_HASH_SIZE,
							&hash_ctl,
							HASH_ELEM | HASH_BLOBS | HASH_CONTEXT);
}
...
}

combocid存放在hash表中。当事务第一次使用combocid时，会在内存中开辟一小块地方存放combocid。

所以这几个command id的关系和调用过程：combocid->(cmin,cmax)->(t_ctid,t_ctid)

简单的事务相关id和系统列关系
#

看了这么多id和源码，似乎有点乱。为了便于理解和记忆，梳理一下这些事务id、command id、tuple id的关系

事务的初步体验
#

在没有工具和插件的条件下，初步体验一下这几个系统列在事务中的变化

lzldb=# select xmin,xmax,cmin,cmax,ctid from lzl1;
 xmin | xmax | cmin | cmax | ctid 
------+------+------+------+-------
 622 | 0 | 0 | 0 | (0,1)
lzldb=# begin ;
BEGIN
lzldb=*# update lzl1 set a=2;
UPDATE 1
--更新后，xmin+1,ctid+1，这里其实出现了新的tuple
lzldb=*
select xmin,xmax,cmin,cmax,ctid from lzl1; 

xmin | xmax | cmin | cmax | ctid 
------+------+------+------+-------
 623 | 0 | 0 | 0 | (0,2)

lzldb=*# rollback;
ROLLBACK
--xmax会记录回滚事务id
--xmin，ctid又回到了旧值，其实旧tuple不怎么变化
lzldb=# select xmin,xmax,cmin,cmax,ctid from lzl1;
 xmin | xmax | cmin | cmax | ctid 
------+------+------+------+-------
 622 | 623 | 0 | 0 | (0,1)
lzldb=# update lzl1 set a=2;
UPDATE 1
--再次更新，tuple号跳过了2，直接到3
lzldb=# select xmin,xmax,cmin,cmax,ctid from lzl1;
 xmin | xmax | cmin | cmax | ctid 
------+------+------+------+-------
 624 | 0 | 0 | 0 | (0,3)

元组header与事务
#

pageinspect插件
#

直接看行的变化是看不到旧的tuple的，所以需要pageinsect插件。pageinsect插件是pg自带的第三方插件，可以展示数据页面的具体内容。为了观察tuple是如何支持事务的，需要用到get_raw_page()和heap_page_items()两个函数。 get_raw_page()：返回指定块的二进制值。其中fork有main、fsm、vm、init几个值。main是数据文件主文件，fsm是free space map块文件，vm是可见性映射快文件，init是初始化的块，如果不指定fork默认为main heap_page_items()：显示一个堆页面上的所有行指针，即使因为mvcc看不到的行也会被展示。一般把get_raw_page()当做参数传入heap_page_items()以展示元组的header、pointer信息和数据本身 heap_tuple_infomask_flags：将十进制的infomask，infomask2值转换成其含义（标识），输出2列：所有单标识和联合标识。(infomask后面会介绍)

lzldb=# create extension pageinspect;
CREATE EXTENSION
lzldb=# select t_xmin,t_xmax,t_field3 as t_cid,t_ctid from heap_page_items(get_raw_page('lzl1',0));
 t_xmin | t_xmax | t_cid | t_ctid 
--------+--------+-------+--------
 633 | 0 | 0 | (0,1)

lp（line pointer）
#

line pointer直译是行指针的意思，实际上是页面中的行指针编号，相当于在页面中标记了一个元组。t_ctid看上去更像是tuple id，但是ctid只是（表的page号，行指针编号）的组合，ctid可以指向下个lp 。例如对一个元组做一次update，会增加一个元组，新元组的lp编号+1，旧tuple的ctid指向新tuple的lp，新tuple的ctid指向自己

lzldb=# select lp,t_ctid from heap_page_items(get_raw_page('lzl1',0));
 lp | t_ctid 
----+--------
 1 | (0,1)
(1 row)

lzldb=# update lzl1 set a=2;
UPDATE 1
lzldb=# select lp,t_ctid from heap_page_items(get_raw_page('lzl1',0));
 lp | t_ctid 
----+--------
 1 | (0,2)
 2 | (0,2)

lp源码在src/include/storage/itemid.h中，ItemIdData结构保存了元组的offset位置，状态，长度

typedef struct ItemIdData
{
	unsigned	lp_off:15,		/* 元组在页面的偏移量 */
				lp_flags:2,		/* lp的状态 */
				lp_len:15;		/* 元组的长度 */
} ItemIdData;
typedef ItemIdData *ItemId;*

*
/* lp_off:15代表位域，lp_off占用unsigned中的15位，3个定义加起来总共32位。所以ItemIdData是int类型，4个字节，共32位 */

lp_flags定义了4种状态

/*
 *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		/* lp没有被使用，元组长度pl_len总是为0 */
#define LP_NORMAL		1		/* lp正在使用，元组长度pl_len总是>0 */
#define LP_REDIRECT		2		/* HOT redirect重定向到其他lp (should have lp_len=0) */
#define LP_DEAD			3		/* dead的lp，可被vacuum */

lzldb=# select lp,lp_flags,lp_off,lp_len from heap_page_items(get_raw_page('lzl1',0));
 lp | lp_flags | lp_off | lp_len 
----+----------+--------+--------
 1 | 1 | 8160 | 28

infomask
#

infomask提供了事务、锁、元组状态等信息，比如提交、终止、锁、HOT信息等等。header中有两个infomask：infomask和infomask2。他们存储的信息有所不同

infomask,infomask2
#

infomask源码还是在src/include/access/htup_details.h

#define FIELDNO_HEAPTUPLEHEADERDATA_INFOMASK2 2
	uint16		t_infomask2;	/* number of attributes + various flags */

#define FIELDNO_HEAPTUPLEHEADERDATA_INFOMASK 3
	uint16		t_infomask;		/* various flag bits, see below */

infomask的标识含义
#

/*
 * information stored in t_infomask:
 */
#define HEAP_HASNULL			0x0001	/* 元组中是否有null值 */
#define HEAP_HASVARWIDTH		0x0002	/* 元组是否是变长的，如varchar类型 */
#define HEAP_HASEXTERNAL		0x0004	/* 是否有toast存储 */
#define HEAP_HASOID_OLD			0x0008	/* 元组是否有OID */
#define HEAP_XMAX_KEYSHR_LOCK	0x0010	/* 元组是否有for key-share锁 */
#define HEAP_COMBOCID			0x0020	/* t_cid是否是comboCID */
#define HEAP_XMAX_EXCL_LOCK		0x0040	/* 元组是否有for update锁 */
#define HEAP_XMAX_LOCK_ONLY		0x0080	/* xmax只起锁作用 */

 /* xmax is a shared locker */
#define HEAP_XMAX_SHR_LOCK	(HEAP_XMAX_EXCL_LOCK | HEAP_XMAX_KEYSHR_LOCK)

#define HEAP_LOCK_MASK	(HEAP_XMAX_SHR_LOCK | HEAP_XMAX_EXCL_LOCK | \
						 HEAP_XMAX_KEYSHR_LOCK)
#define HEAP_XMIN_COMMITTED		0x0100	/* t_xmin对应的插入元组的事务已提交 */
#define HEAP_XMIN_INVALID		0x0200	/* t_xmin对于的插入元组的事务无效或终止 */
#define HEAP_XMIN_FROZEN		(HEAP_XMIN_COMMITTED|HEAP_XMIN_INVALID)
#define HEAP_XMAX_COMMITTED		0x0400	/* t_xmax对于的删除元组的事务是否提交 */
#define HEAP_XMAX_INVALID		0x0800	/* t_xmax对于的删除元组的事务无效或终止 */
#define HEAP_XMAX_IS_MULTI		0x1000	/* t_xmax是否使用MultiXactId */
#define HEAP_UPDATED			0x2000	/* 该元组是数据行被更新后的版本 */
#define HEAP_MOVED_OFF			0x4000	/* 被 9.0 之前的 VACUUM FULL 移动到另外的地方，为了兼容二进制程序升级而保留 */
#define HEAP_MOVED_IN			0x8000	/* 与 HEAP_MOVED_OFF 相对，表明是从别处移动过来的，也是为了兼容性而保留 */
#define HEAP_MOVED (HEAP_MOVED_OFF | HEAP_MOVED_IN)
#define HEAP_XACT_MASK			0xFFF0	/* 可见性相关位 */

infomask2的标识含义
#

#define HEAP_NATTS_MASK			0x07FF	/* 有11位用来保存元组的列的数量，（MaxHeapAttributeNumber用户的列长度是1600个）*/
/* bits 0x1800 are available */
#define HEAP_KEYS_UPDATED		0x2000	/* 元组更新或者删除 */
#define HEAP_HOT_UPDATED		0x4000	/* 元组更新后，新元组是HOT */
#define HEAP_ONLY_TUPLE			0x8000	/* HOT tuple */
#define HEAP2_XACT_MASK			0xE000	/* 可见性相关位 */
#define HEAP_TUPLE_HAS_MATCH	HEAP_ONLY_TUPLE 
/*在 Hash Join 中临时使用的标志，只用于 Hash 表中的 tuple，且不需要可见性信息，所以我们可以用一个可见性标志覆盖他，而不是使用一个单独的位 */

infomask的位与位计算
#

把16进制转换为2进制，就比较容易理解位所代表的含义

--将16进制的1600转换为2进制
lzldb=# select x'1600'::bit(16);
 bit 
------------------
 0001011000000000

infomask：

0000000000000001 0x0001 HEAP_HASNULL			
0000000000000010 0x0002 HEAP_HASVARWIDTH		
0000000000000100 0x0004 HEAP_HASEXTERNAL		
0000000000001000 0x0008 HEAP_HASOID_OLD			
0000000000010000 0x0010 HEAP_XMAX_KEYSHR_LOCK	
0000000000100000 0x0020 HEAP_COMBOCID
0000000001000000 0x0040 HEAP_XMAX_EXCL_LOCK
0000000010000000 0x0080 HEAP_XMAX_LOCK_ONLY		
0000000001010000 0x0050 HEAP_XMAX_SHR_LOCK 位或计算一下(HEAP_XMAX_EXCL_LOCK | HEAP_XMAX_KEYSHR_LOCK)=10|40=50
0000000001010000 0x0050 HEAP_LOCK_MASK 位或计算一下(HEAP_XMAX_SHR_LOCK | HEAP_XMAX_EXCL_LOCK | HEAP_XMAX_KEYSHR_LOCK)=50|40|10=50
0000000100000000 0x0100 HEAP_XMIN_COMMITTED		
0000001000000000 0x0200 HEAP_XMIN_INVALID		
0000001100000000 0x0300 HEAP_XMIN_FROZEN 位或计算一下(HEAP_XMIN_COMMITTED|HEAP_XMIN_INVALID)=100|200=300
0000010000000000 0x0400 HEAP_XMAX_COMMITTED		
0000100000000000 0x0800 HEAP_XMAX_INVALID		
0001000000000000 0x1000 HEAP_XMAX_IS_MULTI		
0010000000000000 0x2000 HEAP_UPDATED			
0100000000000000 0x4000 HEAP_MOVED_OFF			
1000000000000000 0x8000 HEAP_MOVED_IN			
1100000000000000 0xC000 HEAP_MOVED 位或计算一下(HEAP_MOVED_OFF | HEAP_MOVED_IN)=4000|8000=C000
1111111111110000 0xFFF0 HEAP_XACT_MASK

infomask2:

0000011111111111 0x07FF HEAP_NATTS_MASK pg库的列最多有1600个=0000011001000000，所以前11位保存元组列足够
0001100000000000 0x1800 available位，看上去是空闲不用的
0010000000000000 0x2000 HEAP_KEYS_UPDATED 
0100000000000000 0x4000 HEAP_HOT_UPDATED 
1000000000000000 0x8000 HEAP_ONLY_TUPLE 
1110000000000000 0xE000 HEAP2_XACT_MASK

怎么计算infomask？
#

infomask的标识是16进制，pageinspect插件查infomask出来的是10进制。需要to_hex()，10进制转换为16进制的函数，做一个转换

lzldb=# select lp,t_ctid,to_hex(t_infomask) infomask,to_hex(t_infomask2) infomask2 from heap_page_items(get_raw_page('lzl1',0));
 lp | t_ctid | infomask | infomask2 
----+--------+----------+-----------
 1 | (0,1) | 2b00 | 1

infomask=2b00，还是有点转不过来，转成16进制有点难凑，转成二进制对着上面的位含义再凑一下0010101100000000=HEAP_UPDATED+HEAP_XMAX_INVALID+HEAP_XMIN_FROZEN
其含义为：标识元组更新过，xmax为invalid也就是0，xmin frozen对所有事务可见 infomask2=1，二进制的前11位，十进制的前2047（最多1600列），都是代表用户列的个数，所以1代表只有1个列

手动算infomask有点麻烦，从pg13开始pageinspect提供了函数heap_tuple_infomask_flags转换infomask,infomask2的含义。有单独位标识的是raw flag,联合多个位标识的是combined_flags

lzldb=# SELECT t_ctid, raw_flags, combined_flags
 FROM heap_page_items(get_raw_page('lzl1', 0)),
 LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2)
 WHERE t_infomask IS NOT NULL OR t_infomask2 IS NOT NULL;
 t_ctid | raw_flags | combined_flags 
--------+------------------------------------------------------------------------+--------------------
 (0,1) | {HEAP_XMIN_COMMITTED,HEAP_XMIN_INVALID,HEAP_XMAX_INVALID,HEAP_UPDATED} | {HEAP_XMIN_FROZEN}

提交日志clog
#

pg用提交日志（commit log，clog）来保存事务状态。pg会在事务完成前就将事务写进wal日志，这也是wal的含义。如果终止事务，将事务状态写进wal和clog，在实例恢复时，也能知道事务是没有完成提交的。在需要获取事务状态时，比如判断事务可见性时，pg会读取clog的事务状态。 事务状态 源码src/include/access/clog.h

#define TRANSACTION_STATUS_IN_PROGRESS		0x00
#define TRANSACTION_STATUS_COMMITTED		0x01
#define TRANSACTION_STATUS_ABORTED			0x02
#define TRANSACTION_STATUS_SUB_COMMITTED	 0x03

clog中事务定义了4种状态：IN_PROGRESS,COMMITTED,ABORTD,SUB_COMMITTED 事务状态大小 源码src/backend/access/transam/clog.c

/* We need two bits per xact, so four xacts fit in a byte */
#define CLOG_BITS_PER_XACT	2
#define CLOG_XACTS_PER_BYTE 4
#define CLOG_XACTS_PER_PAGE (BLCKSZ * CLOG_XACTS_PER_BYTE)
#define CLOG_XACT_BITMASK	((1 << CLOG_BITS_PER_XACT) - 1)

事务状态非常小，一个事务只需要2位，1字节可以保存4个事务状态一个标准的page可以保留 8K*4=32768个事务状态 clog持久化 pg关库或落盘时，clog数据会写入pg_clog目录下，在10.0及以后的版本，pg_clog重命名为pg_xact。

[pg@lzl pg_xact]$ ll
total 8
-rw------- 1 pg pg 8192 Mar 28 23:33 0000

磁盘上的clog文件命名为0000，0001等。 clog文件大小为256KB，而内存中通过page存储事务为8K，所以0000文件的大小只会是8192的倍数，当写了32个clog page后，下个page便写入0001文件。PostgreSQL 启动时会从 pg_xact 中读取事务的状态加载至内存。系统运行过程中，并不是所有事务的状态都需要长期保留在 CLOG 文件中，因此 vacuum 操作会定期将不再使用的 CLOG 文件删除

Hint Bits
#

什么是hintbits？
#

hint bits是为了标记那些创建或删除的行的事务是否提交或终止。如果没有hint bits，事务可见性需要访问磁盘pg_clog或pg_subtrans，这种访问代价比较昂贵。如果元组被设置了hint bits，那么访问page中的元组，就能知道元组状态，不需要额外的访问。源码中使用SetHintBits()函数设置hintbits 如

SetHintBits(tuple, buffer, HEAP_XMIN_COMMITTED,
			InvalidTransactionId);

SetHintBits设置的只是infomask中的2位，共4种hint bits（其实这2位infomask还有一个联合标识HEAP_XMIN_FROZEN，能看出来hintbits就是单纯为了标记事务状态的）

#define HEAP_XMIN_COMMITTED	0x0100	/* t_xmin对应的插入或更新事务已提交 */
#define HEAP_XMIN_INVALID		0x0200	/* t_xmin对于的插入或更新事务无效或终止 */
#define HEAP_XMAX_COMMITTED		0x0400	/* t_xmax对于的删除或更新事务是否提交 */
#define HEAP_XMAX_INVALID		0x0800	/* t_xmax对于的删除或更新事务无效或终止 */

查询会产生写入
#

事务开始后，pg的dml事务会在元组header中记录t_min等事务id和事务状态。但事务结束时，不会在header中作任何事情，而是在后面的DML或者DQL，VACUUM等SQL扫描到对应的TUPLE时，触发SetHintBits的操作（产生新快照访问数据时SetHintBits，代码在HeapTupleSatisfiesMVCC()中，后面可见性规则小节会介绍）。

在没有触发SetHintBits之前，pg在clog中寻找事务状态；触发SetHintBits后，在数据页的元组header中找hintbits所代表的事务状态。例如一个insert语句

lzldb=# insert into lzl1 values(1);
INSERT 0 1
lzldb=# SELECT t_ctid, raw_flags, combined_flags
lzldb-# FROM heap_page_items(get_raw_page('lzl1', 0)),
lzldb-# LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2)
lzldb-# WHERE t_infomask IS NOT NULL OR t_infomask2 IS NOT NULL;
 t_ctid | raw_flags | combined_flags 
--------+---------------------+----------------
 (0,1) | {HEAP_XMAX_INVALID} | {}
(1 row)

lzldb=# select * from lzl1; --仅做一次查询
a 
---
 1
(1 row)
lzldb=# SELECT t_ctid, raw_flags, combined_flags
 FROM heap_page_items(get_raw_page('lzl1', 0)),
 LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2)
 WHERE t_infomask IS NOT NULL OR t_infomask2 IS NOT NULL;
 t_ctid | raw_flags | combined_flags 
--------+-----------------------------------------+----------------
 (0,1) | {HEAP_XMIN_COMMITTED,HEAP_XMAX_INVALID} | {} 

一次查询后，t_infomask发生了变化，说明tuple header发生了变化。在insert后，SetHintBits只有HEAP_XMAX_INVALID，因为insert本身只会更新xmin，无论事物是否提交或终止（退出或rollback）xmax都是没用的，可以随事务一起SetHintBits为HEAP_XMAX_INVALID 但是事务可能提交，也可能终止（退出或rollback），又由于事务完成不会更新元组，所以HEAP_XMIN_COMMITTED不能随事务完成而SetHintBits 在检测事务可见性（heapam_visibility.c）时，可见性检测更新了元组的事务状态SetHintBits到t_infomask中，所以查询更新了HEAP_XMIN_COMMITTED

hintbits优点：事务中数据更新的完成（包括失败），不会对元组产生任何写入。提交和回退会非常快。

hintbits缺点：如果一个事务更新了多行，下一次查询检测可见性时可能会从pg_clog中读取事务状态，并更新非常多的page。

hintbits是否会产生WAL日志？
#

在开启 checksum 或者参数 wal_log_hints 为 true 的情况下，如果 checkpoint 后第一次使页面 dirty 的操作是更新 Hint Bits，则会产生一条 WAL 日志，将当前页面写入 WAL 日志中(即 Full Page Image)，避免产生部分写，导致数据 checksum 异常。因此，在开启 checksum 或者参数 wal_log_hints 为 true 时，即便执行 SELECT，也可能更改页面的 Hint Bits，从而导致产生 WAL 日志，这会在一定程度上增加 WAL 日志占用的存储空间。如果在使用pg中发现执行SELECT会触发磁盘的写入操作，可以检查一下是否开启了CHECKSUM或者wal_log_hints。

hintbits为什么延迟更新？
#

源码src/backend/access/heap/heapam_visibility.c里，在可见性规则HeapTupleSatisfiesMVCC()注释中有一段hintbits为什么延迟更新的解释

/*
*插入、删除操作还在跑时，哪怕事务已提交或者回退，都不会更新元组上的hint bits，也就是更新事务状态
*因为在高并发场景下共享数据结构可能会造成争用，而且这也不会影响可见性判断
*hintbits只会发生在首次全新快照访问已完成事务的数据之后
*所以HeapTupleSatisfiesMVCC每次都会运行TransactionIdIsCurrentTransactionId，XidInMVCCSnapshot，以判断是否当前事务的元组
*在老版本中，pg尝试立即更新hintbits（即使事务在运行中），但是造成对PGXACT array的更多争用 
*/

简单点说，hintbits立即更新性能非常差，所以将事务状态先放在clog，减少PGXACT的争用，以提升性能。hintbits延迟更新就造成了后续查询可能会更新元组的情况

元组的增删改
#

在积累了元组header、系统列、clog、hintbits等知识点后，我们来看下pg是如何完成增删改操作。

观察DML事务
#

通过对lp,lp_flags,ctid,xmin,xmax,cid(cmin,cmax),infomask,infomask2这些元组头部信息，观察pg的DML事务行为观察这些内容会使用以下sql

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 from heap_page_items(get_raw_page('lzl1',0)) item,LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2) info order by lp;

(稍微说下，有些资料里喜欢这样SELECT '(0,'||lp||')' AS ctid,这样写不太合适，lp跟ctid是两码事，lp相当于行号，ctid是指向行号的，lp是可以不等于ctid的）为了更好的阅读，创建一个view简化一下sql

create view vlzl1 as 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 from heap_page_items(get_raw_page('lzl1',0)) item,LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2) info order by lp;

查询就像这样

lzldb=# \x
Expanded display is on.
lzldb=# select * from vlzl1;
-[ RECORD 6 ]--+-------
t_ctid | (0,6)
lp | 6
lp_flags | LP_NORMAL
t_xmin | 653
t_xmax | 0
t_cid | 0
raw_flags | {HEAP_XMAX_INVALID,HEAP_UPDATED,HEAP_ONLY_TUPLE}
combined_flags | {}

插入
#

清空数据，insert插入一行

lzldb=# begin ;
BEGIN
lzldb=*# insert into lzl1 values(1);
INSERT 0 1
lzldb=*# insert into lzl1 values(2);
INSERT 0 1
lzldb=*# commit;
lzldb=# select * from vlzl1;
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags 
--------+----+-----------+--------+--------+-------+---------------------+----------------
 (0,1) | 1 | LP_NORMAL | 664 | 0 | 0 | {HEAP_XMAX_INVALID} | {}
 (0,2) | 2 | LP_NORMAL | 664 | 0 | 1 | {HEAP_XMAX_INVALID} | {}

ctid指向(page 0,lp 1)，也就指向自身 lp，line pointer行指针编号，递增 2个元组xmin是同一个事务，表示2个元组是一个事务插入 xmax为0表示无效事务ID，infomask也仅说明xmax无效，该元组还没有"经历"删除事务 cid从0开始递增，0代表事务第一个command，1代表事务第二个command

删除
#

lzldb=# begin;
BEGIN
lzldb=*# delete from lzl1 where a=1;
DELETE 1
lzldb=*# commit;
COMMIT
lzldb=# select * from vlzl1;
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags 
--------+----+-----------+--------+--------+-------+-----------------------------------------+----------------
 (0,1) | 1 | LP_NORMAL | 664 | 665 | 0 | {HEAP_XMIN_COMMITTED,HEAP_KEYS_UPDATED} | {}
 (0,2) | 2 | LP_NORMAL | 664 | 0 | 1 | {HEAP_XMIN_COMMITTED,HEAP_XMAX_INVALID} | {}

删除了第一个元组，元组没有物理上删除，只是几个属性打了标记 ctid未变还是指向自身 xmax更新为删除事务id infomask标识有HEAP_KEYS_UPDATED表示元组删除了（实际上HEAP_KEYS_UPDATED的有删除或更新的意思）虽然只更新了第一个元组，但是第二个元组更新了infomask HEAP_XMIN_COMMITTED

更新
#

lzldb=# begin;
BEGIN
lzldb=# update lzl1 set a=3;
UPDATE 1
lzldb=*# commit;
COMMIT
lzldb=# select * from vlzl1;
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags 
--------+----+-----------+--------+--------+-------+-------------------------------------------------------------+----
 (0,1) | 1 | LP_NORMAL | 664 | 665 | 0 | {HEAP_XMIN_COMMITTED,HEAP_XMAX_COMMITTED,HEAP_KEYS_UPDATED} | {}
 (0,3) | 2 | LP_NORMAL | 664 | 666 | 0 | {HEAP_XMIN_COMMITTED,HEAP_HOT_UPDATED} | {}
 (0,3) | 3 | LP_NORMAL | 666 | 0 | 0 | {HEAP_XMAX_INVALID,HEAP_UPDATED,HEAP_ONLY_TUPLE} | {}

更新事务不会再元组上操作，而是将老元组标识为不可用，新增一个新元组 lp=2 为更新事务的老元组，t_xmax更新为更新事务id，infomask增加标识HEAP_HOT_UPDATED，表示该元组是hot，ctid指向了新元组 lp=3 为更新事务的新元组，相当于插入了一个新元组，不过xmin事务id跟老元组xmax一致，并且infomask有额外标识HEAP_UPDATED表示该元组是update后的row 另外，一个看不见的被删除的元组 lp=1，在不相关的更新事务发生后，infomask增加了标识HEAP_XMAX_COMMITTED

回退
#

lzldb=# truncate table lzl1;
TRUNCATE TABLE
lzldb=# begin;
BEGIN
lzldb=*# insert into lzl1 values(1); --插入
INSERT 0 1
lzldb=*# select * from vlzl1;
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags 
--------+----+-----------+--------+--------+-------+---------------------+----------------
 (0,1) | 1 | LP_NORMAL | 679 | 0 | 0 | {HEAP_XMAX_INVALID} | {}
(1 row)
lzldb=*# rollback; --插入回退
ROLLBACK
lzldb=# select * from vlzl1;
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags 
--------+----+-----------+--------+--------+-------+---------------------+----------------
 (0,1) | 1 | LP_NORMAL | 679 | 0 | 0 | {HEAP_XMAX_INVALID} | {}
lzldb=# select * from lzl1;
 a 
---

(0 rows)
--插入后回退，元组header信息没有任何变化

lzldb=# insert into lzl1 values(2);
INSERT 0 1
lzldb=# begin ;
BEGIN
lzldb=*# delete from lzl1 ; --删除
DELETE 1
lzldb=*# select * from vlzl1;
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags 
--------+----+-----------+--------+--------+-------+-----------------------------------------+----------------
 (0,1) | 1 | LP_NORMAL | 684 | 0 | 0 | {HEAP_XMIN_INVALID,HEAP_XMAX_INVALID} | {}
 (0,2) | 2 | LP_NORMAL | 685 | 686 | 0 | {HEAP_XMIN_COMMITTED,HEAP_KEYS_UPDATED} | {}
(2 rows)

lzldb=*# rollback; --删除回退
ROLLBACK
lzldb=# select * from vlzl1;
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags 
--------+----+-----------+--------+--------+-------+-----------------------------------------+----------------
 (0,1) | 1 | LP_NORMAL | 684 | 0 | 0 | {HEAP_XMIN_INVALID,HEAP_XMAX_INVALID} | {}
 (0,2) | 2 | LP_NORMAL | 685 | 686 | 0 | {HEAP_XMIN_COMMITTED,HEAP_KEYS_UPDATED} | {}
--删除后回退，元组header信息没有任何变化

lzldb=*# update lzl1 set a=100 ; --更新
UPDATE 1
lzldb=*# select * from vlzl1; 
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags 
--------+----+-----------+--------+--------+-------+--------------------------------------------------+---------------
 (0,1) | 1 | LP_NORMAL | 684 | 0 | 0 | {HEAP_XMIN_INVALID,HEAP_XMAX_INVALID} | {}
 (0,3) | 2 | LP_NORMAL | 685 | 688 | 0 | {HEAP_XMIN_COMMITTED,HEAP_HOT_UPDATED} | {}
 (0,3) | 3 | LP_NORMAL | 688 | 0 | 0 | {HEAP_XMAX_INVALID,HEAP_UPDATED,HEAP_ONLY_TUPLE} | {}
(3 rows)
lzldb=*# rollback; --更新回退
ROLLBACK
lzldb=*# select * from vlzl1; 
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags 
--------+----+-----------+--------+--------+-------+--------------------------------------------------+---------------
 (0,1) | 1 | LP_NORMAL | 684 | 0 | 0 | {HEAP_XMIN_INVALID,HEAP_XMAX_INVALID} | {}
 (0,3) | 2 | LP_NORMAL | 685 | 688 | 0 | {HEAP_XMIN_COMMITTED,HEAP_HOT_UPDATED} | {}
 (0,3) | 3 | LP_NORMAL | 688 | 0 | 0 | {HEAP_XMAX_INVALID,HEAP_UPDATED,HEAP_ONLY_TUPLE} | {}
--更新后回退，元组header信息没有任何变化

• 事务回退，元组信息不会有任何变化。这也是为什么pg的mvcc不用担心回滚段不够用，因为回滚只是可见性操作，不会更新数据本身 • xmax在回退后也没有变，说明xmax有值不一定代表元组被删除，也可能是删除或更新事务回退了 • 但是，只要产生了可见性检测，哪怕不产生数据变化，所有元组的infomask都会更新HEAP_XMIN_INVALID。其中非HOT元组都加上HEAP_XMIN_INVALID，HOT指向的元组当然也是HEAP_XMIN_INVALID

参考 books：《postgresql指南内幕探索》《postgresql实战》《postgresql技术内幕事务处理深度探索》《postgresql数据库内核分析》 https://edu.postgrespro.com/postgresql_internals-14_parts1-2_en.pdf 官方资料： https://en.wikipedia.org/wiki/Concurrency_control https://wiki.postgresql.org/wiki/Hint_Bits https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND https://www.postgresql.org/docs/10/storage-page-layout.html https://www.postgresql.org/docs/13/pageinspect.html3 pg事务必读文章 interdb https://www.interdb.jp/pg/pgsql05.html https://www.interdb.jp/pg/pgsql06.html 源码大佬 https://blog.csdn.net/Hehuyi_In/article/details/102920988 https://blog.csdn.net/Hehuyi_In/article/details/127955762 https://blog.csdn.net/Hehuyi_In/article/details/125023923 pg的快照优化性能对比 https://techcommunity.microsoft.com/t5/azure-database-for-postgresql/improving-postgres-connection-scalability-snapshots/ba-p/1806462 其他资料 https://brandur.org/postgres-atomicity https://mp.weixin.qq.com/s/j-8uRuZDRf4mHIQR_ZKIEg

pg中的快照
#

快照（snapshot）是记录数据库当前瞬时状态的一个数据结构。pg数据库的快照保存当前所有活动事务的最小事务ID、最大事务ID、当前活跃事务列表、当前事务的command id等快照数据保存在SnapshotData结构体类型中，源码src/include/utils/snapshot.h

typedef struct SnapshotData
{
	SnapshotType snapshot_type; /* 快照类型 */
TransactionId xmin;			/* 事务ID小于xmin，对于快照可见 */
TransactionId xmax;			/* 事务ID大于xmax，对于快照不可见 */

/* 获取快照时活跃事务列表。该列表仅包括xmin与xmax之间的txid */
TransactionId *xip;
uint32		xcnt;			/* xip_list保存在xip[] */

/* 获取快照时活跃子事务列表 */
TransactionId *subxip;
int32		subxcnt;		/* 子事务保存在subxip[] */
bool		suboverflowed;	/* 子事务是否溢出，子事务较多时会产生溢出 */

bool		takenDuringRecovery;	/* 是否是恢复快照recovery-shaped snapshot? */
bool		copied;			/* 这里应该是快照是否是copy的（可重复读和串行化隔离级别，会copy快照）false if it's a static snapshot */

CommandId	curcid;			/* 事务中的command id，CID< curcid的可见 */
...
TimestampTz whenTaken;		/* 生成快照的时间戳 */
XLogRecPtr	lsn;			/* 生成快照的LSN */
} SnapshotData;
typedef struct SnapshotData *Snapshot;

快照中最重要的信息是xmin、xmax、xip_list。通过pg_current_snapshot()（pg12及以前用 txid_current_snapshot () ）显示当前事务的快照。

注意区分快照xmin、xmax跟元组上的xmin、xmax，含义是不一样的。

lzldb=*# select pg_current_snapshot();
 pg_current_snapshot 
---------------------
 100:104:100,102

xmin	最早活跃的txid，所有比他更早的事务txid<xmin，要么提交和可见，要么回滚并成为死元组
xmax	第一个尚未分配的txid，xmax=latestCompletedXid+1，所有txid>=xmax的事务都未启动并对当前快照不可见
xip_list	xip_list存储在数组xip[]中。因为所有事务开始顺序性和完成顺序不一定是一致的，晚开始的事务可能早完成，所以只有xmin和xmax不能完全表达获取快照时的所有活动事务。xip_list保存获得快照时的活动事务

快照类型
#

除了mvcc快照以外，pg在src/include/utils/snapshot.h中还定义了一些其他的快照类型

typedef enum SnapshotType
{
	/* 当且仅当元组符合mvcc快照可见规则时，元组可见
 * 最重要的一种快照事务，是pg用来实现mvcc的快照类型
 * 元组可见性基于事务快照的xmin,xmax,xip_list,curcid等信息进行判断
 * 如果命令发生了数据变更，当前mvcc快照是看不到的，需要再生成mvcc快照
 */
SNAPSHOT_MVCC = 0,
/* 元组上的事务已提交，则可见
 * 进行中的事务不可见
 * 命令发生了数据变更，当前self快照可以看见
 */
SNAPSHOT_SELF,

/*
 * 任何元组都可见
 */
SNAPSHOT_ANY,

/*
 * toast重要是有效的就可见。toast可见性依赖主表的元组可见性
 */
SNAPSHOT_TOAST,

/*
 * 命令发生了数据变更，当前dirty快照可以看见
 * dirty快照会保存当前进行中元组的版本信息
 * 快照xmin会设置成其他进行中事务的元组xmin，xmax类似
 */
SNAPSHOT_DIRTY,

/* HISTORIC_MVCC快照规则与MVCC快照一致，用于逻辑解码
 */
SNAPSHOT_HISTORIC_MVCC,

/*
	判断死元组是否对一些事务可见
 */
SNAPSHOT_NON_VACUUMABLE
} SnapshotType;

快照与隔离级别
#

不同的隔离级别，快照获取方式是不一样的

rc模式需要事务中的每个sql都获得快照，而rr模式在事务中只使用一个快照。获得快照的方法在GetTransactionSnapshot()函数中。

进程上的事务结构体
#

pg在获得快照数据的时候，需要检索所有backend进程的事务状态。

所以在理解获得快照数据函数GetSnapshotData()之前，需要先理解几个在关于backend process的结构体。这些结构体包括PGPROC、PGXACT、PROC_HDR(PROCGLOBAL)、ProcArray

这些process相关结构体包含一些进程、锁等信息，这里只研究process里事务相关的信息。源码以pg13源码为示例

PGPROC结构体
#

源码src/include/storage/proc.h

//每个backend进程在内存中都存储PGPROC结构体
//可以理解为backend进程的主结构体
struct PGPROC
{
...
LocalTransactionId lxid;	/* local id of top-level transaction currently
								 * being executed by this proc, if running;
								 * else InvalidLocalTransactionId */
...
struct XidCache subxids;	/* 缓存子事务XIDs */
...
/* clog组事务状态更新 */
bool		clogGroupMember;	/* 当前proc是否使用clog组提交 */
pg_atomic_uint32 clogGroupNext; /* 原子int，指向下一个组成员proc */
TransactionId clogGroupMemberXid;	/* 当前要提交的xid */
XidStatus	clogGroupMemberXidStatus;	/* 当前要提交xid的状态 */
int			clogGroupMemberPage;	/* 当前要提交xid属于哪个page*/
									
XLogRecPtr	clogGroupMemberLsn; /* 当前要提交的xid的commit日志的lsn号 */
};
/* NOTE: "typedef struct PGPROC PGPROC" appears in storage/lock.h. 居然不跟结构体写在一起*/

PGXACT结构体
#

//在9.2以前，PGXACT的信息在PGPROC中，由于压测显示在多cpu系统中，因为减少了获取的缓存行数，把两者分开GetSnapshotData会更快，
typedef struct PGXACT
{
	TransactionId xid;			/* id of top-level transaction currently being
								 * executed by this proc, if running and XID
								 * is assigned; else InvalidTransactionId */
								// 看上是当前进程的xmax

	TransactionId xmin;			/* 不包括lazy vaccum，事务开始时最小xid，vacuum无法删除xid >= xmin的元组*/
	uint8		vacuumFlags;	/* vacuum-related flags, see above */
	bool		overflowed; //PGXACT是否溢出

	uint8		nxids;
} PGXACT;

能看出pgxact保存的信息比较简单，是backend的xmin、xmax等事务相关信息。而pgproc更倾向于保存backend的基本信息，pgproc中还是有一部分不太频繁调用的事务信息，不过最核心的进程事务信息在pgxact中

PROC_HDR(PROCGLOBAL)结构体
#

每个backend process都有proc结构体，很明显在高并发场景下扫描所有proc寻找事务信息比较耗时，这时需要一个实例级别的结构体存储所有proc信息，这个结构体就是PROCGLOBAL**。**

源码一般用结构体类型PROC_HDR定义结构体指针指向PROCGLOBAL。PROC_HDR存储的是全局的proc信息，所有proc数组列表、空闲proc等等

源码位置src/include/storage/proc.h

typedef struct PROC_HDR
{
	/* pgproc数组 (not including dummies for prepared txns) */
	PGPROC	 *allProcs;
	/* pgxact数组 (not including dummies for prepared txns) */
	PGXACT	 *allPgXact;
	...
	/* Current shared estimate of appropriate spins_per_delay value */
	int			spins_per_delay;
	/* The proc of the Startup process, since not in ProcArray */
	PGPROC	 *startupProc;
	int			startupProcPid;
	/* Buffer id of the buffer that Startup process waits for pin on, or -1 */
	int			startupBufferPinWaitBufId;
} PROC_HDR;

PROCARRAY结构体
#

procarray在procarray.c中，procarray.c是维护所有backend的PGPROC和PGXACT结构的。

源码位置src/backend/storage/ipc/procarray.c

typedef struct ProcArrayStruct
{
	int			numProcs;		/* proc的个数*/
	int			maxProcs;		/* proc array的大小 */

	//处理已分配的xid
	int			maxKnownAssignedXids;	/* allocated size of array */
	int			numKnownAssignedXids;	/* current # of valid entries */
	int			tailKnownAssignedXids;	/* index of oldest valid element */
	int			headKnownAssignedXids;	/* index of newest element, + 1 */
	slock_t		known_assigned_xids_lck;	/* protects head/tail pointers */

	/*
	 * Highest subxid that has been removed from KnownAssignedXids array to
	 * prevent overflow; or InvalidTransactionId if none. We track this for
	 * similar reasons to tracking overflowing cached subxids in PGXACT
	 * entries. Must hold exclusive ProcArrayLock to change this, and shared
	 * lock to read it.
	 */
	TransactionId lastOverflowedXid;

	/* oldest xmin of any replication slot */
	TransactionId replication_slot_xmin;
	/* oldest catalog xmin of any replication slot */
	TransactionId replication_slot_catalog_xmin;

	/* pgprocnos，相当于allPgXact[]数组下标，可用于检索allPgXact[]，该数组有PROCARRAY_MAXPROCS条目 */
	int			pgprocnos[FLEXIBLE_ARRAY_MEMBER];
} ProcArrayStruct;
static ProcArrayStruct *procArray;

获得快照
#

GetTransactionSnapshot()
#

通过函数GetTransactionSnapshot()获得快照

源码src/backend/utils/time/snapmgr.c

// GetTransactionSnapshot()为一个事务中的sql分配合适的快照
Snapshot
GetTransactionSnapshot(void)
{

	 // 如果是逻辑解码，则获得historic类型快照Return historic snapshot if doing logical decoding. We'll never need a
	 // 因为是逻辑解码事务，后续就不需要再call非historic类型快照了，直接return
	if (HistoricSnapshotActive())
	{
		Assert(!FirstSnapshotSet);
		return HistoricSnapshot;
	}

	/* 如果不是事务的第一次调用，则进入if */
	if (!FirstSnapshotSet)
	{
		/*
		 * 保证catalog快照是新的
		 */
		InvalidateCatalogSnapshot();

		Assert(pairingheap_is_empty(&RegisteredSnapshots));
		Assert(FirstXactSnapshot == NULL);
	//如果是并行模式下则返回报错
		if (IsInParallelMode())
			elog(ERROR,
				 "cannot take query snapshot during a parallel operation");

		 //如果是可重复读或串行化隔离级别，则在事务中都使用同一个快照，所以只copy一次
		 //IsolationUsesXactSnapshot()标识隔离级别为可重复读或串行化，他们的在同事务中只使用一个快照
		if (IsolationUsesXactSnapshot())
		{
			//首先，在CurrentSnapshotData中创建快照 
			//如果是SI隔离级别，初始化SSI所需的数据结构
			if (IsolationIsSerializable()) 
				CurrentSnapshot = GetSerializableTransactionSnapshot(&CurrentSnapshotData);
			else
				CurrentSnapshot = GetSnapshotData(&CurrentSnapshotData);
			/* Make a saved copy */
			/* 可重复读或串行化隔离级别，这个快照会贯穿整个事务，所以只复制一次 */
			CurrentSnapshot = CopySnapshot(CurrentSnapshot);
			FirstXactSnapshot = CurrentSnapshot;
			/* Mark it as "registered" in FirstXactSnapshot */
			FirstXactSnapshot->regd_count++;
			pairingheap_add(&RegisteredSnapshots, &FirstXactSnapshot->ph_node);
		}
		else
			//如果是读已提交隔离级别，获得快照
			CurrentSnapshot = GetSnapshotData(&CurrentSnapshotData);

// 修改标记，表示是第一次获得的快照，下次事务再调用该函数，就不会进到这层if了
		FirstSnapshotSet = true;
		return CurrentSnapshot;
	}

//如果不是事务中第一次调用（已经有第一个快照了）
//可重复读或串行化隔离级别，返回第一个快照的复制品
	if (IsolationUsesXactSnapshot())
		return CurrentSnapshot;

	/* Don't allow catalog snapshot to be older than xact snapshot. */
	InvalidateCatalogSnapshot();
	//读已提交级别，重新获得快照
	CurrentSnapshot = GetSnapshotData(&CurrentSnapshotData);

	return CurrentSnapshot;
}

关于IsolationUsesXactSnapshot()和IsolationIsSerializable()

在src/include/access/xact.h宏定义

#define XACT_READ_UNCOMMITTED	0
#define XACT_READ_COMMITTED	1
#define XACT_REPEATABLE_READ	2
#define XACT_SERIALIZABLE	3
//内部只有3个隔离级别，就是1、2、3
//2个隔离级别在每个事务中用同一快照，其他隔离级别在每个sql语句用一个快照
#define IsolationUsesXactSnapshot() (XactIsoLevel >= XACT_REPEATABLE_READ)
#define IsolationIsSerializable() (XactIsoLevel == XACT_SERIALIZABLE)

IsolationUsesXactSnapshot()是可重复读或串行化隔离级别

IsolationIsSerializable()是串行化隔离级别。

GetTransactionSnapshot()函数流程图:

（图片来自csdn https://blog.csdn.net/Hehuyi_In）

GetTransactionSnapshot()主要的判断逻辑：

逻辑解码时的historic快照直接返回快照结果
在可重复读或串行化隔离级别，如果是第一次调用，返回快照并复制，以便下次（既非第一次）直接引用该快照
在读已提交隔离级别，每次调用都生成新快照
串行化隔离级别的第一次调用，额外获得SSI数据信息
GetTransactionSnapshot()获得快照，其获得快照数据调用的是GetSnapshotData()

GetSnapshotData()
#

源码src/backend/storage/ipc/procarray.c

Snapshot
GetSnapshotData(Snapshot snapshot)
{
	//先初始化一些变量，包括arrayP指针，procarray，xmin，xmax，复制槽事务id等等
	ProcArrayStruct *arrayP = procArray;
	TransactionId xmin;
	TransactionId xmax;
	TransactionId globalxmin;
	int			index;
	int			count = 0;
	int			subcount = 0;
	bool		suboverflowed = false;
	TransactionId replication_slot_xmin = InvalidTransactionId;
	TransactionId replication_slot_catalog_xmin = InvalidTransactionId;

	Assert(snapshot != NULL);

	if (snapshot->xip == NULL)
	{
		/*
		 * First call for this snapshot. Snapshot is same size whether or not
		 * we are in recovery, see later comments.
		 */
		snapshot->xip = (TransactionId *) //获得当前事务的xip
			malloc(GetMaxSnapshotXidCount() * sizeof(TransactionId));
		...
		Assert(snapshot->subxip == NULL);
		snapshot->subxip = (TransactionId *) //获得当前子事务的subxip
			malloc(GetMaxSnapshotSubxidCount() * sizeof(TransactionId));
		...
	}

	//获取procarray，需要共享lwlock锁
	LWLockAcquire(ProcArrayLock, LW_SHARED);

	/* xmax=最大完成xid+1 */
	xmax = ShmemVariableCache->latestCompletedXid;
	Assert(TransactionIdIsNormal(xmax));
	TransactionIdAdvance(xmax); //xmax+1

	/* xmax的值已经取出，xmin需要检索pgproc、pgxact、procarray */
	/* 先把globalxmin、xmin赋值xmax，如果判断backend没有事务信息，就比较好办了 */
	globalxmin = xmin = xmax; 
	
	//恢复快照单独处理
	snapshot->takenDuringRecovery = RecoveryInProgress();
	//非恢复快照需要到backend中获取事务信息
	if (!snapshot->takenDuringRecovery)
	{
		int		 *pgprocnos = arrayP->pgprocnos;
		int			numProcs;

		/*
		 * Spin over procArray checking xid, xmin, and subxids. The goal is
		 * to gather all active xids, find the lowest xmin, and try to record
		 * subxids.看上去在检索procarray的时候会spin，以收集所有活跃的xid，最小的xmin，子事务subxid
		 */
		numProcs = arrayP->numProcs;
		for (index = 0; index < numProcs; index++)
		{
			int			pgprocno = pgprocnos[index]; //通过循环numProcs进程个数，取pgprocno全部下标
			PGXACT	 *pgxact = &allPgXact[pgprocno]; //通过pgprocno遍历所有pgxact结构体
			TransactionId xid;
			...
			/* Update globalxmin to be the smallest valid xmin */
			xid = UINT32_ACCESS_ONCE(pgxact->xmin);
			if (TransactionIdIsNormal(xid) &&
				NormalTransactionIdPrecedes(xid, globalxmin))
				globalxmin = xid;

			/* Fetch xid just once - see GetNewTransactionId */
			xid = UINT32_ACCESS_ONCE(pgxact->xid);
			...
			/* 把backend中的xmin保存到快照xip中 */
			/* 也就是说通过便利所有pgxact以找到所有活跃的xid */
			snapshot->xip[count++] = xid;
			...
			/* 子事务信息处理 */
			if (!suboverflowed) //如果子事务没有溢出
			{
				if (pgxact->overflowed)
					suboverflowed = true; //如果事务溢出，将子事务也标记为溢出
				else
				{
					int			nxids = pgxact->nxids;

					if (nxids > 0)
					{
						PGPROC	 *proc = &allProcs[pgprocno];

						pg_read_barrier();	/* pairs with GetNewTransactionId */

						memcpy(snapshot->subxip + subcount,
							 (void *) proc->subxids.xids,
							 nxids * sizeof(TransactionId));
						subcount += nxids;
					}
				}
			}
		}
	}
	else //这里的else对应if (!snapshot->takenDuringRecovery)
	{
		// 这里的判断都是standby的，当实例是hot standby模式，从库中有查询事务时
		subcount = KnownAssignedXidsGetAndSetXmin(snapshot->subxip, &xmin,
												 xmax);

		if (TransactionIdPrecedesOrEquals(xmin, procArray->lastOverflowedXid))
			suboverflowed = true;
	}


	//事物槽的xmin和catalog全集群xmin，先保存到本地变量
	//事物槽xmin是为了防止元组被回收
	//注释中说明是为了不长时间持有ProcArrayLock，才保存到本地变量
	replication_slot_xmin = procArray->replication_slot_xmin;
	replication_slot_catalog_xmin = procArray->replication_slot_catalog_xmin;
	
	//从backend中获取事务信息的工作已经完成，下面是一堆if判断，收尾工作并增加代码严谨性 
	if (!TransactionIdIsValid(MyPgXact->xmin))
		MyPgXact->xmin = TransactionXmin = xmin;

	LWLockRelease(ProcArrayLock); //释放ProcArrayLock

	if (TransactionIdPrecedes(xmin, globalxmin))
		globalxmin = xmin; //globalxmin和进程xmin，globalxmin赋值更小的那个

	RecentGlobalXmin = globalxmin - vacuum_defer_cleanup_age;
	if (!TransactionIdIsNormal(RecentGlobalXmin))
		RecentGlobalXmin = FirstNormalTransactionId; //特殊情况下，如果RecentGlobalXmin<=2，赋值3

	/* Check whether there's a replication slot requiring an older xmin. */
	if (TransactionIdIsValid(replication_slot_xmin) &&
		NormalTransactionIdPrecedes(replication_slot_xmin, RecentGlobalXmin))
		RecentGlobalXmin = replication_slot_xmin;

	/* Non-catalog tables can be vacuumed if older than this xid */
	RecentGlobalDataXmin = RecentGlobalXmin;

	//再次检查和对比catalog，globalxminn
	if (TransactionIdIsNormal(replication_slot_catalog_xmin) &&
		NormalTransactionIdPrecedes(replication_slot_catalog_xmin, RecentGlobalXmin))
		RecentGlobalXmin = replication_slot_catalog_xmin;

	RecentXmin = xmin;
	
	//开始给snapshot结构体赋值，返回快照数据
	snapshot->xmin = xmin;
	snapshot->xmax = xmax;
	snapshot->xcnt = count;
	snapshot->subxcnt = subcount;
	snapshot->suboverflowed = suboverflowed;

	snapshot->curcid = GetCurrentCommandId(false);

	//如果是一个新快照，初始化一些快照信息
	snapshot->active_count = 0;
	snapshot->regd_count = 0;
	snapshot->copied = false;
	
	//下面是快照过久时的判断，居然写在这
	if (old_snapshot_threshold < 0)
	{
		/*
		 * If not using "snapshot too old" feature, fill related fields with
		 * dummy values that don't require any locking.
		 */
		//如果没有使用old_snapshot_threshold参数（参数<0，不会出现snapshot too old的问题）
		//赋一些简单的值，都是常量，不会产生任何锁
		snapshot->lsn = InvalidXLogRecPtr;
		snapshot->whenTaken = 0;
	}
	else
	{
		//当old_snapshot_threshold参数>=0时，需要完成old snapshot的逻辑
		snapshot->lsn = GetXLogInsertRecPtr(); //获得lsn
		snapshot->whenTaken = GetSnapshotCurrentTimestamp(); //获得快照时间
		MaintainOldSnapshotTimeMapping(snapshot->whenTaken, xmin); //
		//GetXLogInsertRecPtr()，GetSnapshotCurrentTimestamp() ,MaintainOldSnapshotTimeMapping()三个函数中有 //SpinLockAcquire和SpinLockRelease
		//MaintainOldSnapshotTimeMapping()函数还有LWLockAcquire和LWLockRelease 
		//因为每次快照都要调用，获取快照数据函数应该是很频繁的
		//所以能看出来pg13源码中，如果将old_snapshot_threshold设置为负数，spinlock和lwlock会少很多
	}

	return snapshot;
}

pg14对事务的优化
#

pg14事务优化源码分析
#

pg13的源码能看出来GetSnapshotData()中写死了old_snapshot_threshold>=0时，每次获得快照数据都会产生较多的SpinLock和LWLock，而获得快照对于数据库来说是非常频繁的操作，这必定导致一些性能问题。所以pg14中直接把old_snapshot_threshold部分删除了···

除了删除GetSnapshotData()中的old_snapshot_threshold逻辑，还做了很多其他优化：

移除RecentGlobalXmin，RecentGlobalDataXmin，新增GlobalVisTest*系列函数

新增边界boundaries概念，有两个边界分别为definitely_needed，maybe_needed

struct GlobalVisState
{
	/* XIDs >= are considered running by some backend */
	// >=definitely_needed的行一定可见
	FullTransactionId definitely_needed;

	/* XIDs < are not considered to be running by any backend */
	// <maybe_needed的行一定可以清理
	FullTransactionId maybe_needed;
};

新增ComputeXidHorizons()用于进一步精准计算horizons（保存xmin和removable xid信息），该函数仍需要遍历PGPROC。计算的范围当然是在XID >= maybe_needed && XID < definitely_needed

新增GlobalVisTestShouldUpdate()用于判断是否需要再次计算边界

先了解一个变量ComputeXidHorizonsResultLastXmin

static TransactionId ComputeXidHorizonsResultLastXmin; //最后一次精准计算的xmin

GlobalVisTestShouldUpdate(GlobalVisState *state)
{
	//如果xmin=0，需要重新计算边界。相当于给初始化数据库产生的元组设置一个例外判断
	if (!TransactionIdIsValid(ComputeXidHorizonsResultLastXmin))
		return true;

	/*
	 * If the maybe_needed/definitely_needed boundaries are the same, it's
	 * unlikely to be beneficial to refresh boundaries.
	 */
	//maybe_needed等于definitely_needed不需要再计算了
	//不过不是用的等于，而是maybe_needed>=definitely_needed
	//“大于”的场景是没有行一定可见，“等于”的场景是只有一行一定可见
	if (FullTransactionIdFollowsOrEquals(state->maybe_needed,
										 state->definitely_needed))
		return false;

	/* does the last snapshot built have a different xmin? */
	//当最后一次快照snapshot->xmin=最后一次精准计算的xmin时，不再重新计算边界
	return RecentXmin != ComputeXidHorizonsResultLastXmin;
}

可以看出maybe_needed和definitely_needed跟快照xmin、xmax是相似的，多嵌套了1层计算。先计算boundaries，再进一步精确计算horizons。GlobalVisTestShouldUpdate减少了计算boundaries的场景，而ComputeXidHorizons()精准计算也更高效。

优化结果
#

对比优化前后的效果相当明显：

其实在pg13的生产上也能看到GetSnapshotData的性能消耗总是很高。不过没截图，再借用下大佬的图

reference
#

books：《postgresql指南内幕探索》《postgresql实战》《postgresql技术内幕事务处理深度探索》《postgresql数据库内核分析》 https://edu.postgrespro.com/postgresql_internals-14_parts1-2_en.pdf 官方资料： https://en.wikipedia.org/wiki/Concurrency_control https://wiki.postgresql.org/wiki/Hint_Bits https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND https://www.postgresql.org/docs/10/storage-page-layout.html https://www.postgresql.org/docs/13/pageinspect.html3 pg事务必读文章 interdb https://www.interdb.jp/pg/pgsql05.html https://www.interdb.jp/pg/pgsql06.html 源码大佬 https://blog.csdn.net/Hehuyi_In/article/details/102920988 https://blog.csdn.net/Hehuyi_In/article/details/127955762 https://blog.csdn.net/Hehuyi_In/article/details/125023923 pg的快照优化性能对比 https://techcommunity.microsoft.com/t5/azure-database-for-postgresql/improving-postgres-connection-scalability-snapshots/ba-p/1806462 其他资料 https://brandur.org/postgres-atomicity https://mp.weixin.qq.com/s/j-8uRuZDRf4mHIQR_ZKIEg

可见性检查
#

快照有了，就可以通过快照数据去判断元组的可见性。回顾一下（先不考虑子事务），事务的关键信息：元组头部事务信息、快照信息、clog事务状态(SetHintBits前需要）

元组上有元组xmin、xmax、cmin、cmax、infomask等
快照数据中有快照xmin、xmax、xip_list、curcid等
clog中额外的事务状态信息，也可能写入了infomask中的hintbits

快照类型不同，可见性判断略有区别

bool
HeapTupleSatisfiesVisibility(HeapTuple tup, Snapshot snapshot, Buffer buffer)
{
	switch (snapshot->snapshot_type)
	{
		case SNAPSHOT_MVCC:
			return HeapTupleSatisfiesMVCC(tup, snapshot, buffer);
			break;
		...
		case SNAPSHOT_NON_VACUUMABLE:
			return HeapTupleSatisfiesNonVacuumable(tup, snapshot, buffer);
			break;
	}
	...
}

每种快照都有各自的可见性规则，这里用最常见的SNAPSHOT_MVCC快照可见性规则来理解元组可见性

static bool
HeapTupleSatisfiesMVCC(HeapTuple htup, Snapshot snapshot,
					 Buffer buffer)
{
	HeapTupleHeader tuple = htup->t_data; 

	Assert(ItemPointerIsValid(&htup->t_self)); //lp有效，也就是元组有效
	Assert(htup->t_tableOid != InvalidOid); //oid有效，也就是表还有效

	//t_xmin未提交，insert或update新元组的事务，未提交
	//在htup_details.h中已经宏定过，HeapTupleHeaderXminCommitted(）是((tup)->t_infomask & HEAP_XMIN_COMMITTED) != 0
	//也就是说if (!HeapTupleHeaderXminCommitted(tuple)) 表示元组infomask中没有HEAP_XMIN_COMMITTED
	//其实就是字面含义，t_xmin没有提交
	if (!HeapTupleHeaderXminCommitted(tuple)) 
	{
		//假如有个事务更新了元组，但是回退或者失败了，那么这个元组的xmin就是失败的事务ID
		//如果是失败事务的t_xmin，则直接返回不可见
		if (HeapTupleHeaderXminInvalid(tuple))
			return false;
		
		//当元组infomask有HEAP_MOVED_OFF标记时，vacuum元组单独判断可见性，并对于vacuum事务做一些hintbits标记
		/* Used by pre-9.0 binary upgrades */
		if (tuple->t_infomask & HEAP_MOVED_OFF)
		{
			TransactionId xvac = HeapTupleHeaderGetXvac(tuple);

			if (TransactionIdIsCurrentTransactionId(xvac))
				return false;
			if (!XidInMVCCSnapshot(xvac, snapshot))
			{
				if (TransactionIdDidCommit(xvac))
				{
					SetHintBits(tuple, buffer, HEAP_XMIN_INVALID,
								InvalidTransactionId);
					return false;
				}
				SetHintBits(tuple, buffer, HEAP_XMIN_COMMITTED,
							InvalidTransactionId);
			}
		}
		//当元组infomask有HEAP_MOVED_IN标记时，vacuum元组单独判断可见性，并对于vacuum事务做一些hintbits标记
		/* Used by pre-9.0 binary upgrades */
		else if (tuple->t_infomask & HEAP_MOVED_IN)
		{
			TransactionId xvac = HeapTupleHeaderGetXvac(tuple);

			if (!TransactionIdIsCurrentTransactionId(xvac))
			{
				if (XidInMVCCSnapshot(xvac, snapshot))
					return false;
				if (TransactionIdDidCommit(xvac))
					SetHintBits(tuple, buffer, HEAP_XMIN_COMMITTED,
								InvalidTransactionId);
				else
				{
					SetHintBits(tuple, buffer, HEAP_XMIN_INVALID,
								InvalidTransactionId);
					return false;
				}
			}
		}
		//当元组是本事务写入的
		else if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetRawXmin(tuple)))
		{
			if (HeapTupleHeaderGetCmin(tuple) >= snapshot->curcid) //当元组cid>=快照事务当前commandid时
				return false;	// 说明插入元组的时间晚于可见性检测开始时间，元组不可见

			if (tuple->t_infomask & HEAP_XMAX_INVALID) //当元组infomask位有HEAP_XMAX_INVALID时
				return true; //说明元组没有被删除（delete），元组可见
				//因为仅插入元组，不提交、提交或者回退，都是HEAP_XMAX_INVALID
				//但是这个判断在“本事物写入”条件下,所以这里的逻辑是
				//本事务新增元组，未提交（逻辑上等价于同一事务中元组未被删除），且t_cid<curcid，元组可见

			//xmax在两种情况被设置：1对元组加锁，元组被删除
			//即使元组没有HEAP_XMAX_INVALID，可能也不是被删除，也可能是元组加锁了
			//元组加锁情况下设置了xmax，元组可见
			if (HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask))	/* not deleter */
				return true;
			
			// HEAP_XMAX_IS_MULTI是对多个事务获取同一行锁时，才会产生MultiXactId
			// 这里仍然是在判断xmax加锁情况下的可见性
			if (tuple->t_infomask & HEAP_XMAX_IS_MULTI)
			{
				TransactionId xmax;

				xmax = HeapTupleGetUpdateXid(tuple);

				/* not LOCKED_ONLY, so it has to have an xmax */
				Assert(TransactionIdIsValid(xmax));

				/* updating subtransaction must have aborted */
				//如果xmax不是当前事务，则可见
				if (!TransactionIdIsCurrentTransactionId(xmax))
					return true;
				//如果xmax是当前事务，通过commandid判断，在更新和删除操作之前获得快照，在获得快照时间元组是可见的
				else if (HeapTupleHeaderGetCmax(tuple) >= snapshot->curcid)
					return true;	/* updated after scan started */
				else
					return false;	/* updated before scan started */
			}
			
			//以下判断场景是：子事务中的删除命令回退了，需要SetHintBits为HEAP_XMAX_INVALID
			//删除命令回退了，所以元组是可见的
			if (!TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetRawXmax(tuple)))
			{
				/* deleting subtransaction must have aborted */
				SetHintBits(tuple, buffer, HEAP_XMAX_INVALID,
							InvalidTransactionId);
				return true;
			}

			//cmax删除元组的cid
			//如果元组cmax>=快照curcid，则删除发生在快照扫描之后，元组可见
			//如果元组cmax<快照curcid，则删除发生在快照扫描之前，元组不可见
			if (HeapTupleHeaderGetCmax(tuple) >= snapshot->curcid)
				return true;	/* deleted after scan started */
			else
				return false;	/* deleted before scan started */
		}
		//XidInMVCCSnapshot()判断xid在快照生成时是in-progress状态
		//in-progress是 1.快照xmin<=xid<快照xmax且xid in xip_list 2.xid>=快照xmax
		//以下XidInMVCCSnapshot()中的xid是t_xmin
		//所以，这个判断的含义是：如果t_xmin在快照生成时是in-progress状态，则元组不可见
		//相当于t_xmin没有提交，所以元组不可见。这看上去有点奇怪
		//因为整个判断是在!HeapTupleHeaderXminCommitted(tuple)下的，含义也是t_xmin没有提交，判断有些重复
		//但是加上前面的几个小判断，这的else if就变得合理，其含义为：
		//t_xmin没有提交，且元组没有被删除，且不是当前事务，则元组不可见
		else if (XidInMVCCSnapshot(HeapTupleHeaderGetRawXmin(tuple), snapshot))
			return false;
			
		//如果t_xmin事务提交了，做个SetHintBits为HEAP_XMIN_COMMITTED
		//这里看上去有点奇怪，整个判断是t_xmin未提交的情况下，不应该出现t_xmin提交了
		//而且，真的有这种情况的话，为什么这里不做事务可见性判断？
		else if (TransactionIdDidCommit(HeapTupleHeaderGetRawXmin(tuple)))
			SetHintBits(tuple, buffer, HEAP_XMIN_COMMITTED,
						HeapTupleHeaderGetRawXmin(tuple));
		//如果t_xmin事务没有提交，做个SetHintBits为HEAP_XMIN_INVALID
		else
		{
			/* it must have aborted or crashed */
			SetHintBits(tuple, buffer, HEAP_XMIN_INVALID,
						InvalidTransactionId);
		//t_xmin事务没有提交，再次返回不可见。看上去跟上面的关于XidInMVCCSnapshot()的条件很像
		//当前即没有提交，又不满足XidInMVCCSnapshot()（xid在快照生成时不是in-progress）
		//只有生成快照时事务未开始，后来事务开始了，目前没有提交，元组不可见
		return false; 
		}
	}
	//xmin未提交的情况下的事务可见性总算判断完了
	//这里的else以后都是xmin提交的情况下，对元组可见性的判断
	//xmin已提交的判断是hintbits位有HEAP_XMIN_COMMITTED
	else
	{
		//xmin已提交，但是不是当前快照做的
		/* xmin is committed, but maybe not according to our snapshot */
		//当infomask没有HEAP_XMIN_FROZEN且在快照生成时xmin in-progress状态，则元组不可见
		//整合翻译一下，这里的if含义为快照生成时xmin未提交，在可见性判断时，元组xmin提交但没有标记FROZEN的情况，元组不可见
		//即使元组xmin已提交了，对当前快照而言仍然是in-progress
		if (!HeapTupleHeaderXminFrozen(tuple) &&
			XidInMVCCSnapshot(HeapTupleHeaderGetRawXmin(tuple), snapshot))
			return false;		/* treat as still in progress */
	}

	//HEAP_XMAX_INVALID表示元组没有被删除
	//这里的if含义是：当前元组提交了且在快照生成时也提交了且没有被删除（完全没有删除标记），元组可见
	if (tuple->t_infomask & HEAP_XMAX_INVALID)	/* xid invalid or aborted */
		return true;
	
	//虽然元组上有xmax，但不是删除事务，而是锁标记
	//这里的if含义是：当前元组提交了且在快照生成时也提交了且有xmax，但xmax是锁标记，元组可见
	if (HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask))
		return true;
	
	//HEAP_XMAX_IS_MULTI表示元组处于shared-row-lock，一般表示多个事务处理一行时行所拥有的infomask标记
	if (tuple->t_infomask & HEAP_XMAX_IS_MULTI)
	{
		TransactionId xmax;

		/* already checked above */
		Assert(!HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask));

		//获取更新元组的事务id
		xmax = HeapTupleGetUpdateXid(tuple);

		/* not LOCKED_ONLY, so it has to have an xmax */
		Assert(TransactionIdIsValid(xmax));

		//如果shared-row-lock元组的事务ID是当前事务
		if (TransactionIdIsCurrentTransactionId(xmax))
		{
			//元组cmax>=快照curcid时，元组在快照生成时还没有被删除，元组可见
			if (HeapTupleHeaderGetCmax(tuple) >= snapshot->curcid)
				return true;	/* deleted after scan started */
			//元组cmax<快照curcid时，元组在快照生成时还已被删除，元组可见
			else
				return false;	/* deleted before scan started */
		}
		//如果shared-row-lock元组的事务ID不是当前事务，且在快照生成时xmax处于in-progress状态
		//这里的if含义是：xmin提交，且元组未被删除，有MULTI XMAX标记的情况下，xmax在快照生成时还未提交，元组可见
		if (XidInMVCCSnapshot(xmax, snapshot))
			return true;
		//如果shared-row-lock元组事务已提交，则元组不可见
		if (TransactionIdDidCommit(xmax))
			return false;		/* updating transaction committed */
		/* it must have aborted or crashed */
		//更新元组异常终止或回滚，元组仍可见
		return true;
	}
	
	//元组xmin已提交，xmax还没有提交标记，还没有被删除
	//看来!HEAP_XMAX_COMMITTED和HEAP_XMAX_INVALID还是有点区别
	//这里的判断看上去像元组经历过删除，但删除事务没有提交
	//而上面的HEAP_XMAX_INVALID是完全确认没有删除元组或删除abort or rollback，所以可以直接判断为true
	if (!(tuple->t_infomask & HEAP_XMAX_COMMITTED))
	{
		//如果xmax与校验事务是同一事物
		if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetRawXmax(tuple)))
		{
			//还是老一套通过commandid检测可见性
			//cmax>=快照curcid，说明删除在快照生成之后，元组可见
			if (HeapTupleHeaderGetCmax(tuple) >= snapshot->curcid)
				return true;	/* deleted after scan started */
				
			//cmax<快照curcid，说明删除在快照生成之前，元组不可见
			else
				return false;	/* deleted before scan started */
		}
		
		//删除事务没有提交，且xmax与校验事务不是同一事物
		//xmax在生成快照时是in-progress的，则元组可见
		if (XidInMVCCSnapshot(HeapTupleHeaderGetRawXmax(tuple), snapshot))
			return true;
		
		//确认xmax删除事务回退或失败，SetHintBits为HEAP_XMAX_INVALID
		//类似上面的HEAP_XMAX_INVALID，元组可见
		if (!TransactionIdDidCommit(HeapTupleHeaderGetRawXmax(tuple)))
		{
			/* it must have aborted or crashed */
			SetHintBits(tuple, buffer, HEAP_XMAX_INVALID,
						InvalidTransactionId);
			return true;
		}

		/* xmax transaction committed */
		//还剩下xmax删除事务已提交的场景，SetHintBits为HEAP_XMAX_COMMITTED
		//按道理这里应该判断可见性，但是没有写在这，而是在代码的最后几行。因为这里的小条件属于大条件之一
		SetHintBits(tuple, buffer, HEAP_XMAX_COMMITTED,
					HeapTupleHeaderGetRawXmax(tuple));
	}
	else
	{
		/* xmax is committed, but maybe not according to our snapshot */
		//xmax删除事务当前已提交，但是在快照生成时in-progress，则元组可见
		if (XidInMVCCSnapshot(HeapTupleHeaderGetRawXmax(tuple), snapshot))
			return true;		/* treat as still in progress */
	}

	/* xmax transaction committed */
	//只剩下xmax已提交的，且不在快照生成时in-progress的情况，元组不可见
	return false;
}

整个可见性判断的源码看上去有点复杂。把SetHintBits部分刨去，省略繁杂的if，只看关键性的可见性规则，其中的关键点如下：

可见性规则的主干逻辑
- 删除已提交，元组不可见
- 插入已提交，删除回滚，元组可见
- 插入已提交，删除未提交，本事务需要对比cid，其他事务对元组可见
- 插入回滚，元组不可见
- 插入未提交，同事务需要对比cmin，其他事务对元组不可见
可见性检查中有两个时间点，一个是检查发生时间，一个是快照生成时间。判断逻辑就有同一个事务（检查事务和快照生成事务为同一事务）和不同事务（检查事务和快照生成事务为2个不同的事务）的情况
- 如果是同一事务，通过对比元组cmin/cmax和snapshot->curcid的大小
  
  cmin>=snapshot->curcid，说明插入元组的事务晚于快照获取时间，此时元组不可见。反之元组可见
  
  cmax>=snapshot->curcid，说明删除元组的事务晚于快照获取时间，此时元组可见。反之元组不可见
- 如果不是同一事务，通过XidInMVCCSnapshot()函数判断xid(t_xmin或t_xmax）是否在快照生成时in-progress
  
  xmin在快照生成时in-progress，则元组不可见
  
  xmax在快照生成时in-progress，则元组可见
除了基本的dml操作，还需要完善其他条件下的判断，有如下4种情况：
- vacuum事务删除和新增的元组可见性判断
- HEAP_XMAX_IS_LOCKED_ONLY锁标记时元组可见
- HEAP_XMAX_IS_MULTI元组处于multixact状态时的可见性判断
- 元组有frozen标记时的可见性判断

multixact
#

什么是multixact？
#

在对同一行加锁时，元组上关联的事务ID可能有多个，pg将多个事务ID组合起来用一个MultiXactID来管理。TransactionId和MultiXactID是多对一的关系

multixactID跟TransactionId一样，也是32位，同样有wraparound

MultiXactId的0、1都是系统使用，可分配的MultiXactId从2开始

源码src/include/access/multixact.h
#define InvalidMultiXactId	((MultiXactId) 0)
#define FirstMultiXactId	((MultiXactId) 1)
#define MaxMultiXactId		((MultiXactId) 0xFFFFFFFF)

行锁的类型
#

只有行上有锁时，才会有multixact。MultiXact总共定义了6种状态

typedef enum
{
MultiXactStatusForKeyShare = 0x00,
MultiXactStatusForShare = 0x01,
MultiXactStatusForNoKeyUpdate = 0x02,
MultiXactStatusForUpdate = 0x03,
/* an update that doesn't touch "key" columns */
MultiXactStatusNoKeyUpdate = 0x04,
/* other updates, and delete */
MultiXactStatusUpdate = 0x05
} MultiXactStatus;

其中能显示声明的行锁的状态有4种：ForKeyShare，ForShare，ForNoKeyUpdate，ForUpdate

multixact的infomask标记
#

pg会将行锁标记到xmax上并记录到infomask中源码src/include/access/htup_details.h

#define HEAP_XMAX_KEYSHR_LOCK	0x0010	/* xmax is a key-shared locker */
#define HEAP_XMAX_EXCL_LOCK		0x0040	/* xmax is exclusive locker */
#define HEAP_XMAX_LOCK_ONLY		0x0080	/* xmax, if valid, is only a locker */
#define HEAP_XMAX_SHR_LOCK	(HEAP_XMAX_EXCL_LOCK | HEAP_XMAX_KEYSHR_LOCK)
#define HEAP_LOCK_MASK	(HEAP_XMAX_SHR_LOCK | HEAP_XMAX_EXCL_LOCK | \
						 HEAP_XMAX_KEYSHR_LOCK)
#define HEAP_XMAX_IS_MULTI		0x1000	/* t_xmax is a MultiXactId */

这里重点模拟HEAP_XMAX_IS_MULTI标记，只有多个事务对同一行持有共享锁时才真正产生multixact id，才会有此标记

lzldb=# insert into lzl1 values(1); --初始只有1行数据
INSERT 0 1
lzldb=# select * from vlzl1;
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags 
--------+----+-----------+--------+--------+-------+----------------------------------+----------------
 (0,1) | 1 | LP_NORMAL | 742 | 0 | 0 | {HEAP_HASNULL,HEAP_XMAX_INVALID} | {}
(1 row)

窗口1	窗口2
lzldb=# begin; BEGIN lzldb=# select from lzl1 for share; a — 1
	lzldb=# begin; BEGIN lzldb=# select from lzl1 for share; a — 1
lzldb=*# update lzl1 set a=2; –hang
	commit；
UPDATE 1 –update更新完成

--查看元组xmax、infomask情况
lzldb=*# select t_ctid,lp,t_xmin,t_xmax,(t_infomask&4096)!=0 is_multixact from heap_page_items(get_raw_page('lzl1',0));
 t_ctid | lp | t_xmin | t_xmax | is_multixact 
--------+----+--------+--------+--------------
 (0,2) | 1 | 742 | 4 | t
 (0,2) | 2 | 744 | 3 | t

HEAP_XMAX_IS_MULTI的16进制值是1000，转换为10进制为4096，通过(t_infomask&4096)!=0 is_multixact可以看出元组是否使用了multixact id。从上面的例子可以看出：

multxact id不同于transaction id，它有自己的取值空间
multixact id一般来说比transaction id小，所以这里t_xmax比t_xmin更小
如果是一个update语句更新的元组，那么新旧元组的xmax肯定是相等的。但是在multixact的场景下，可能就不一样了。

multixact slru
#

虽然src/backend/access/transam/multixact.c的开头定义很多变量和函数，有page,member,membergoup,offset，但是总体都是定义变量值，然后定义这些变量进行相互转化的函数

读懂multixact.c前需要先了解几个宏定义

src/include/c.h中定义MultiXactOffset是32位的类型

typedef uint32 MultiXactOffset;

src/include/access/slru.h中定义每个段有多少SLRU PAGES

#define SLRU_PAGES_PER_SEGMENT	32

回到src/backend/access/transam/multixact.c的开头

define MULTIXACT_OFFSETS_PER_PAGE (BLCKSZ / sizeof(MultiXactOffset)) 
//MULTIXACT_OFFSETS_PER_PAGE=8k/32B=2048 一个page可以存储2048个offsets标识位,其实也是2048个MULTIXACTID

#define MultiXactIdToOffsetPage(xid) \
	((xid) / (MultiXactOffset) MULTIXACT_OFFSETS_PER_PAGE)
//通过xid转换为对应记录的位于的页面：xid/2048

#define MultiXactIdToOffsetEntry(xid) \
	((xid) % (MultiXactOffset) MULTIXACT_OFFSETS_PER_PAGE)
//通过xid转换为对应记录位于页面的偏移量：xid%2048

#define MultiXactIdToOffsetSegment(xid) (MultiXactIdToOffsetPage(xid) / SLRU_PAGES_PER_SEGMENT)
//通过xid转换为对应记录位于的segment：xid/2048/32

再看下源码开头的注释

/* 
 * Defines for MultiXactOffset page sizes. A page is the same BLCKSZ as is
 * used everywhere else in Postgres.
 *
 * Note: because MultiXactOffsets are 32 bits and wrap around at 0xFFFFFFFF,
 * MultiXact page numbering also wraps around at
 * 0xFFFFFFFF/MULTIXACT_OFFSETS_PER_PAGE, and segment numbering at
 * 0xFFFFFFFF/MULTIXACT_OFFSETS_PER_PAGE/SLRU_PAGES_PER_SEGMENT. We need
 * take no explicit notice of that fact in this module, except when comparing
 * segment and page numbers in TruncateMultiXact (see
 * MultiXactOffsetPagePrecedes).
 */

因为MultiXactOffsets是32位且有wraparound，所以

MultiXact页编号回卷于0xFFFFFFFF/MULTIXACT_OFFSETS_PER_PAGE=2^32^/2048=2^21

段编号回卷于0xFFFFFFFF/MULTIXACT_OFFSETS_PER_PAGE/SLRU_PAGES_PER_SEGMENT=2^32^/2^11/^2^5^=2^16

TruncateMultiXact()会清理这些段包括页编号，TruncateMultiXact()被vacuum调用

pg_multixact目录
#

同CLOG，SUBTRANS日志一样，multixact日志SLRU缓冲池实现。pg_multixact目录下只有两个目录member,offset

[pg@lzl pg_multixact]$ ll
total 8
drwx------ 2 pg pg 4096 Feb 14 21:29 members
drwx------ 2 pg pg 4096 Feb 14 21:29 offsets

一个mutixactid有对应多个transaction id，也就是member。offset是每个multiact的起始位置

typedef struct mXactCacheEnt
{
	MultiXactId multi; //一个MultiXactId
	int		nmembers;
	dlist_node	node;
	MultiXactMember members[FLEXIBLE_ARRAY_MEMBER]; //多个TransactionId，如果需要，pg用MultiXactIdExpand()扩展member
} mXactCacheEnt;

multixact.h中定义了MultiXactMember只是单个事务id和事务状态

typedef struct MultiXactMember
{
	TransactionId xid;
	MultiXactStatus status;
} MultiXactMember;

multixact参考
#

https://www.postgresql.org/docs/current/routine-vacuuming.html

https://pgpedia.info/m/multixact-id.html

https://www.postgresql.org/docs/15/explicit-locking.html

https://www.modb.pro/db/14939

https://www.highgo.ca/2020/06/12/transactions-in-postgresql-and-their-mechanism/

2PC事务
#

什么是2PC事务？
#

事务原子性要求事务必须整体完成或者回滚。在多个联接的数据库等情况下的分布式事务中，必须为事务提供一致性状态，以满足分布式事务的原子性。与其他数据库一样，pg库也提供了 two-phase commit protocol(2PC)两阶段提交协议。

分布式事务实现方案很多，2PC是其中最基础也是最常见的。分布式事务包括原子提交、原子可见性、全局一致性，2PC只是原子提交的实现方案。

prepare transaction
#

FDW可以自己处理2PC事务，pg也提供了显示使用2PC事务的方法prepare transaction。prepare transaction发起后，就不会与会话有任何关联，它状态会被保存下来。prepare transaction并不是设计为在应用或者交互式会话中使用，除非你在编写一个事务管理器，所以推荐（默认）关闭的。

语法：

PREPARE TRANSACTION transaction_id
COMMIT PREPARED transaction_id 
ROLLBACK PREPARED transaction_id

注意：

这的transaction_id不是内部事务id，只是一个声明的字符串
PREPARE TRANSACTION 必须在事务块中，事务块以BEGIN|START STRANSATION开始
max_prepared_transactions控制prepare事务数，默认为0关闭，需要打开才能使用prepare事务

开启一个prepare事务
#

lzldb=# begin;
BEGIN
lzldb=*# PREPARE TRANSACTION 'lzl';
PREPARE TRANSACTION

lzldb=# select * from pg_prepared_xacts ;
 transaction | gid | prepared | owner | database 
-------------+-----+-------------------------------+-------+----------
 719 | lzl | 2023-04-29 16:08:45.866022+08 | pg | lzldb
(1 row)

lzldb=# rollback prepared 'lzl';
ROLLBACK PREPARED 

lzldb=# select * from pg_prepared_xacts ;
 transaction | gid | prepared | owner | database 
-------------+-----+----------+-------+----------
(0 rows)

pg_twophase目录
#

前面说过，prepare事务与会话无关，当开启一个prepare事务后，事务状态信息保存在缓存中。为了保证事务不丢失，prepare事务也会落盘，到pg_twophase目录。其实并不是关库才会导致prepare事务落盘，而是checkpoint 源码src/backend/access/transam/twophase.c

void
CheckPointTwoPhase(XLogRecPtr redo_horizon)
{
	...
	TRACE_POSTGRESQL_TWOPHASE_CHECKPOINT_START(); //checkpoint开始
	...
	fsync_fname(TWOPHASE_DIR, true); //调用fsync落盘
	
	TRACE_POSTGRESQL_TWOPHASE_CHECKPOINT_DONE();//checkpoint完成
	...
}

于是尝试开启一个prepare事务并做checkpoint

[pg@lzl pg_twophase]$ ll
total 0

lzldb=*# PREPARE TRANSACTION 'lzl';
PREPARE TRANSACTION
lzldb=# checkpoint;
CHECKPOINT

[pg@lzl pg_twophase]$ ll
total 4
-rw------- 1 pg pg 116 Apr 29 16:33 000002D0

orphaned prepared transactions
#

如果一个prepared事务没有完成（prepared事务不提交或回滚），而prepared事务又与会话无关，如果不显示结束这个事务的话，prepared事务仍然存在（会话断开后一般事务会回退），这就是orphaned prepared transactions。 orphaned prepared transactions会一直持有一些锁、元组的资源，导致vacuum无法回收和清理死元组，甚至阻止事务ID回卷。比如一个prepared事务忘记提交或者回滚了，如果没有外部事务管理机制来监控，这个parepared事务将可能不被发现并永远存在，最终导致严重的问题。所以建议max_prepared_transactions=0（默认）或者通过pg_prepared_xacts视图监控prepared事务

下面模拟一个孤儿prepared事务无限期阻塞的情况

--开启一个prepared事务并断开会话
lzldb=# begin;
BEGIN
lzldb=*# insert into lzl1 values(1);
INSERT 0 1
lzldb=*# PREPARE TRANSACTION 'lzl';
PREPARE TRANSACTION
lzldb=# \q

--会话断开prepared事务仍然存在
postgres=# select * from pg_prepared_xacts ;
 transaction | gid | prepared | owner | database 
-------------+-----+-------------------------------+-------+----------
 721 | lzl | 2023-04-29 17:08:59.597678+08 | pg | lzldb

--ddl 阻塞
lzldb=# alter table lzl1 add column b int;
--查看锁的情况
lzldb=# select locktype,relation,pid,mode from pg_locks where relation=32808;
 locktype | relation | pid | mode 
----------+----------+-------+---------------------
 relation | 32808 | 26136 | AccessExclusiveLock
 relation | 32808 | | RowExclusiveLock

--结束prepared事务，ddl执行完成
lzldb=# rollback prepared 'lzl';
ROLLBACK PREPARED
lzldb=# alter table lzl1 add column b int;
ALTER TABLE

2PC事务参考
#

http://postgres.cn/docs/13/sql-prepare-transaction.html

https://www.highgo.ca/2020/01/28/understanding-prepared-transactions-and-handling-the-orphans/

https://wiki.postgresql.org/wiki/Atomic_Commit_of_Distributed_Transactions

子事务
#

什么是子事务？
#

一般事务只能整体提交或回滚，而子事务允许部分事务回滚。

SAVEPOINT p1 在事务里面打上保存点标记。不能直接提交子事务，子事务也是通过事务的提交而提交。不过可以通过ROLLBACK TO SAVEPOINT p1回滚到该保存点。

子事务在大批量数据写入的时候很有用。如果事务中存在多个子事务，而其中一小段子事务失败，只需要重做这小部分数据就行，而不需要整个事务数据全部重做。

子事务在SQL语句中的使用
#

SAVEPOINT savepoint_name
ROLLBACK [ WORK | TRANSACTION ] TO [ SAVEPOINT ] savepoint_name
RELEASE [ SAVEPOINT ] savepoint_name

注意：

savepoints语句必须在事务块中
savepoint执行保存点；rollback回滚到指定保存点；release擦除保存点，不会回滚子事务数据
cursor不会被savepoint事务影响

sql中的子事务示例：

lzldb=# begin;
BEGIN
lzldb=*# insert into lzl1 values(0);
INSERT 0 1
lzldb=*# savepoint p1;
SAVEPOINT
lzldb=*# insert into lzl1 values(1);
INSERT 0 1
lzldb=*# savepoint p2;
SAVEPOINT
lzldb=*# insert into lzl1 values(2);
INSERT 0 1
lzldb=*# savepoint p3;
SAVEPOINT
lzldb=*# insert into lzl1 values(3);
INSERT 0 1
lzldb=*# rollback to savepoint p2;
ROLLBACK
lzldb=*# commit;
COMMIT
lzldb=# select xmin,xmax,cmin,a from lzl1;
 xmin | xmax | cmin | a 
------+------+------+---
 731 | 0 | 0 | 0
 732 | 0 | 1 | 1
(2 rows)
--回滚到p2时，p3也被回滚

lzldb=# select * from vlzl1;
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags 
--------+----+-----------+--------+--------+-------+------------------------------------------------------+----------------
 (0,1) | 1 | LP_NORMAL | 731 | 0 | 0 | {HEAP_HASNULL,HEAP_XMIN_COMMITTED,HEAP_XMAX_INVALID} | {}
 (0,2) | 2 | LP_NORMAL | 732 | 0 | 1 | {HEAP_HASNULL,HEAP_XMIN_COMMITTED,HEAP_XMAX_INVALID} | {}
 (0,3) | 3 | LP_NORMAL | 733 | 0 | 2 | {HEAP_HASNULL,HEAP_XMIN_INVALID,HEAP_XMAX_INVALID} | {}
 (0,4) | 4 | LP_NORMAL | 734 | 0 | 3 | {HEAP_HASNULL,HEAP_XMIN_INVALID,HEAP_XMAX_INVALID} | {}
(4 rows)
--子事务infomask跟一般事务区别不大，同一个事务中多个命令通过cid和HEAP_XMIN_INVALID等就可以判断可见性
--子事务产生写入同样会消耗transaction id，而且cid在父事务框架下增加

其他场景中产生子事务
#

即使不用savepoint，也有其他方法产生子事务

EXCEPTION语句会触发子事务，这在一些工具或架构中常见，也很容易被忽略。每次EXCEPTION都会产生一个子事务。

语法如：BEGIN / EXCEPTION WHEN .. / END

参考：https://fluca1978.github.io/2020/02/05/PLPGSQLExceptions.html

PL/Python代码引用plpy.subtransaction()

子事务SLRU缓存
#

子事务提交日志在pg_xact，父子对应关系在pg_subtrans存储子事务缓存subXID和父XID的映射。当PostgreSQL需要查找subXID时，它会计算这个ID驻留在哪个内存页中，然后在内存页中进行搜索。如果页面不在缓存中，它会驱逐一个页面，并将所需的页面从pg_subtrans加载到内存中。大量的子事务cache miss会消耗系统的IO和cpu。

子事务用的buffer只有32个并在源码中写死

源码src/include/access/subtrans.h

/* Number of SLRU buffers to use for subtrans */
\#define NUM_SUBTRANS_BUFFERS 32

buffer默认为8k，xid是32位占4个bytes，所以

SUBTRANS_BUFFER大小为32*8k=256k

SUBTRANS_BUFFER能存储最多32*8k/4=65536个xid

通过transactionid找到子事务的在page中的位置源码src/backend/access/transam/subtrans.c

/* We need four bytes per xact */
#define SUBTRANS_XACTS_PER_PAGE (BLCKSZ / sizeof(TransactionId))
//每个页面最多存储8k/4bytes=2048个子事务id

#define TransactionIdToPage(xid) ((xid) / (TransactionId) SUBTRANS_XACTS_PER_PAGE)
//通过子事务xid计算page号=xid/2048
#define TransactionIdToEntry(xid) ((xid) % (TransactionId) SUBTRANS_XACTS_PER_PAGE)
//通过子事务xid计算在page中的offset=xid%2048

子事务xid在page中不一定是紧凑的，一个page可能少于2048个子事务id

子事务的危害
#

PGPROC_MAX_CACHED_SUBXIDS溢出

PGPROC_MAX_CACHED_SUBXIDS不是GUI参数，在源码中写死，只能通过改源码修改该参数。

源码src/include/storage/proc.h

	/* 
	*每个backend都有子事务cache上限PGPROC_MAX_CACHED_SUBXIDS。
	*我们必须跟踪cache是否溢出（比如，事务至少有一个缓存不了的子事务）
	*如果一个cache都没有溢出，我们可以确认没有在pgproc array中xid一定不是一个运行中的事务。
	*（没有在任何proc，又没有溢出，说明没有跑）
	*如果有溢出，我们必须查看pg_subtrans
	*/
	#define PGPROC_MAX_CACHED_SUBXIDS 64	/* XXX guessed-at value */
	
	struct XidCache
	{
		TransactionId xids[PGPROC_MAX_CACHED_SUBXIDS];
	};

阅读这段源码，得到两个重要信息

每个backend都有子事务cache为PGPROC_MAX_CACHED_SUBXIDS，固定64个子事务
超过64个子事务会溢出到pg_subtrans目录

copy大佬压测：子事务刚好超过64个的时候，性能下降。所以，每个会话的子事务最好不要超过64个

参考：https://postgres.ai/blog/20210831-postgresql-subtransactions-considered-harmful

子事务导致multixact异常等待

原文：https://buttondown.email/nelhage/archive/notes-on-some-postgresql-implementation-details/

for update本身是行级排他锁，本身不应该产生multixact id，但在此场景中产生了多个MultiXact等待，导致数据库性能断崖

LWLock:MultiXactMemberControlLock
LWLock:MultiXactOffsetControlLock
LWLock:multixact_member
LwLock:multixact_offset

后来发现在Django框架中有子事务语句

SELECT [some row] FOR UPDATE;
 SAVEPOINT save;
 UPDATE [the same row];

从库性能急剧下降

原文：https://about.gitlab.com/blog/2021/09/29/why-we-spent-the-last-month-eliminating-postgresql-subtransactions/

一个长事务和一个savepoint子事务也可能造成查询库性能断崖

如果读取发生在主库的快照上，则生成的快照包含xmin，xmax，txip事务列表，subxip保存一个在进行的子事务列表。但是，无论是原数组还是快照都不会直接与从库共享，从库从WAL中读取所需的所有数据。

当存在子事务时，一个长事务的运行会使从库性能断崖式下滑

生产性能急剧下降

当数据库运行繁忙，又存在较多子事务时，性能可能急剧下降，并伴随子事务的等待事件。这个场景即使每个会话子事务没有超过64，而且不是在从库而是在主库上时，也会发生。

我们发现工具（OGG）中默认是50个子事务，此时我们将工具中的子事务数据量降低到10-20个时，数据库性能得到缓解。

子事务的使用建议

除了显示savepoint使用子事务，excetpion、框架、工具中同样会产生子事务
如果有从库查询业务，禁止使用子事务。
谨慎使用行锁。for update+子事务同样会引起multixactid的问题
如果仍有子事务，子事务设置不要超过64个，最好是更低

子事务已经在国内外生产环境造成了非常多问题，有许多案例和问题分析。引用一下“Subtransactions are basically cursed. Rip em out.”

子事务参考
#

https://postgres.ai/blog/20210831-postgresql-subtransactions-considered-harmful

https://www.cybertec-postgresql.com/en/subtransactions-and-performance-in-postgresql/

https://fluca1978.github.io/2020/02/05/PLPGSQLExceptions.html

https://about.gitlab.com/blog/2021/09/29/why-we-spent-the-last-month-eliminating-postgresql-subtransactions/

https://buttondown.email/nelhage/archive/notes-on-some-postgresql-implementation-details/

reference
#

books：

《postgresql指南内幕探索》

《postgresql实战》

《postgresql技术内幕事务处理深度探索》

《postgresql数据库内核分析》

https://edu.postgrespro.com/postgresql_internals-14_parts1-2_en.pdf

官方资料：

https://en.wikipedia.org/wiki/Concurrency_control

https://wiki.postgresql.org/wiki/Hint_Bits

https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND

https://www.postgresql.org/docs/10/storage-page-layout.html

https://www.postgresql.org/docs/13/pageinspect.html3

pg事务必读文章 interdb

https://www.interdb.jp/pg/pgsql05.html

https://www.interdb.jp/pg/pgsql06.html

源码大佬

https://blog.csdn.net/Hehuyi_In/article/details/102920988

https://blog.csdn.net/Hehuyi_In/article/details/127955762

https://blog.csdn.net/Hehuyi_In/article/details/125023923

pg的快照优化性能对比

https://techcommunity.microsoft.com/t5/azure-database-for-postgresql/improving-postgres-connection-scalability-snapshots/ba-p/1806462

其他资料

https://brandur.org/postgres-atomicity

https://mp.weixin.qq.com/s/j-8uRuZDRf4mHIQR_ZKIEg

https://blog.csdn.net/postgrechina/article/details/49130743?spm=a2c6h.12873639.article-detail.7.41b32cda2KR1QM

http://mysql.taobao.org/monthly/2018/12/02/

向量数据库相关概念

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

向量数据库相关概念
#

亿点点历史知识
#

LLM的模型发展历史，Harnessing the Power of LLMs in Practice: A Survey on ChatGPT and Beyond¹：

很多人都是从ChatGPT爆点后才逐渐了解到大模型，但在爆点的前几年大模型的发展已经开始了诸神之战。一些机构发布了许多革命性的论文，公司部分像是Google、DeepMind、OpenAI、Meta、Microsoft，学校部分像是Stanford、Berkeley、CMU、Princeton、MIT²。

总共分为三个阵营：

Google和DeepMind阵营 — Gemini、Bard
Microsoft和OpenAI阵营 —ChatGPT、Bing
Meta开源社区阵营 — Llama

近几年现有大模型产品发布时间线A Survey of Large Language Models³：

生成式AI的简单概念
#

AIGC（Artificial Intelligence generated Content）：AIGC精准概念是利用AI自动生成内容的生产方式。广义的AIGC可以近似训练像人类一样具备生成创建能力的AI技术，即生成式AI，它可以基于数据和生成演算法模型，自主生成创建新的文本、图像、音乐、视频、3D交互内容等各种形式的内容和数据，以及包括开启科学新发现、创造新的和意义等。

LLM（Large Language Model）：LLM即大语言模型，LLM能够捕捉和处理复杂的语言模式和语义，也就是它能够理解和生成人类语言。GPT3、ChatGPT、BERT、T5、文心一言等都是典型的大型语言模型。

NLP（Natural language processing）：自然语言处理（NLP）是研究如何让计算机读懂人类语言，也就是将人的自然语言转换为计算机可以阅读的指令。LLM是 NLP 中的一个重要组成部分。

AIGC取得了令人瞩目的增长，有很大因素就在于自然语言处理（NLP），而推动NLP发展的最大功臣是大语言模型（LLM）。今年（2024年）AIGC在视频、声音等领域也同样发展迅速。⁴

prompt：提示符、指令，提供给AI对应描述任务的自然语言，用于引导语言模型（如GPT-3或GPT-4）生成相应的输出⁵。（大伙其实都知道是啥了，不多解释）

embedding：

嵌入是一种表示对象（如文本、图像和音频）的方法，将其表示为连续向量空间中的点，这些点在空间中的位置对机器学习算法具有语义。

根据GloVe英文单词和向量相关性，这有个可直接看词汇embedding后的二维图。这个就是自然语言嵌入为二维向量：

RAG
#

RAG(Retrieval-Augmented Generation)是一个包含文档检索和大型语言模型（LLM）回答生成的两阶段过程。初始阶段利用密集嵌入来检索文档。根据具体使用场景，这种检索可以基于多种数据库格式，例如向量数据库、摘要索引、树索引、key索引⁵。

RAG原始论文⁶是2020年5月22日发布，来自Facebook(Meta)、伦敦大学学院、纽约大学的人员提出RAG的通用微调方法。RAG包含如下特性²

RAG模型结合了预训练的记忆以帮助语言的生成
RAG模型生成的语言更加具体、多样且具有事实性

OpenAI在2023年3月23日发布的chatgpt-retrieval-plugin仓库推荐在RAG中使用向量数据库，从此在应用领域向量数据库跟随大模型的爆火而备受关注

向量数据库能为AI带来什么？
#

向量数据库能在RAG中为大模型提供数据检索和数据长期存储的能力⁷

为什么要使用RAG？任何话语都没有祖师爷OpenAI说话有力。下面一段话源自2023年3月OpenAI的发布的检索插件使用指引⁸，用ChatGPT翻译如下：

开源检索插件使 ChatGPT 能够访问个人或组织的信息源（需获得许可）。用户可以通过自然语言提问或表达需求，从其数据源（如文件、笔记、电子邮件或公共文档）中获取最相关的文档片段。

作为开源且自托管的解决方案，开发者可以部署他们自己的插件版本并注册到 ChatGPT 上。该插件利用 OpenAI 的嵌入技术，并允许开发者选择一个矢量数据库（如 Milvus、Pinecone、Qdrant、Redis、Weaviate 或 Zilliz）来索引和搜索文档。信息源可以使用 webhook 与数据库同步。

总之，OpenAI推荐大伙使用向量数据库。

向量数据库凉了吗？不仅没有凉，RAG发展到今天，甚至都已经烂大街了–RAG 技术真的“烂大街”了吗？。而向量数据库因具有高检索效率、数据存储可靠性等等特点，是RAG的重要一环。

常见的向量数据库
#

自从OpenAI发布RAG repo以来，出现了许多向量数据库（当然以前也有一些）。一些公司也拿到了相当可观的融资⁹

Company	Headquartered in	Funding
Weaviate	🇳🇱 Amsterdam	$68M Series B
Qdrant	🇩🇪 Berlin	$11M Seed
Pinecone	🇺🇸 San Francisco	$138M Series B
Milvus/Zilliz	🇨🇳 / 🇺🇸 Redwood City	$113M Series B
Chroma	🇺🇸 San Francisco	$20M Seed
LanceDB	🇺🇸 San Francisco	Venture
Vespa	🇳🇴 / 🇺🇸 Indianapolis	Yahoo!
Vald	🇯🇵 Tokyo	Yahoo! Japan

向量数据库发布时间：

向量数据库性能对比¹⁰：

专用向量数据库一般来说比插件来实现向量的传统数据库性能更好，原因大概有两点：

专用向量数据库针对向量做的底层存储，其性能一般都要好于无目标性的传统数据库
专用向量数据库一般更新（基本都是go、rust实现的），他们在代码实现层面更方便优化

但这不代表插件实现的向量数据库没有用武之地：

传统数据库原生就支持更多功能，不仅仅是相似度计算
ACID，传统数据库的存储更为安全
在同一个数据库中更容易操作数据

向量数据功能对比：

上面对pgvector的描述不太准确了，pgvector目前已经支持了HNSW，基于pgvector的生态pgvectorscale也支持了DiskANN。

数学相关概念
#

数学说：“我站在山顶看你们玩”

标量
#

标量就是具体的数。标量没有方向，一般是相对向量来定义的。

向量（vector）
#

在欧几里得空间中，向量包括长度和方向。如下点A到点B的向量a（包含两个点的信息，和方向信息）¹¹：

单位向量（Unit vector）
#

大小为一个单位的向量就是单位向量。单位向量等于向量除以欧几里得长度¹²： $$ \vec a = \frac{\mathbf a}{||\mathbf a||} $$

数学中的单位向量（Unit vector）在pgvector和OpenAI embeddings中被称为normalized vector。（注意，不要跟数学中的normal vector混淆，normal vector是法向量，是另一个概念）

为什么要使用单位向量？

OpenAI embeddings对使用单位向量的解释¹³:

OpenAI embeddings are normalized to length 1, which means that:

Cosine similarity can be computed slightly faster using just a dot product

Cosine similarity and Euclidean distance will result in the identical rankings

稀疏向量（sparse vector）
#

稀疏向量之所以称为稀疏向量，是因为向量中的信息分布稀疏。通常情况下，我们需要在成千上万个零中找到几个1（相关信息）。因此，这些向量可以包含许多维度，通常在数万个维度。

稀疏向量和密集向量的比较。稀疏向量包含稀疏分布的信息位，而密集向量在每个维度上都包含更多信息，信息密集。¹⁴

欧几里得空间（Euclidean space）
#

简称欧式空间，是数学中最基本的空间。现代数学中，正整数n维的空间称为欧几里得空间。

还有一些其他的空间定义，如内积空间、希尔伯特空间，它们在数学定义上有不同，但是在数据库/真实世界中不会分那么清楚，基本要知道的是内积空间、欧几里得空间、希尔伯特空间都可以包含点、向量、内积等元素，我们可以简单的称他们为“多维空间”。它们的区别可参考漫谈数学中的各种空间¹⁵

欧几里得距离(Euclidean distance)
#

简称欧式距离，也就是我们一般认为的点与点的距离，即线段的长度¹⁶

在二维空间中，点q与点p的欧式距离为： $$ d(\mathbf p,\mathbf q)=\sqrt{(p_1-q_1)^2+(p_2-q_2)^2} $$

在n维空间中，点q与点p的欧式距离为： $$ d(\mathbf p,\mathbf q)=\sqrt{(p_1-q_1)^2+(p_2-q_2)^2+\cdots+(p_n-q_n)^2} $$

曼哈顿距离（Manhattan distance OR Taxicab distance）
#

$$ d(\mathbf p,\mathbf q)= \sum_{i=1}^n | p_i-q_i| $$

曼哈顿距离是两个点在各个维度上的差的绝对值之和¹⁷

上图中，绿线为欧式距离，红、黄、蓝线为曼哈顿距离。

闵氏距离(Minkowski distance)
#

$$ d(\mathbf a,\mathbf b)= \left( \sum_{i=1}^n | a_i-b_i|^p \right)^{1/p} $$

下图表示在闵式距离中取不同的p时，单位长度的点到原点的距离¹⁸：

当p=1时，为曼哈顿距离，也写作“L1 distance”
当p=2时，为欧式距离，也写作“L2 distance”
当p=n时，为闵式距离，也写作“Ln distance”

余弦相似性（Cosine similarity）
#

即两个向量的夹角的cosine值，也叫余弦值。余弦相似性只跟两个向量的夹角有关系，跟向量的长度无关¹⁹

两个向量角度越小，余弦相似性越大，值域[-1,1]。cos(0)=1，cos(90)=0，cos(180)=-1。

两个向量的余弦相似性写作： $$ cos (\theta) $$ 用向量表示： $$ cos (\theta)=\frac{\mathbf a\cdot \mathbf b }{||\mathbf a|| , ||\mathbf b||}= \frac{ \sum_{i=1}^n \mathbf a_i \mathbf b_i}{ \sqrt {\sum_{i=1}^n \mathbf a_i ^2} \cdot \sqrt {\sum_{i=1}^n \mathbf b_i ^2}} $$

内积（ inner product）
#

也称为点积（Dot product），可以被用来表示向量的长度和角度。内积等于向量的欧几里得距离乘以夹角余弦值。

二维空间中的内积为： $$ \mathbf a\cdot \mathbf b=||\mathbf a|| , ||\mathbf b||, cos \theta $$ or $$ \mathbf a\cdot \mathbf b= a_1 b_1 + a_2 b_2 $$ 在n维空间中的内积为（a=[a1,a2,···,an],b=[b1,b2,···,bn]）： $$ \mathbf a\cdot \mathbf b=\sum_{i=1}^n a_ib_i= a_1b_1 + a_2b_2 + \cdots + a_nb_n $$

此时来看下面这个图就能看懂了。用上面的公式也可反推n维向量的距离操作符的含义。

他们分别是：欧几里得距离，余弦距离，内积²⁰

他们都可以描述两个向量的相似性。

欧几里得距离仅包含两个向量的距离信息
余弦距离：仅包含两个向量的角度信息
内积：既包含距离信息，也包含角度信息

当然还有更多数学模型上的向量相似性计算方法，不过要看向量数据库支不支持。

jaccard距离
#

简而言之，交集除以并集²¹

用公式表达： $$ J(A,B)= \frac{|A\cap B| }{|A \cup B|} $$

用向量表达，即计算两个相等元素个数和不相等元素个数的比²²

Hamming距离
#

两个相同长度的字符串或向量在各自位置上的不同数量²³

例子：

“karolin” and “kathrin” is 3.
“karolin” and “kerstin” is 3.
“kathrin” and “kerstin” is 4.
0000 and 1111 is 4.
2173896 and 2233796 is 3.

图例²⁴：

Delaunay三角剖分
#

Delaunay三角剖分是对平面上一组点集进行的操作，它将这些点集的凸包（包含多个点）细分为多个三角形，这些三角形的外接圆不包含任何点集中的点。这样做最大化了所有三角形中最小角的大小，并倾向于避免产生细长的三角形²⁵。

不满足三角形的外接圆不包含任何点集中的点：

满足三角形的外接圆不包含任何点集中的点：

例如剖分一下点集：

合理的剖分：

Delaunay三角剖分其实并不是一种算法，它只是给出了一个“好的”三角网格的定义，它的优秀特性是空圆特性和最大化最小角特性，这两个特性避免了狭长三角形的产生，也使得Delaunay三角剖分应用广泛。

voronoi diagram
#

Delaunay三角剖分（Delaunay triangulation）是一个在一般位置中的离散点集P的三角剖分，它对应于P的Voronoi图的对偶图。Delaunay三角形的外接圆心是Voronoi图的顶点。在二维情况下，Voronoi的顶点通过边连接，这些边可以通过Delaunay三角形的邻接关系得出：如果两个三角形在德劳内剖分中共享一条边，那么它们的外接圆心在Voronoi镶嵌中应该用一条边连接起来²⁶：

Voronoi图的主要特性是：从一个质心到其区域内任何点的距离都小于该点到另一个质心的距离。 $$ R_k={x \in X ,|,d(x,P_k) \le d(x,P_j) ; \mathrm{for ,all },j \neq k} $$ Rk是质心，d(x,Pk)是质心到其区域内任何点的距离，d(x,Pj)是其他质心到该区域任何点的距离。

由于d距离计算方式的不同，Voronoi图还可以有不同的样貌²⁷：

向量数据库的索引
#

邻近搜索
#

ENN（exact nearest neighbor）：指的是在给定数据集中找到与查询点最接近的点或向量。这种方法保证了最高的精确度，但随着数据集的规模增大，计算成本会急剧升高，因为它需要评估查询点与数据集中每个点之间的距离。

ANN（Approximate nearest neighbor）：为了提高效率，在牺牲一定的精确度条件下，近似的找到与查询点最近的点。这种方法通过各种算法实现，可以大大降低计算成本，特别是在处理大规模数据集时更为有效。

KNN (K-Nearest Neighbors): 这是一种常用的机器学习算法，工作原理是找到数据集中距离给定查询点最近的K个邻居

索引评价标准
#

评价一个索引的好坏总是依赖于具体的数据模型的，总体来说包含如下几点：

查询时间。查询的速度是非常关键的，在大模型中尤为重视。
查询质量。ANN查询不会总是返回最精准的结果，但查询质量也不能偏差过大，而查询质量也有很多指标，其中包括最常用的召回率。
内存消耗。查询索引所消耗的内存，在内存上查找明显比在磁盘上查找更快。
训练时间。有些查询方法需要训练才能达到较好的状态。
写入时间。写入向量时对索引的影响，以及包含所有维护。

其中大部分指标都比较好理解，这里主要讲解查询质量：

ANN查询中，不会总是返回精确的结果。搜索一个元素集时，包括：查询的范围（retrieved elements）、所有正确元素集（relevant elements）、返回的正确元素集（true postives）、返回的错误元素集（false positives）²⁸：

TP = True positive; FP = False positive; TN = True negative; FN = False negative

准确率（Accuracy）： $$ Accuracy=\frac{TP+TN}{TP+FP+TN+FN} $$ 或写成： $$ Accuracy=\frac{所有正确的元素}{所有元素} $$

精确率（Precision）： $$ Precision=\frac{TP}{TP+FP} $$

或写成： $$ Precision=\frac{检索出的正确元素}{检索出的所有元素} $$

召回率(Recall)： $$ Recall=\frac{TP}{TP+FN} $$ 或写成： $$ Recall=\frac{检索出的正确元素}{所有正确的元素} $$

F-值（F-measure）：相当于加权后的精确率和召回率 $$ Recall=2 \cdot \frac{precision \cdot recall}{precision+recall} $$

示例：考虑一个用来识别数字照片中的狗（和相关元素）的计算机程序。在处理一张包含十只猫和十二只狗的照片时，程序识别出了八只狗。在被识别为狗的八个元素中，只有五个实际上是狗（true positives），而其他三个是猫（false positives）。有七只狗被漏识别（false negatives），七只猫被正确排除（true negatives）。那么该程序的

准确率=12/(10+12)（跟识别程序本身关系不大）
精确率=5/8（true positives/检索出的所有元素）
召回率=5/12（true positives/所有正确元素）
F值=2*[(5/18)*(5/12)]/[(5/18)+(5/12)]

locality-sensitive hashing (LSH)
#

LSH是一种用于通过将数据向量转换为哈希值来缩小搜索范围的方法，同时保留它们相似性的信息。

LSH的构建
#

LSH有许多实现方式，这里介绍比较传统的实现。这个传统LSH的实现包含3个部分²²

Shingling：将原始文本编码为向量。
MinHashing：将向量转换为一种称为signature的特殊表示形式，用于比较它们之间的相似性。
LSH function：将signature哈希到不同的桶中。如果一对向量的signature至少有一次落入同一个桶中，它们就被认为是候选者。

Shingling
#

shingling是一种embedding方式（个人观点）。Shingling将自然语言识别成k个连续的token，重复的token将被剔除²²：

此时我们有了基于k-gram的token集，接下来就是转化为向量。

首先有一个全“0”向量，向量长度等于token集的长度。每个token所对应的向量的位置设置为1：

最终的结果就是，我们得到一个很长的向量，向量只有0、1元素，向量信息包含一条语句的语义。

MinHashing
#

由于向量维度实在太高，直接通过one-hot encoding出来的向量来计算近似距离的效果非常差。我们需要将稀疏向量转化为密集向量，这个过程在LSH中称为MinHashing ，转化后的向量称为MinHashing signature。

MinHashing在初学者最初认识它的时候会有点难理解，认识了以后你会发现它很简单。

MinHashing is a hash function that permutes the components of an input vector and then returns the first index where the permutated vector component equals 1.

首先打乱排序（permutation），将一个向量的元素重新排列
返回排序后的向量的第一个1元素的index

例如以下例子：

u1向量(0,0,1,1,0)，第一次随机换行后，对应index是0，第二次随机换行后，对应的index是0²⁹，u1经过minhashing后的signature为(0,0)。

实际上可以使用多个 minhash 值来近似求得向量之间的 Jaccard 相似度。实际上，使用的 minhash 值越多，近似就越准确。

LSH function
#

即使我们将稀疏向量转化为了密集向量，但是密集向量的维度也会很高，直接检索的效率很低。

我们可以通过hash表来提升查询效率。但是要注意，如果直接用随机的hash算法容易将邻近的向量放在不同的hash桶中，我们应该找一个能将邻近的向量应该放在同一个hash桶中的hash算法，这就是LSH——局部敏感HASH算法。

LSH mechanism builds a hash table consisting of several parts which puts a pair of signatures into the same bucket if they have at least one corresponding part.

局部敏感hash算法的理念也很简单，将signature分片，分片后的子signature各自计算hash值，子hash值碰撞的列为candidate。

以下例子比较容易理解自行阅读：

从极限角度思考，b=1就是不分片直接hash，完全没有发挥LSH的效果；b=signature的元素个数，每个元素一个分片，也就是每个元素一个hash值，可以做到比较精确的近似比较，但是对计算量和内存是极大的负担。

LSH参数与错误率
#

一个向量的candidate向量概率直接影响召回率。candidate向量的概率如下，其中

s代表近似度
b代表分片数
r代表每个分片中的行数

如果将P和s作为对比坐标，根据公式，其向量相似度和candidate概率关系如下：

分区个数b越大，candidate相似概率越小。

同时，调整b和s会影响P，P的值与FP、TN又有关系。

例如返回更多的candidates，这自然会导致更多的false postive——即返回不相似的“candidate pair”。这是修改参数 b 的不可避免的结果。

TP = True positive; FP = False positive; TN = True negative; FN = False negative

LSH 容易受到高维数据的影响：更多的维度需要更长的signature长度和更多的计算才能保持良好的搜索质量。在这种情况下，建议使用其他索引。

more
#

还有两篇没啃完，大概看了下跟binary vector和欧几里得距离相关

https://towardsdatascience.com/similarity-search-part-6-random-projections-with-lsh-forest-f2e9b31dcc47

https://towardsdatascience.com/similarity-search-part-7-lsh-compositions-1b2ae8239aca

HNSW索引
#

HNSW算法（ Hierarchical navigable small world）是基于多图层的邻近算法。HNSW目前是最流行的向量索引算法之一。

从高层次来看，HNSW基于小世界理论。小世界理论最初源于社会心理学的六度分隔理论，任何两个人之间仅仅通过五层社会关系就能够被相互连接，换句话说，就是任何两个地球上的人都可以通过最多六步社会联系来相互联系上。小世界理论后来被实验和使用经验佐证而被广泛接受，并扩展到非社会关系网络中。注意小世界理论是一种现象。

总之，小世界理论是在说明“两个事务间的联系实际上是很短的”。HNSW所做的事情就是建立两个元素之间的联系、减少联系数。

HNSW索引的构建
#

看下HNSW论文关于构建HNSW图层的算法³⁰：

构建算法中有几个要素是比较重要的：

M为新增的边connection，表示新插入的节点的新边个数。
Mmax为节点的边的最大个数。如果一直插入的是邻近节点，那么已有的邻近节点的边有可能一直增加，查找时会浪费算力。当新增节点时发现新插入边导致已有邻近节点的边大于Mmax，那么需要做shrink connection。
efConstruction为邻近的节点集。

构建图例³¹：

HNSW添加node的步骤（without shrink connection）：

新节点插入时，先在最上层通过efConstruction找到邻近节点。以找到的最邻近节点当做entry point进入到下一层，然后继续通过那层的efConstruction查找邻近节点。
在某层（如L=2)做node插入。从efConstruction中找出M个节点，并连接新节点，此时新增了1个节点并添加M条边与之相连。
重复step2，直到最底层layer0。

HNSW启发式邻居构建
#

基本的HNSW索引结构构建还存在一个问题，如果有两个簇相隔比较远，那么根据最具备的HNSW构建算法，两个簇几乎不可能相连，因为构建HNSW的基本算法是基于最邻近的节点efConstruction来构建的。

HNSW original paper除了提出最基本的构建HNSW的算法，也提出了解决孤立群集的启发式算法：

Fig.2 为两个孤立的群集选择图形邻居的启发式方法。一个新元素被插入到cluster 1的边界上。该元素的所有最近邻居都属于cluster 1，因此错过了群集之间的Delaunay三角网的边缘。然而，启发式方法选择了来自群集2的元素e2，因此，如果插入的元素与来自群集1的任何其他元素相比更靠近e2，就能保持全局连通性。

“启发式算法不仅考虑了图中节点之间最近的距离，还考虑了图上不同区域之间的连通性”

如下图添加一个X节点，这里就应该启用启发式算法，与cluster A建立连接性，而不是简单的添加到邻近节点上：

HNSW索引寻迹
#

HNSW original paper中提到的HNSW寻找KNN的方法的主体逻辑包含如下2个算法：

算法2看上去要稍微复杂点，实际上逻辑很简单，算法2的功能是在该层中找到对于q最邻近的节点集ef。算法2简单来说就是把candidate节点加入到ef集并比较距离，把最远的节点剔出去，这样返回的W就是该层对于q的ef。
算法5的功能是返回q的K个最邻近节点，它会调用算法2两次（或多次）。for中的第一行输入参数ef=1，也就是说非最底层的layer都只找最邻近的ep（entry point），最底层（lc=0）返回K个最邻近节点集W。

HNSW复杂度
#

HNSW的层数为log(N)函数。

查询复杂度：在Delaunay graph中可以严格评估复杂度，平均复杂度为 O(log(N))（非Delaunay graph，如存在启发式邻近算法的graph，论文没有给出具体的复杂度公式）。

构建复杂度：HNSW是通过所有元素迭代插入构建的，平均复杂度为O(N∙log(N)) 。

HNSW索引参数
#

一般向量数据的HNSW索引都有几个参数可以调整，这些参数会影响索引构建速度、召回率等。不同的数据库参数可能稍微有差异，这里以pgvector的HNSW参数为例：

索引构建参数：

• m：向量的边的最大个数，默认为16。相当于论文中Mmax。 • ef_construction：构建索引时邻近列表中的向量个数，默认64。相当于论文中ef_construction。

索引搜索参数：

• hnsw.ef_search可调整搜索时邻近列表中的向量个数（也相当于论文中ef_construction）。必须大于等于limit。

构建索引时，调整ef_construction对创建时间和召回率的影响²⁰：

提高ef_construction这个参数会提高召回率，延长创建索引时间。ef_construction=256以后，索引构建时间明显增加，但召回率提升不明显。

提高m，同样会提高召回率，延长创建索引时间。m=36以后，索引构建时间明显增加，但召回率提升不明显。

同样的，提高hnsw.ef_search会提升召回率，降低性能。

IVFFlat索引
#

IVFFlat索引全称为扁平压缩的倒排索引（ Inverted File with Flat Compression）（跟invert有啥关系？分不了类的索引都叫倒排？）。IVFFlat索引的核心理念基于voronoi diagram：

Voronoi图的主要特性是：从一个质心到其区域内任何点的距离都小于该点到另一个质心的距离。

这个特性用公式表达： $$ R_k={x \in X ,|,d(x,P_k) \le d(x,P_j) ; \mathrm{for ,all },j \neq k} $$ Rk是质心，d(x,Pk)是质心到其区域内任何点的距离，d(x,Pj)是其他质心到该区域任何点的距离。

利用这个概念可以通过设置质心，把众多向量进行区域划分，然后利用voronio图的特性，粗略地找到邻近点。

IVFFlat索引的构建
#

我们将高维空间下降到2维以便理解IVFFlat索引构建³²。

例如以下一堆x表示点（或者叫向量），假设我们有三个质心

三个质心划分出3个Voronoi cell，所有点都分配到各自的Voronoi cell中

IVFFlat索引寻迹
#

此时有一个query节点，然后计算它到所有质心的距离，然后找到最近的那个质心，这个质心所在的cell就是接下来要寻找的区域。最后在这个区域范围内，找到邻近的节点³³：

边界问题：

上面的查询路径存在边界问题。当query靠近区域边界的时候，如果存在最近的节点在其他区域中，那么靠“仅搜索区域内邻近节点”的算法，是不会找到这个最邻近节点的。

边界问题本质是因为：

voronio图只能保证某节点到其区域质心的距离小于到其他质心的距离，但不保证某节点到区域内其他节点的距离小于到其他区域节点的距离。

这个问题可以通过设置搜索的区域数量来缓解，例如把搜索的区域数量从1增加到3：

增加搜索区域数量一般都以参数形式设置在数据库中，例如pgvector中的ivfflat.probes。

IVFFlat寻迹概述：

计算query节点到所有其他质心的距离，找到最近的那个
根据查询cells个数的入参（例如probes），在top probes个cells中寻找邻近点

IVFFlat索引参数
#

同样的，支持IVFFlat索引的向量数据库中，一般至少都有list和probe两个参数。这些参数会影响索引搜索性能、召回率。这里以Faiss的参数为例³²。

nlist：构建区域的个数。增大nlist会提高搜索邻近质心的时间，但会减少区域内搜索节点的时间
nprobe：搜索区域的个数。增大nprobe增大搜索区域个数，很明显会降低搜索性能，提升召回率

理论上来说，对于nlist，最好针对性的对向量数据的结构、数据库类型进行测试，不一定提高nlist总是会降低响应时间。对于nprobe，增大nprobe一定会降低搜索性能、提升召回率，但是nprobe太大没有意义，不符合ANN的初衷。

以下源自Pinecone对Faiss IVVFlat索引的性能测试：

PQ乘积量化
#

100w个密集向量可能需要上G的内存，而真实世界中的向量远不止这个数。如果不加以管理，相似性向量搜索可能需要大量内存，然而内存RAM是有限的。向量的大小随向量的维度、向量个数而增加。

乘积量化（Product Quantization）旨在减少内存使用，还可以提升查询速度（因为计算量减少了）。PQ是一种有损压缩方法，这会导致向量检索的准确性降低，不过这在ANN需求中是行的。

PQ的算法逻辑稍微比其他算法复杂一些，强烈推荐这篇文章Similarity Search, Part 2: Product Quantization³⁴

PQ的构建
#

步骤描述：

subvectors–将原始的高维向量切分成n个低维子向量
codebook–将n个各自所有的子向量通过k-means算法计算各自的voronoi图（或者其他算法），计算出来有n个不同的voronoi图，这些voronoi图就是codebook（这里假设每个voronoi图都有k个质心）
clustering–把n个子向量放进各自已聚类完成的voronoi图中计算出最近质心
quantized vectors–将这n个最近质心当做新的向量-量化后向量
reproduction values–以n个子空间的各自最近质心的编号为新值，合起来的新增称为PQ code

其中5.reproduction values详细描述：

根据n个子向量和每个子空间的中的k个质心，我们可以得到一个n*k的质心矩阵。取每个子向量的最近质心的编号，就是PQ code。

（btw：如果严谨一点，下图中所有元素的下角编号应该都是从1开始，而不是0）

新的PQ code相当于原向量失真压缩后的新向量（reproduction value），新的距离计算可以直接计算PQ code的L2距离。

PQ的检索
#

基于PQ original paper³⁵，PQ检索方式有两种：

对称方式：向量x，向量y之间的距离，近似通过他俩的质心q(x),q(y)的距离来代替。换言之，俩个向量的距离可通过两个向量的PQ code距离来代替
非对称方式：向量x，向量y之间的距离，近似通过x到质心q(y)的距离来替代。换言之，俩个向量的距离可通过查询向量原值和另一个向量的PQ code来计算

很明显两个模式计算的距离准确度是不一样的：

上图表示8个子空间，256个质心，在不同模式下计算两个向量的距离准确度。可以看出非对称模式比对称模式的准确度要高。

在对比两个向量距离的时候，对称和非对称模式的距离计算模型是比较有用的。但在查找PQ近似向量的时候场景中，稍微有些差别，特别是对称模式计算失真会非常严重：

对称方式的查询速度是非常快的，因为code table已经通过PQ构建过程计算并保留了，只需要先通过code table把查询向量x的PQ code算出来（计算量极小），然后通过PQ code反向获得的code table中对应的那些子code table，这个子code table里的向量都是与其距离相等的近似向量。这种方式计算量极少，直接查表即可。
对称方式的失真情况相对比较严重（上面2个图还不是很好，把它想象成一个cell中包含多个向量的voronoi图，就知道对称方式失真有多严重了），非对称方式可以稍微缓解这个问题。非对称方式先计算向量x的PQ code，然后同样通过PQ code反向获得的code table中对应的那些子code table，然后通过向量x与这个子code table中的向量进行距离计算，得到KNN。它的计算量为n*km（n=子空间数，km≈所有向量数/质心数）。

非对称的需要通过PQ code找到质心，在质心所在的子空间中找KNN，查询向量x与已存在向量y的距离通过向量x与y的质心来近似替代。

PQ非对称方式检索³⁴：

PQ非对称方式检索步骤：

查询向量分成为多个子向量
计算子向量和质心矩阵的距离
取子空间中最近的质心，当做查询向量的PQ code
通过查询向量和PQ code对应的质心来计算近似距离，距离可在各自子空间单独计算然后累加

我们前面提到非对称相对对称的近似距离计算要稍微好些，在某些场景下非对称的距离跟实际距离也可能产生较大的差距：

以上图比较好理解。在同一cell中，最远端的vector跟最靠近质心的vector跟质心的距离可能差别较大，只计算到质心距离的partial distance无法体现这种差别。

PQ的参数及其影响
#

PQ至少有两个参数对性能和内存影响是比较大的，分别是子空间数m，子空间的质心数k。

召回率：

The product quantizer is parametrized by the number of subvectors m and the number of quantizers per subvector k ∗ , producing a code of length m × log2 k

子空间有m个，每个子空间的质心数是k^* 个，产生一个PQ code的长度（bits单位）为³⁵： $$ code ; length , (bits)=m \cdot \log_2 k^* $$

子空间m越多，召回率越高；PQ code越长，召回率也越高。PQ code越长其实就是质心数越多。注意这里的具体值是基于论文的数据集的。

内存和复杂度：

k代表聚类质心数，D代表维度，m代表子空间数。k*代表子空间中的质心，D*代表子空间中的维度。

例如k=2048，D=128，m=8，复杂度如下³⁶：

Operation	Memory and complexity
k-means	kD = 2048×128 = 262144
PQ	mkD = (k^(1/m))×D = (2048^(1/8))×128 = 332

可以看到PQ在搜索时复杂度明显的下降。

DiskAnn&Vamana
#

DiskAnn original paper 的Abstract³⁷:

Current state-of-the-art approximate nearest neighbor search (ANNS) algorithms generate indices that must be stored in main memory for fast high-recall search. This makes them expensive and limits the size of the dataset. We present a new graph-based indexing and search system called DiskANN that can index, store, and search a billion point database on a single workstation with just 64GB RAM and an inexpensive solid-state drive (SSD).

当前（论文发布于2019年）的ANN算法为了高召回率和性能都依赖RAM。这种方式不仅昂贵而且限制了数据集的大小。DiskANN只需要64GB RAM和不算贵的SSD。

vamana的构建
#

Vamana 迭代构建一个有向图，首先从一个随机图开始，其中每个节点代表向量空间中的一个数据点。起初，图是高度连接的，所有节点都彼此相连。然后使用一个目标函数对图进行优化，该目标函数旨在最大化最接近节点之间的连接性。这通过修剪大多数随机短程边，同时添加某些长程边来实现，这些长程边连接相距较远的节点（以加速图中的遍历）³⁷

图中有200个二维点并进行了两次迭代。第一次迭代极大的修剪了边，但也把减少路径长度的长边修剪了；当调大阿尔法放开修剪条件时，长边会被增加回来³⁸。具体算法参考论文了，大致是这个意思。

DiskAnn的算法
#

论文的The DiskANN Index Design:

The high-level idea is simple: run Vamana on a dataset P and store the resulting graph on an SSD. At search time, whenever Algorithm 1 requires the out-neighbors of a point p, we simply fetch this information from the SSD. However, note that just storing the vector data for a billion points in 100 dimensions would far exceed the RAM on a workstation! This raises two questions: how do we build a graph over a billion points, and how do we do distance comparisons between the query point and points in our candidate list at search time in Algorithm 1, if we cannot even store the vector data?

在向量集合上运行vamana并存储在SSD上。在数据集非常大时，需要面临两个问题：

如何在有限的内存资源下索引如此大规模的数据集？

k-means和vamana叠加算法：首先，使用 k-means 将数据分成 k 个簇，然后将每个点分配到最近的 i 个簇。通常，i 的数值为 2 就足够了。为每个簇构建基于内存的 Vamana 索引，最后将 k 个 Vamana 索引合并为一个

如果原始数据不能加载到内存中，搜索时如何计算距离？

使用压缩向量（例如PQ）并将压缩向量存储在主存中。

如果将索引数据存储在 SSD 上，必须尽量减少磁盘访问次数和磁盘读写请求，以确保搜索延迟较低；同时失真的压缩会降低召回率。因此，DiskANN论文提出了三个优化策略：

Beam Search：简单来说，就是预加载邻居信息。在搜索点 p 时，如果 p 的邻居点不在内存中，则需要从磁盘加载。由于少量 SSD 随机访问操作所需的时间与一次 SSD 单扇区访问操作所需的时间大致相同，可以一次性加载 W 个未访问点的邻居信息。W 的设置不能太大也不能太小。W 设置过大会浪费计算资源和 SSD 带宽，而设置过小则会增加搜索延迟。
Caching Frequently Visited Vertices：旨在减少磁盘访问次数。在内存中缓存从起始点出发 C 个跳点范围内的所有点。C 的值最好设置在 3 到 4 之间。
Implicit Re-Ranking Using Full-Precision Vectors：因为PQ是失真压缩，基于PQ的距离算法只是邻近实际距离。为了消除这个差异，我们存储每个点到其邻近的所有距离，这个就是full-precision。至于实现原理，简单来说，也是利用了磁盘的加载效率问题。

依据论文，DiskANN的执行效率和召回率好于IVF和HNSW：

References
#

Harnessing the Power of LLMs in Practice: A Survey on ChatGPT and Beyond ↩︎
劉智皓 (Chih-Hao Liu) 66個大型語言模型LLM經典論文 ↩︎ ↩︎
A Survey of Large Language Models ↩︎
一文讲清楚，AI、AGI、AIGC与AIGC、NLP、LLM，ChatGPT等概念 ↩︎
https://en.wikipedia.org/wiki/Prompt_engineering ↩︎ ↩︎
RAG原始论文 ↩︎
Jonathan Katz pgconfdev2024Vectors: How to better support a nasty data type ↩︎
OpenAI推荐使用vector database https://openai.com/index/chatgpt-plugins/ ↩︎
Vector databases (1): What makes each one different? ↩︎
向量数据库性能对比 ↩︎
https://en.wikipedia.org/wiki/Vector_(mathematics_and_physics) ↩︎
https://en.wikipedia.org/wiki/Unit_vector ↩︎
OpenAI解释单位向量的使用 https://platform.openai.com/docs/guides/embeddings/frequently-asked-questions ↩︎
Pinecone Natural Language Processing for Semantic Search https://www.pinecone.io/learn/series/nlp/dense-vector-embeddings-nlp/ ↩︎
姚远漫谈数学中的各种空间 ↩︎
https://en.wikipedia.org/wiki/Euclidean_distance ↩︎
https://en.wikipedia.org/wiki/Taxicab_geometry ↩︎
https://en.wikipedia.org/wiki/Minkowski_distance ↩︎
https://en.wikipedia.org/wiki/Sine_and_cosine ↩︎
Jonathan Katz pgconfeu2023 Vectors are the new JSON ↩︎ ↩︎
https://en.wikipedia.org/wiki/Jaccard_index ↩︎
Vyacheslav Efimov Similarity Search, Part 5: Locality Sensitive Hashing (LSH) ↩︎ ↩︎ ↩︎
https://en.wikipedia.org/wiki/Hamming_distance ↩︎
Vyacheslav Efimov Similarity Search, Part 6: Random Projections with LSH Fores ↩ ↩︎
earthwjl Delaunay三角剖分学习笔记 ↩︎
https://en.wikipedia.org/wiki/Delaunay_triangulation ↩︎
https://en.wikipedia.org/wiki/Voronoi_diagram ↩︎
https://en.wikipedia.org/wiki/Precision_and_recall ↩︎
简书 LSH（局部敏感哈希）算法 ↩︎
HNSW原始论文 ↩︎
Vyacheslav Efimov Similarity Search, Part 4: Hierarchical Navigable Small World (HNSW) ↩︎
https://www.pinecone.io/learn/series/faiss/vector-indexes/ ↩︎ ↩︎
Vyacheslav Efimov Similarity Search, Part 1: kNN & Inverted File Index ↩︎
Vyacheslav Efimov Similarity Search, Part 2: Product Quantization ↩︎ ↩︎
PQ原始论文 ↩︎ ↩︎
Pinecone Faiss Manual https://www.pinecone.io/learn/series/faiss/product-quantization/ ↩︎
DiskANN原始论文 ↩︎ ↩︎
DiskANN, A Disk-based ANNS Solution with High Recall and High QPS on Billion-scale Dataset https://milvus.io/blog/2021-09-24-diskann.md ↩︎

顺序	default	C	en_US	en_US.utf8	zh_CN	zh_CN.utf8
1	〇	A	〇	〇	a	a
2	a	AA	a	a	A	A
3	A	a	A	A	aa	aa
4	aa	aa	aa	aa	AA	AA
5	AA	〇	AA	AA	阿	阿
6	啊	啊	啊	啊	啊	啊
7	阿	阿	阿	阿	〇	〇

顺序	default	C	en_US	en_US.utf8	zh_CN	zh_CN.utf8
1	〇	A	〇	〇	a	a
2	a	AA	a	a	A	A
3	A	a	A	A	aa	aa
4	aa	aa	aa	aa	AA	AA
5	AA	〇	AA	AA	阿	阿
6	啊	啊	啊	啊	啊	啊
7	阿	阿	阿	阿	〇	〇

PostgreSQL内功修炼 on 最后的DBA

UUIDv4和v7两篇精彩文章-碰撞和性能

太长不看 #

UUID v4 碰撞事故 #

原因一：熵源不可靠 #

原因二：npm uuid 包有已知 bug #

原因三：Linux 内核 /dev/random 竞态 #

原因四：Go 的 UUID 库不检查返回值 #

原因五：AMD CPU RNG 的历史缺陷 #

UUID v7 在 PG 16 中的性能对比 #

测试条件 #

性能结果 #

为什么差这么多 #

总结 #

从collation mismatch异常到其原理

问题现象 #

问题分析 #

为什么会报错？ #

源码理解 #

pg_newlocale_from_collation缓存和检查pg_collation #

CheckMyDatabase缓存和检查pg_database #

函数差异 #

为什么仅refresh database后报错不多 #

测试 #

测试：刷db不刷新pg_collation，仅db coll version改变 #

测试：刷db不刷新pg_collation，指定表达式排序报warning #

测试：刷db不刷新pg_collation，新建指定collation的索引报warning #

测试：刷db不刷新pg_collation，已建指定collation的索引不报warning #

这个问题的总结 #

这个问题的解决方案 #

more #

glibc升级相关的精华总结 #

物理迁移后可以做什么 #

ref #

简评ORACLE,MYSQL,PG的逻辑复制

postgresql逻辑复制 #

mysql的binlog #

oracle的逻辑复制 #

查询冲突：从静态表查询冲突到其原理

问题现象 #

现象 #

为什么一个静态表查询冲突是一个值得关注的问题 #

原因分析 #

XLOG_HEAP2_CLEAN #

ResolveRecoveryConflictWithSnapshot #

GetConflictingVirtualXIDs #

页内修剪 #

测试 #

测试：异表查询冲突 #

测试：vacuum产生页内修剪 #

测试：update产生页内修剪 #

测试：hintbit回写产生页内修剪？ #

测试：查询产生页内修剪 #

测试：共享表多database查询冲突 #

结论 #

开发视野 #

运维视野 #

PostgreSQL DDL变更的坑和巧妙方案

Linux内存进阶

内存基本概念 #

buddy #

page table & PTE #

TLB #

反向映射 #

大页 #

C库和系统调用 #

缺页异常 #

写时复制COW #

mmap、brk&共享内存映射区、堆区 #

VM #

compact #

concept & param #

dirty #

concept & param #

观察脏页 #

os dirty !=pg dirty #

swappiness #

swappiness=0 #

inconsistent swap behavior #

memory overcommitment #

太长不看
#

UUID v4 碰撞事故
#

原因一：熵源不可靠
#

原因二：npm uuid 包有已知 bug
#

原因三：Linux 内核 /dev/random 竞态
#

原因四：Go 的 UUID 库不检查返回值
#

原因五：AMD CPU RNG 的历史缺陷
#

UUID v7 在 PG 16 中的性能对比
#

测试条件
#

性能结果
#

为什么差这么多
#

总结
#

问题现象
#

问题分析
#

为什么会报错？
#

源码理解
#

`pg_newlocale_from_collation`缓存和检查`pg_collation`
#

`CheckMyDatabase`缓存和检查`pg_database`
#

函数差异
#

为什么仅refresh database后报错不多
#

测试
#

测试：刷db不刷新pg_collation，仅db coll version改变
#

测试：刷db不刷新pg_collation，指定表达式排序报warning
#

测试：刷db不刷新pg_collation，新建指定collation的索引报warning
#

测试：刷db不刷新pg_collation，已建指定collation的索引不报warning
#

这个问题的总结
#

这个问题的解决方案
#

more
#

glibc升级相关的精华总结
#

物理迁移后可以做什么
#

ref
#

postgresql逻辑复制
#

mysql的binlog
#

oracle的逻辑复制
#

问题现象
#

现象
#

为什么一个静态表查询冲突是一个值得关注的问题
#

原因分析
#

XLOG_HEAP2_CLEAN
#

ResolveRecoveryConflictWithSnapshot
#

GetConflictingVirtualXIDs
#

页内修剪
#

测试
#

测试：异表查询冲突
#

测试：vacuum产生页内修剪
#

测试：update产生页内修剪
#

测试：hintbit回写产生页内修剪？
#

测试：查询产生页内修剪
#

测试：共享表多database查询冲突
#

结论
#

开发视野
#

运维视野
#

内存基本概念
#

buddy
#

page table & PTE
#

TLB
#

反向映射
#

大页
#

C库和系统调用
#

缺页异常
#

写时复制COW
#

mmap、brk&共享内存映射区、堆区
#

VM
#

compact
#

concept & param
#

dirty
#

concept & param
#

观察脏页
#

os dirty !=pg dirty
#

swappiness
#

swappiness=0
#

inconsistent swap behavior
#

memory overcommitment
#

concept & param
#

reserve内存和overcommmit
#

观察overcommit
#

watermark
#

min_free_kbytes
#

watermark_scale_factor
#

watermark_boost_factor
#

顺序	default	C	en_US	en_US.utf8	zh_CN	zh_CN.utf8
1	〇	A	〇	〇	a	a
2	a	AA	a	a	A	A
3	A	a	A	A	aa	aa
4	aa	aa	aa	aa	AA	AA
5	AA	〇	AA	AA	阿	阿
6	啊	啊	啊	啊	啊	啊
7	阿	阿	阿	阿	〇	〇