PostgreSQL案例 on 最后的DBA

案例-起库失败和sysv共享内存

Mon, 09 Mar 2026 00:00:00 +0000

问题现象
#

数据库实例RSS内存打满，日志有OOM信息，库挂了。这里不分析OOM原因。

但是起库的时候失败，从日志来看总共起库4、5次都失败：

2026-02-12 09:15:21 CST::@:[578272]: FATAL: pre-existing shared memory block (key 2048, ID 1328250881) is still in use
2026-02-12 09:15:21 CST::@:[578272]: HINT: Terminate any old server processes associated with data directory "/data".
2026-02-12 09:15:21 CST::@:[578272]: LOG: database system is shut down
2026-02-12 09:21:03 CST::@:[658824]: FATAL: pre-existing shared memory block (key 2048, ID 1328250881) is still in use
2026-02-12 09:21:03 CST::@:[658824]: HINT: Terminate any old server processes associated with data directory "/data".
2026-02-12 09:21:03 CST::@:[658824]: LOG: database system is shut down
2026-02-12 09:31:12 CST::@:[794791]: LOG: redirecting log output to logging collector process
2026-02-12 09:31:12 CST::@:[794791]: HINT: Future log output will appear in directory "/data/pg_log".
2026-02-12 09:31:37 CST::@:[801049]: FATAL: lock file "postmaster.pid" already exists
2026-02-12 09:31:37 CST::@:[801049]: HINT: Is another postmaster (PID 794791) running in data directory "/data"?
2026-02-12 09:32:34 CST::@:[814396]: FATAL: lock file "postmaster.pid" already exists
2026-02-12 09:32:34 CST::@:[814396]: HINT: Is another postmaster (PID 794791) running in data directory "/data"?

启动成功是因为DBA在起库前执行ipcrm -m xxx，然后启动成功的。

虽然快速解决问题，但是仍有很多疑问：

为什么这种场景在现实种不算太多见？
start.log起库报错有2类，分别对应什么操作和逻辑？
如果PM都不在了共享内存还可以存在吗？
这段共享内存如何定位和清理？
PG共享内存有多段，这段共享内存是哪一段？
除了ipcrm -m还有其他起库办法吗

报错分析：`pre-existing shared memory block`
#

3种共享内存
#

正常来说，PG起库后共享内存有三段。

以默认“shared_memory_type='mmap'+未使用大页”为例：

## 从PG申请的虚拟内存查看PG真实使用共享内存
cat /proc/`head -1 $PGDATA/postmaster.pid`/smaps | grep -E "\-s"

2b61b0563000-2b61b0564000 rw-s 00000000 00:04 116293664 /SYSV00001000 (deleted)
2b61b057f000-2b61b05b3000 rw-s 00000000 00:12 1501001168 /dev/shm/PostgreSQL.1193490778
2b61bbac2000-2b61fa67a000 rw-s 00000000 00:04 1500999610 /dev/zero (deleted)

如上所示，从上往下分别是SYSV起库使用的共享内存、并行计算使用的共享内存、sharedbuffers使用的共享内存。

如果sharedbuffers使用了大页，或者sharedbuffers type是SYSV而不是mmap，输出会稍微有些区别。

大页：

2aaaaac00000-2aba9ca00000 rw-s 00000000 00:0e 48453452 /anon_hugepage (deleted)
2b08f2eea000-2b08f2eeb000 rw-s 00000000 00:04 50692152 /SYSV00001000 (deleted)
2b08f2f05000-2b08f302d000 rw-s 00000000 00:12 48436142 /dev/shm/PostgreSQL.1345689218

shared_memory_type = ‘sysv’：

2b03b3ceb000-2b03b3d1f000 rw-s 00000000 00:12 1572332304 /dev/shm/PostgreSQL.2883611352
2b03bf0c2000-2b03fdc7a000 rw-s 00000000 00:04 143917075 /SYSV00001000 (deleted)

汇总如下：

PG共享内存配置	smaps共享内存段数	sharedbuffers smaps	sysv smaps
shared_memory_type=mmap，没有大页	3段共享内存	/dev/zero	/SYSV00001000
shared_memory_type=sysv，没有大页	2段共享内存	/SYSV00001000	/SYSV00001000
shared_memory_type=mmap，有大页	3段共享内存	/anon_hugepage	/SYSV00001000
shared_memory_type=sysv，有大页	不支持	不支持

那么现在问题来了，报错分析：pre-existing shared memory block时对应的哪个共享内存？

源码分析
#

源码搜报错很容易找到关键代码位置：src/backend/port/sysv_shmem.c

首先理解sysv shmem是干嘛的，以下截取自零散的readme：

We still require a SysV shmem block to
 * exist, though, because mmap'd shmem provides no way to find out how
 * many processes are attached, which we need for interlocking purposes.
 
 * As of PostgreSQL 9.3, we normally allocate only a very small amount of
 * System V shared memory, and only for the purposes of providing an
 * interlock to protect the data directory. The real shared memory block
 * is allocated using mmap(). This works around the problem that many
 * systems have very low limits on the amount of System V shared memory
 * that can be allocated. Even a limit of a few megabytes will be enough
 * to run many copies of PostgreSQL without needing to adjust system settings.

sysv shmem可以找共享内存是否是attached，mmap不能实现此功能
这段sysv shmem是用来保护datadir的；shared buffer用的是mmap（默认）不是sysv
这段sysv shmem非常小（从虚拟内存地址可以看出申请的是4K=2b61b0563000-2b61b0564000）

再看shm的状态enum：

typedef enum
{
	SHMSTATE_ANALYSIS_FAILURE,	/* unexpected failure to analyze the ID */
	SHMSTATE_ATTACHED,			/* pertinent to DataDir, has attached PIDs */
	SHMSTATE_ENOENT,			/* no segment of that ID */
	SHMSTATE_FOREIGN,			/* exists, but not pertinent to DataDir */
	SHMSTATE_UNATTACHED			/* pertinent to DataDir, no attached PIDs */
} IpcMemoryState;

主要是关注ATTACHED,FOREIGN,UNATTACHED。

sysv shmem是用来保护datadir目录的，比如常见的场景是要确认这个目录不会被跑2个实例。既然有shmem共享内存，那么因为各种奇怪原因，这个共享内存也有可能不是这个目录或者这个进程的，所有是FOREIGN状态。如果共享内存对应到datadir了，但没有进程在运行，那么应该是UNATTACHED，有进程运行那么是ATTACHED。

这时再来看PGSharedMemoryCreate函数抛出的报错：

PGShmemHeader *
PGSharedMemoryCreate(Size size,
					 PGShmemHeader **shim)
{...
 for (;;) //死循环
	{..
 shmid = shmget(NextShmemSegID, sizeof(PGShmemHeader), 0);//shmget获取shmem共享内存并返回shmid
		if (shmid < 0)
		{
			oldhdr = NULL;
			state = SHMSTATE_FOREIGN;
		}
		else
			state = PGSharedMemoryAttach(shmid, NULL, &oldhdr);//找到这段shmem共享内存的状态
 
 switch (state)//根据共享内存的状态执行不同的动作
		{ 
 ...//这里只展示了2种，shm有attach和没有attach
			case SHMSTATE_ATTACHED: //shm有attach的情况，抛出报错（也就是问题现象出现的报错）
				ereport(FATAL,
						(errcode(ERRCODE_LOCK_FILE_EXISTS),
						 errmsg("pre-existing shared memory block (key %lu, ID %lu) is still in use",
								(unsigned long) NextShmemSegID,
								(unsigned long) shmid),
						 errhint("Terminate any old server processes associated with data directory \"%s\".",
								 DataDir)));
				break;
 ...
			case SHMSTATE_UNATTACHED://shm是unattach的

				/*
				 * The segment pertains to DataDir, and every process that had
				 * used it has died or detached. Zap it, if possible, and any
				 * associated dynamic shared memory segments, as well. This
				 * shouldn't fail, but if it does, assume the segment belongs
				 * to someone else after all, and try the next candidate.
				 * Otherwise, try again to create the segment. That may fail
				 * if some other process creates the same shmem key before we
				 * do, in which case we'll try the next key.
				 */
 //代表内存段关联Data目录，且没有进程还持有这个段
				if (oldhdr->dsm_control != 0)
					dsm_cleanup_using_control_segment(oldhdr->dsm_control);
				if (shmctl(shmid, IPC_RMID, NULL) < 0)
					NextShmemSegID++; //注意这里的ShmemSegID递增循环
				break;
		}
 ...
 }
 ...
 }

可以看到shmem attached时会抛出报错。如果没有attach，会无限循环尝试清理这段共享内存并shmemsegid+1申请新的共享内存。

第一种情况对应这个故障
第二种情况对应实例崩溃仍然可以正常起库

sysv shmem
#

PG10及以后postmaster.pid，sysv_shmem相关的逻辑大改，10以后基本没有变过。本文只分析了10以后的逻辑。

pidfile.h:

#define LOCK_FILE_LINE_SHMEM_KEY	7

sysv_shmem.c，InternalIpcMemoryCreate()：

	{
		char		line[64];

		sprintf(line, "%9lu %9lu",
				(unsigned long) memKey, (unsigned long) shmid);
		AddToDataDirLockFile(LOCK_FILE_LINE_SHMEM_KEY, line);
	}

从源码可以看出，shmem信息保存在postmaster.pid文件第七行，分别写的是shmkey和shmid。

> cat postmaster.pid 
242712
/data
1772698474
8531
/tmp
0.0.0.0
 4096 143917078 # <----here
ready

什么是shmkey和shmid
#

在pg源码中是这样调用的，InternalIpcMemoryCreate()：

			shmid = shmget(memKey, 0, IPC_CREAT | IPC_EXCL | IPCProtection);

PG以shmkey/memkey为种子key，向内核申请shmem并返回唯一标识符shmid。

shmid高度依赖服务器或者说服务器内存的状态。对于PG来说，快速重启实例，前后的shmid可能会相同或者+1，这跟linux内核机制相关；服务器重启那就完全不一样。

可以这样增加理解度：无论服务器是否重启，shmkey/memkey都可以是固定值，因为毕竟是用户输入（即PG）；而在服务器重启前后，即便传入同一shmkey，获取的shmid不太可能是同一值。

PG是怎么拿shmkey的
#

PGSharedMemoryCreate()：

	/*
	 * We use the data directory's ID info (inode and device numbers) to
	 * positively identify shmem segments associated with this data dir, and
	 * also as seeds for searching for a free shmem key.
	 */
	if (stat(DataDir, &statbuf) < 0)
		ereport(FATAL,
				(errcode_for_file_access(),
				 errmsg("could not stat data directory \"%s\": %m",
						DataDir)));
...
	/*
	 * Loop till we find a free IPC key. Trust CreateDataDirLockFile() to
	 * ensure no more than one postmaster per data directory can enter this
	 * loop simultaneously. (CreateDataDirLockFile() does not entirely ensure
	 * that, but prefer fixing it over coping here.)
	 */
	NextShmemSegID = statbuf.st_ino;

	for (;;)
	{
		IpcMemoryId shmid;
		PGShmemHeader *oldhdr;
		IpcMemoryState state;

		/* Try to create new segment */
		memAddress = InternalIpcMemoryCreate(NextShmemSegID, sysvsize);
		if (memAddress)
			break;				/* successful create and attach */

		/* Check shared memory and possibly remove and recreate */

		/*
		 * shmget() failure is typically EACCES, hence SHMSTATE_FOREIGN.
		 * ENOENT, a narrow possibility, implies SHMSTATE_ENOENT, but one can
		 * safely treat SHMSTATE_ENOENT like SHMSTATE_FOREIGN.
		 */
		shmid = shmget(NextShmemSegID, sizeof(PGShmemHeader), 0);

PG通过stat获取datadir的状态，其中包含datadir的inode，PG直接将datadir.inode当作shmkey。

在PG中shmem key跟datadir的inode强相关，一般情况下shmem key=datadir inode

验证示例：

> ls -id $PGDATA
4096 /lzlcloud/pg8574/data
> cat postmaster.pid |head -7|tail -1
 4096 143917090

可以看到datadir.inode=shmkey=4096。

PG在云环境下的shmkey
#

上面说一般情况shmid=datadir.inode，实际上这在云环境中基本不是这个情况。

我们的云环境：

> ls -id /lzlcloud/pg8298/data
4096 /lzlcloud/pg8298/data
> ls -id /lzlcloud/pg8388/data
4096 /lzlcloud/pg8388/data
> ls -id /lzlcloud/pg8095/data
4096 /lzlcloud/pg8095/data

> cat /lzlcloud/pg8298/data/postmaster.pid|head -7|tail -1
 4096 971833391
> cat /lzlcloud/pg8388/data/postmaster.pid|head -7|tail -1
 4097 62128161
> cat /lzlcloud/pg8095/data/postmaster.pid|head -7|tail -1
 4098 143163441

data盘dir的inode都是4096，而shmkey是4096、4097、4098

why?

inode的问题跟磁盘的文件系统有关系：

每个文件系统有独立的inode
文件系统预留了一些inode，前几位是不能使用的。根据不同的挂载方式，我们data盘真正的inode从4096开始

也就是说datadir.inode=4096这是我们云环境磁盘挂载的默认行为。其他环境可能不一样，未深入分析。不过以相同文件系统和相同方式挂载挂载pg datadir的话，仍有可能inode数值相等。

shmkey的问题跟PG源码相关,PGSharedMemoryCreate()：

	for (;;)
	{	
 ...
 NextShmemSegID = statbuf.st_ino;
 ...
		shmid = shmget(NextShmemSegID, sizeof(PGShmemHeader), 0);
		...
		switch (state)
		{
			case SHMSTATE_FOREIGN:
				NextShmemSegID++;
				break;

本来shmkey=datadir.inode，但是由于可能申请到shmem是foreign的，所以shmkey+1再申请一次。

例如postmaster.pid文件shmkey=4097的那个实例，它起库时shmkey=4096，但是发现shmid那个内存段被其他实例使用了（就是另一个shmkey=4096的PG实例），它让shmkey+1再申请了另一个shmid共享内存段。

同理shmkey=4098的那个实例加了2次才找到空闲的shmkey对应的shmid。

shmid的关联性
#

sysv的shmid可以在起库的报错日志、postmaster.pid文件第7行、虚拟内存地址smaps中均可以找到，并通过sysv共享内存命令的ipcs命令查看和ipcrm命令清理。

示例：注意以下shmid=143917078

起库报错日志：

pg_ctl: another server might be running; trying to start server anyway
waiting for server to start....2026-03-05 16:02:19 CST::@:[262388]: FATAL: pre-existing shared memory block (key 4096, ID 143917078) is still in use

postmaster.pid文件第七行：

> cat postmaster.pid |head -7|tail -1
 4096 143917078

虚拟内存smaps：

cat /proc/`head -1 $PGDATA/postmaster.pid`/smaps | grep -E "\-s" 
2ad2b5189000-2ad2b518a000 rw-s 00000000 00:04 143917078 /SYSV00001000 (deleted)

通过shmid sysv共享内存id查看和清理：

ipcs -m -i 143917078 #清理：ipcrm -m shmid

Shared memory Segment shmid=143917078
uid=6001 gid=6001 cuid=6001 cgid=6001
mode=0600 access_perms=0600
bytes=56 lpid=242712 cpid=242712 nattch=10
att_time=Thu Mar 5 16:14:51 2026 
det_time=Thu Mar 5 16:14:49 2026 
change_time=Thu Mar 5 16:14:34 2026 

测试
#

生产问题复现
#

持有一个backend进程永不退出，kill -9 PM

> cat postmaster.pid
 4096 143917076
 
> ipcs -m -i 143917076 #shmem id
Shared memory Segment shmid=143917076
uid=6001 gid=6001 cuid=6001 cgid=6001
mode=0600 access_perms=0600
bytes=56 lpid=241567 cpid=64757 nattch=23 

> kill -stop 107648 #任意一个backend

> kill -9 64757 #postmaster或者其他的

> ipcs -m -i 143917076
Shared memory Segment shmid=143917076
uid=6001 gid=6001 cuid=6001 cgid=6001
mode=0600 access_perms=0600
bytes=56 lpid=252283 cpid=64757 nattch=1 #nattch != 0

> pg_ctl start -D $PGDATA
pg_ctl: another server might be running; trying to start server anyway
waiting for server to start....2026-03-05 16:02:19 CST::@:[262388]: FATAL: pre-existing shared memory block (key 4096, ID 143917076) is still in use
2026-03-05 16:02:19 CST::@:[262388]: HINT: Terminate any old server processes associated with data directory "/data".
 stopped waiting
pg_ctl: could not start server

nattach=1，实例无法启动。

实例奔溃正常起库
#

其实就是kill实例然后启动

> cat postmaster.pid 
 4096 143917077
 
> ipcs -m -i 143917077 #shmem id
Shared memory Segment shmid=143917077
uid=6001 gid=6001 cuid=6001 cgid=6001
mode=0600 access_perms=0600
bytes=56 lpid=154800 cpid=134329 nattch=18

> kill -9 134329 #postmaster或者其他的

> cat postmaster.pid 
 4096 143917077

> ipcs -m -i 143917077 #shmem id没有改变，shmem仍然存在
Shared memory Segment shmid=143917077
uid=6001 gid=6001 cuid=6001 cgid=6001
mode=0600 access_perms=0600
bytes=56 lpid=169360 cpid=134329 nattch=0 #nattch=0

> ipcs -m -i 143917077 #shmem id没有改变，shmem仍然存在

> pg_ctl start -D $PGDATA # 起库成功
pg_ctl: another server might be running; trying to start server anyway
waiting for server to start....2026-03-05 16:14:34 CST::@:[242712]: LOG: redirecting log output to logging collector process
2026-03-05 16:14:34 CST::@:[242712]: HINT: Future log output will appear in directory "/data/pg_log".
 done
server started

> ipcs -m -i 143917077 #残留的shmem起库时被清理
ipcs: id 143917077 not found
> ipcs -m -i 143917078 #shmemid起库时被+1
Shared memory Segment shmid=143917078
uid=6001 gid=6001 cuid=6001 cgid=6001
mode=0600 access_perms=0600
bytes=56 lpid=273571 cpid=242712 nattch=26

> cat postmaster.pid # shmkey不变，shmid+1
 4096 143917078

正常kill -9然后启动，可以正常启动，残留的shmem会在启动时被清理。shmkey不变是因为inode=4096且shmkey=4096没有被占用，shmid+1这是linux内核行为，至少说明不是使用的同一段shmem。

持有文件但不持有shmem
#

因为起库跟datadir inode相关，inode跟shmem id相关，起库本质上是在检查shmem是不是被其他进程持有，而不是文件fd是否还被其他进程持有。所以这里测试不持有共享内存但持有文件fd的进程logger。

$ cat /proc/77300/smaps | grep -E "\-s" #这是logger进程，检查它没有用共享内存
$ kill -stop 77300 #stop logger
$ kill -9 77076 #kill -9 pm
$ cat postmaster.pid #文件仍在
77076
/lzlcloud/pg8531/data
1772700343
8531
/tmp
0.0.0.0
 4096 143917080
ready 
$ ipcs -m -i 143917080 #共享内存仍在

Shared memory Segment shmid=143917080
uid=6001 gid=6001 cuid=6001 cgid=6001
mode=0600 access_perms=0600
bytes=56 lpid=77319 cpid=77076 nattch=0
att_time=Thu Mar 5 17:27:11 2026 
det_time=Thu Mar 5 17:27:15 2026 
change_time=Thu Mar 5 16:45:43 2026 

$ ps -ef|grep 77300 #进程仍在
postgres 77300 1 0 16:45 ? 00:00:00 postgresql: lzldb: logger 
postgres 135246 46622 0 17:27 pts/1 00:00:00 grep --color=auto 77300
$ pg_ctl start -D $PGDATA #起库成功
pg_ctl: another server might be running; trying to start server anyway
waiting for server to start....2026-03-05 17:27:55 CST::@:[140497]: LOG: redirecting log output to logging collector process
2026-03-05 17:27:55 CST::@:[140497]: HINT: Future log output will appear in directory "/data/pg_log".
 done
server started

logger持有data目录下的文件，但不关联共享内存，不会阻止起库

删除postmaster.pid文件起库失败
#

流程跟上面差不多：持有1个backend进程，kill -9 PM，删除postmaster.pid文件，起库。

过程不贴了，结果是起库失败，报错如下：

waiting for server to start....2026-03-06 15:29:48 CST::@:[22475]: FATAL: pre-existing shared memory block (key 4098, ID 171868173) is still in use
2026-03-06 15:29:48 CST::@:[22475]: HINT: Terminate any old server processes associated with data directory "/data".
2026-03-06 15:29:48 CST::@:[22475]: LOG: database system is shut down

可以看出，有僵尸进程持有shmem的情况下，即便删除包含shmid的postmaster.pid文件，PG仍然能找到对应的shmid。

关闭一个其他库，启动当前库
#

pg会分析2个地方shmid是否是当前的

以datadir.inode当作shmkey对应的shmid，或者shmkey++
postmaster.pid中的shmid

即便直接删除postmaster.pid，PG仍然可以知道shmem是不是被其他进程持有。但是我们可以通过datadir.inode和shmkey++的特性让他起库。

因为根据之前分析，我们云环境datadir inode都是4096，shmkey不同是因为源码有shmkey++的逻辑。所以我们可以：启动或停止一个datadir.inode=4096的PG库，让当前PG库启动时shmkey++多一个或者少一个，拿到不同的shmid。

$ kill -stop 165245 
$ kill -9 164411 #停当前库并持有一个当前库backend进程

$ pg_ctl stop -D /pg8531/data # 停一个其他库
waiting for server to shut down.... done
server stopped
$ pg_ctl start -D /pg8574/data # 启动当前库，会失败，因为postmaster.pid没有删除
rase_ctl: another server might be running; trying to start server anyway
waiting for server to start....2026-03-05 18:22:35 CST::@:[196209]: FATAL: pre-existing shared memory block (key 4097, ID 143917087) is still in use
2026-03-05 18:22:35 CST::@:[196209]: HINT: Terminate any old server processes associated with data directory "/pg8574/data".
 stopped waiting
rase_ctl: could not start server
Examine the log output.

$ mv /lzlcloud/pg8574/data/postmaster.pid{,.bak} # 删除当前库的postmaster.pid
$ pg_ctl start -D /lzlcloud/pg8574/data #再起当前库，成功
2026-03-05 18:23:09 CST::@:[207725]: LOG: redirecting log output to logging collector process
2026-03-05 18:23:09 CST::@:[207725]: HINT: Future log output will appear in directory "/lzlcloud/pg8574/data/pg_log".
 done
server started

$ ipcs -m -i 143917087 #shmid对应的sysv共享内存仍然被我们持有

Shared memory Segment shmid=143917087
uid=6001 gid=6001 cuid=6001 cgid=6001
mode=0600 access_perms=0600
bytes=56 lpid=196209 cpid=164411 nattch=1
att_time=Thu Mar 5 18:22:35 2026 
det_time=Thu Mar 5 18:22:35 2026 
change_time=Thu Mar 5 18:21:04 2026 

可以启动，当前库共享内存申请了另一块，之前那个共享内存没有被清理。这就是在云环境下关其他库启动当前库的骚操作。

这里有个小小的前提，关的其他库不仅要inode=当前库inode，还要其他库shmkey<当前库shmkey。

报错分析：`lock file "postmaster.pid" already exists`
#

这个问题比“共享内存已存在”简单多了。

起库时本身就会检查lock file、lock file中的pid，CreateLockFile():

		if (other_pid != my_pid && other_pid != my_p_pid &&
			other_pid != my_gp_pid)
		{
			if (kill(other_pid, 0) == 0 ||
				(errno != ESRCH && errno != EPERM))
			{
				/* lockfile belongs to a live process */
				ereport(FATAL,
						(errcode(ERRCODE_LOCK_FILE_EXISTS),
						 errmsg("lock file \"%s\" already exists",
								filename),
						 isDDLock ?
						 (encoded_pid < 0 ?
						 errhint("Is another postgres (PID %d) running in data directory \"%s\"?",
								 (int) other_pid, refName) :
						 errhint("Is another postmaster (PID %d) running in data directory \"%s\"?",
								 (int) other_pid, refName)) :
						 (encoded_pid < 0 ?
						 errhint("Is another postgres (PID %d) using socket file \"%s\"?",
								 (int) other_pid, refName) :
						 errhint("Is another postmaster (PID %d) using socket file \"%s\"?",
								 (int) other_pid, refName))));
			}
		}

测试就更简单，在库启动的时候再启动一次：

$ pg_ctl start -D /pg8531/data
pg_ctl: another server might be running; trying to start server anyway
waiting for server to start....2026-03-06 15:59:05 CST::@:[89145]: FATAL: lock file "postmaster.pid" already exists
2026-03-06 15:59:05 CST::@:[89145]: HINT: Is another postmaster (PID 255500) running in data directory "/pg8531/data"?
 stopped waiting
pg_ctl: could not start server
Examine the log output.

所以故障时的start.log后面几个报错是因为库已经启动了，多启动了几次。

总结
#

PG在起库时，会先开辟一个sysv shmem（不是mmap对应的share buffers）以锁定datadir。锁定是通过datadir的inode号当作shmkey通过shmget申请的，并返回shmem唯一标识符shmid。由于可能申请的shmem被其他进程使用，PG会让shmkey++无限循环指到申请到没有被人占用的shmem。postmaster.pid第七行分别保存shmkey和shmid。在云环境下通常可以看到共享PG实例的shmkey递增的现象，这是因为data盘挂载方式相同使用了相同的inode，shmkey++导致。

如果PG实例被意外干掉，shmem不会被清理，正常情况下没有僵尸进程持有共享内存，那么起库会清理这段shmem并正常起库；异常情况下僵尸进程持有共享内存，起库会失败，此时需要介入处理。

推荐的处理方式：

ipcrm -m（最推荐）
lsof找到僵尸进程并kill
重启主机

不推荐但可以起库的方式：

mv postmaster.pid+关闭一个其他PG库（其他PG库的shmkey<当前PG库）
mv postmaster.pid+重新挂载data盘并改变inode

最后回答开头的问题：

为什么这种场景在现实种不算太多见？

实例异常宕机+仍然有僵尸进程没有被清理。有些情况是异常宕机没有僵尸进程，正常起库就行了。

start.log起库报错有2类，分别对应什么操作和逻辑？

共享内存被占用的报错是因为实例异常宕机+仍然有僵尸进程；postmaster.pid存在的报错是因为起库多次

如果PM都不在了共享内存还可以存在吗？

PM都不在了共享内存可以存在，PG的进程不一定会自己跑挂或者被OS处理；但是所有进程都不在了共享内存应该不存在

这段共享内存如何定位和清理？

起库的start.log可以找到shmid，ipcrm -m $shmid命令可以清理。

PG共享内存有多段，这段共享内存是哪一段？

sysv shmem，用于保护datadir，一定存在，参考“三种共享内存”部分。与mmap下的sharebuffers是2个东西。

可以通过inode或者文件找到对应的shmem吗？

LINUX在用户态没有提供通过inode或者文件找到对应shmem的接口（这句话AI含量100%，经过多个模型交叉验证）。PG是通过datadir的inode当作种子shmkey去申请的shmem共享内存，本质上不是通过inode直接找到对应的shmem，PG对shmem共享内存使用自己的寻找机制，但不绝对对应，shkey++就是一个折衷起库逻辑。

pg数据库运维经验2025

Sun, 11 Jan 2026 00:00:00 +0000

主要是技术性运维总结，主打通俗易懂和快速上手，同时也是对PG数据库运维的阶段性总结，希望对PGer有所帮助。

历史的运维经验：pg数据库运维经验2024。注意，本篇不会包含历史的运维经验的内容。

CPU
#

SQL性能问题是PG异常处理根因中最多的，这包含SQL本身性能不好，索引一般、突发并发高、执行计划突变。对于postgres这种没有完善的绑定执行计划的方案的库来说，有一个DBA团队帮助设计数据模型、数据访问方式、索引、调整执行计划等显得尤为重要，实际上可以极大缓解CPU突然打满的问题。

执行计划
#

执行计划突变是cost-base优化器的老毛病，postgres也不会例外。

DISTINCT不准确
#

案例-从distinct不准确到DISTINCT的计算原理

由于默认采样数最大是3w行，也就是说这种采样算法只要超过3w，即表比较大的时候，预估distinct很可能偏小。注意这里的数据不能有太多唯一值。

测试一张表不同采样数的差异：

表有reltuples=8亿，relpages=2kw，size=175GB，真实的某字段distinct 1亿

target statistics	pages采样比例（1）	tuples采样比例（1）	n_distinct	执行时间
50	0.00075	0.00001875	6w	2秒
100	0.0015	0.0000375	11w	5秒
1000	0.015	0.000375	103w	58秒
3000	0.045	0.001125	268w	3分01秒
10000	0.15	0.00375	675w	7分21秒

（target statistics 最大值10000）

可以粗糙的总结：n_distinct和analyze的执行时间随采样数量成倍增长。

n_distinct随采样数量增长，pages和tuples却一直都很准确。

generic plan的干扰
#

pg的执行计划要考虑generic plan。generic plan与传参是无关的，它用一些默认值计算cost，并与前五次计划的代价进行对比，谁小用谁。

案例-添加索引性能下降和generic plan

一、generic plan预估不准的问题分类

因为有5次机制对比，所以generic plan的问题可以分为2种：

前5次SQL的执行没有普遍性。跟前5次执行计划相关性大，依赖数据倾斜和前5次参数是否具有普遍性。
generic plan本身有问题。generic plan因为数据倾斜或数据均衡但无法准确计算选择率，导致generic plan本身执行效率低下

二、解决方案参考

generic plan问题在分区表上可能会出现，分区键是连续的，扫描所有分区建选择率应该为1，但generic plan为0.05，很可能导致走“全索引”扫描这种场景。

所以在优化的时候需要考虑更多：

不要建太多索引迷惑优化器
排除generic plan的干扰。用EXECUTE真实跑6次
会话级别set plan_cache_mode='force_generic_plan'; or set plan_cache_mode='force_custom_plan';对比执行计划；或者在pg16+用explain (GENERIC_PLAN)对比执行计划

语法参考：

--prepare/excute
PREPARE sql1(text) AS
SELECT COUNT(*) FROM LZL where a=$1;

EXECUTE sql1('zzz'); --跑6次再说
EXPLAIN EXECUTE sql1('zzz');

select * from pg_prepared_statements --查看prepare语句信息，只能看当前会话

--对比执行计划，设置会话参数后执行EXPLAIN EXECUTE
set plan_cache_mode='force_generic_plan'
set plan_cache_mode='force_custom_plan'
--直接查看genetic plan,16+
explain (GENERIC_PLAN) xx 

行锁导致的LWLock:Lockmanager
#

LWLock Lockmanager问题一般发生在分区表上，高并发没有分区键的SQL容易发生。而今年又发现一个新的场景：行锁导致的LWLock:Lockmanager

这不算一个很大的问题，因为更新同一行会阻塞是众所周知的。只是没有测试前我也没有想到更新同一行也会产生LWLock:Lockmanager。不算特别有价值的案例，在观察等待事件有LWLock:Lockmanager时考虑行锁即可。

idle连接数
#

PostgreSQL的性能基本随着大版本提升而稳定提升。其中PG14对快照的获取和维护所有backend的事务信息都做了大幅优化，使得14对多idle connection的提升明显：

（https://techcommunity.microsoft.com/blog/adforpostgresql/improving-postgres-connection-scalability-snapshots/1806462）

但，这不代表14以后就不需要关注idle连接数了，它仍然会消耗backend事务维护成本、上下文切换、使内存碎片化等问题，导致数据库的idle连接数越多性能越差。

一般业务连接本身是有轮询和保活的，保持一定的idle是为了不让每个请求都新建连接，那样消耗就大了去了。一般小库是不太需要关注连接数（只要别太离谱），因为CPU买的不多，系统也没那么重要，而且扩容比较容易。但是大库又不一样了。CPU数就是主机资源上限，再加也加不上去了。大库本身idle connection就很多，再增加空闲连接不一定会增加系统的吞吐量，特别是CPU已经不太够时，增加idle连接会起反向效果。

以PG15压测经验来看，以5k idle为基线，上1w个idle时，idle的维护会多使用2-5个vCPU，上2w个idle时，多使用5-10个vCPU。大致情况是这样。

idle in transaction
#

去年狠狠把长事务批判了一遍，因为长事务对PG的影响要比其他库（oracle、mysql等）要大。但这问题不大，做好告警和运维，长事务问题是可解决的。

在监控会话状态时，一般都要查看会话状态，比如active代表正在运行，代表在跑SQL，idle in transaction代表事务在空闲状态，代表事务没有在跑SQL也没有提交。所有的pg_stat_activity.state如下，pg15：

Current overall state of this backend. Possible values are:

active: The backend is executing a query.
idle: The backend is waiting for a new client command.
idle in transaction: The backend is in a transaction, but is not currently executing a query.
idle in transaction (aborted): This state is similar to idle in transaction, except one of the statements in the transaction caused an error.
fastpath function call: The backend is executing a fast-path function.
disabled: This state is reported if track_activities is disabled in this backend.

常见的state只有active,idle,idle in transaction,idle in transaction (aborted)。idle in transaction有一个误区是，它只代表当前时间没有运行sql，没有提交事务，不代表这个事务空闲了很久。不能通过事务xact_start +idle in transaction判断事务多久没跑，而应该通过state_change +idle in transaction来判断。

内存
#

内存问题非常棘手，而且今年处理了非常多，也找到了一些很好的解决方案。不过内存体系知识还是比较大，只能尽我所能尽量简化这部分知识，直达现象、结果和解决方案。

内存问题和大页
#

pg内存问题分类：

pg内存问题相关wchan：

大页对内存碎片、CG内直接内存回收都非常好的效果。

大页实际效果看压测：https://docs.paic.com.cn/#/post/84479375

大页八股文理论效果：

减少TLB的压力
减少pagetable在主内存上的大小
大页在物理上是连续的。连续的物理内存访问比不连续的物理内存访问更优
当使用大页时，page是直接映射的，不会使用多级的pte条目

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

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

内存知识比较多，其他的参考Linux内存进阶。总之要记住如下几点：

优先排除os层问题再解决pg实例层问题
大页有神奇的效果，但极少数情况仍没有效果
很多小伙伴不会关注pgpgin/pgpgout/pgfree，甚至不会关心pgscank/pgscand，只会看cpu、内存用了多少。这对运维pg库来说是不够的。
没有良好的运维体系pg的内存会很不稳定

值得注意的cgroup知识
#

cgroup的知识也不少，参考之前的文章吧，这里做个简单总结。

cgroup v1有自身的缺陷：

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

未解之谜
#

大页确实解决了很多问题，但不能解决所有内存问题。不能解决的这部分问题待研究，希望26年可以弄明白。

关注OS
#

关注OS的一切
#

学习开源库需要了解操作系统

（这句话已忘记出处）

想要运维好Postgres，了解OS的原理是十分重要的。Postres数据库就是构建在OS（特别是linux）之上，linux提供什么它用什么，postgres是linux的生态。所以想要深入理解运行原理，得先了解操作系统原理。

优先排除os层问题再解决pg实例层问题

（这句话是我说的）

一、CPU

因为postgres还用不了NUMA，无论是主机资源全给，还是CGROUP（or pod）管理cpu，都不太需要深入到操作系统层CPU原理。CPU问题看看SQL或者PG的堆栈基本够了。

二、内存

内存参考内存章节。内存问题是需要深入到OS层的。

三、进程

从操作系统查看PG进程的状态非常重要，包括但不限于要查看D、wchan、RSS、SYSCALL

四、主机状态和日志

监控主机状态、包括主机层CPU、内存、IO、网络、日志。非常重要。

难以想象“an I/O error occured while sending to the backend”这种网络IO的模糊告警跟底层存储是相关的。除了查看/var/log/message，pg层看不出来有什么。当然这个报错有可能不是这个原因，请勿曲解。

五、其他

未归类

物理读
#

postgres本身不直接暴露“真正的物理磁盘读”（Physical Disk Read）指标。pg_stat中的各种reads（比如pg_stat_database.blks_read ）都是从os cache中读。

那怎么监控物理读？

reads或者buffer allocation指标都是辅助策略，最好的办法还是监控OS。

os是postgres的生态，绝对不要单看数据库。数据库层监控不到物理读不值得PGer shame，有方案就没问题。

监控iostat以及各种五花八门的磁盘监控指标。对于云环境来说，os层的监控体系已经十分成熟了，不要浪费基于云的可观测性。

autovacuum
#

监控autovacuum process的SQL参考sql autovacuum_queue_and_progress

大库的autovacuum freeze
#

只要把参数、监控、告警配好，autovacuum freeze在绝大部分库中，都是不太需要关注的。

但是，在一些事务并发超高、数据特别大的库，仍然不可以忽略。因为autovacuum prevent wraparound可能随时都在跑，此时至少要关注如下两点：

年龄告警，及时处理并尽量避免下一次告警。不要出现快死到临头了才来着急挽救（加速方案需要看版本，比如INDEX_CLEANUP OFF,BUFFER_USAGE_LIMIT的调整）
对内存（特别是cache）的冲击。如果autovacuum跑个不停，库又特别大，对cache也有一定冲击，对内存是有影响的

原理和参数参考howstos这个图：

大表跑不动
#

大表指上百GB的表，一般有许多索引和死元组才会“跑不动”。

跑不动的主要原因是：(auto)vacuum会根据死元组，一条条的去索引上清理死索引元组。一般大表的(auto)vacuum就慢在这里，一般可以看到这个大表的死元组也比较多。更恐怖的是，这可能导致(auto)vacuum的运行速度慢于死元组生成速度，也就是(auto)vacuum永远跑不完，无限膨胀。

对于大表跑不完的场景经验：

同一表，死元组数基本与执行时间成正比
从autovacuum日志中的user time，elapsed time可以观察使用cpu时间和执行时间，即可大致推测delay sleep时间
关闭autovacuum cost-based delay，可以减少3倍执行时间（与索引大小相关，属于来源：200GB表，280GB索引）
调整某表的autovacuum cost-based delay含义是让autovacuum跑这个表更少的休息，会在更短的时间内消耗更多CPU以及扫描表时的io

如何加速？

repack。repack属于釜底抽薪型，可以快速重建表，在应急时可以使用。但repack毕竟是cli工具，每次去跑比较麻烦。
调整autovacuum的 cost-based delay参数。可1.调大cost limit alter table t1 SET (autovacuum_vacuum_cost_limit=1000); ,或者2.直接关闭delay睡眠时间alter table t1 SET (autovacuum_vacuum_cost_delay=0);。建议仅对autovacuum跑不过来的表调整。
删除不必要的索引。扫描索引并更新索引条目的时间是最久的，删除不必要的索引当然有效
分区表。推荐分区大小不大于10GB；改造为分区表是最好的方案
删除updated_time字段索引以利用HOT，以减少膨胀率

checkpoint和bgwriter
#

checkpointer不仅要打检查点，跟实例恢复的时间相关，它还会做刷脏。而bgwriter只是做刷脏。从pg 17开始一些指标转移到pg_stat_checkpointer ，这里以pg 17-为例，基本只看pg_stat_bgwriter

一、checkpoint间隔

指标checkpoints_timed：对应checkpoint_timeout参数
指标checkpoints_req：对应max_wal_size参数。

推荐以checkpoint_timeout为基本的checkpoint间隔，如果出现checkpoints_req，应该将max_wal_size调大，并配合调整刷脏参数。有FPI时也应该检查这两个指标表现。

二、刷脏指标

指标buffers_checkpoint：checkpointer刷脏数
指标buffers_clean：bgwriter刷脏数
指标buffers_backend：backend刷脏数，这应该尽量少的出现，出现说明bgwriter刷脏不够激进
指标buffers_backend_fsync：意义不明

刷脏调参目标以刷脏优先级为目标，刷脏优先级为：bgwriter刷脏 > checkpointer刷脏 > backend刷脏

checkpointer虽然可以顺手刷脏，但是checkpointer不好控制刷脏速度，即可能出现checkpointer会引起IO突刺的情况。所以bgwriter的刷脏优先级应高于checkpointer。backend刷脏自不必多说，这是backend触发的刷脏，应尽量减少这种情况。

三、bgwriter刷脏参数

bgwriter是通过“写多少停一下然后继续写的方式”来控制刷脏速度的。

参数bgwriter_delay：停多久
参数bgwriter_lru_maxpages：一次最多写多少
参数bgwriter_lru_multiplier：一次写多少=(近期buffer allocate* lru_multiplier)，但不大于lru_maxpages
参数bgwriter_flush_after：刷多少后做fsync
指标pg_buffers_alloc：可以代表共享内存buffer的分配量。（allocate是产生了实质的换入的，可以一定程度上代表内存换入pgpgin）。
指标maxwritten_clean：到达bgwriter_lru_maxpages的次数

默认的bgwriter刷脏逻辑：一次刷（新buffers数*2，但不大于100个dirty buffers），delay 200ms，每刷64个buffers后 fsync。

平时的一周期刷脏量跟近期的buffer allocation多少和bgwriter_lru_multiplier参数相关，而在高峰期时buffer allocation一般是比较高的，所以高峰期一般会触达bgwriter_lru_maxpages上限。所以可以这样理解：bgwriter_lru_maxpages用于限制高峰期刷脏上限；bgwriter_lru_multiplier用于控制低峰期不要频繁刷脏。

四、刷脏参数参考

默认最大bgwriter刷脏=100*5*8k=3.9M/s。默认bgwriter刷脏参数肯定是偏小的，如果需要调大的话应该结合shared_buffer的大小和负载来进行调整。

说了半天理论，实际可以参考如下调整：

#读写比2:8，负载较高
shared_buffers=40GB
checkpoint_timeout=20min;
max_wal_size=80GB
bgwriter_delay=20ms
bgwriter_lru_maxpages=1000
bgwriter_lru_multiplier=4

看情况再进行下一步调整。

至于效果，从实际的经验来看，不要期待单独调整bgwriter可以有好的效果。甚至bgwriter调整的过于激进可能会有反向效果。

所以，你的库没有明确定位到是checkpoint刷脏突刺或者其他刷脏的问题，那就不要动这个。仅推荐核心大库、并发高的库，在调整其他东西的时候（比如迁移时、调shared buffer时等）一并调整刷脏，当成附属调优策略。

五、刷脏参数总结

bgwriter刷脏可以总结为“三难”：

“难懂、难调、难有效果”

DB4AI
#

AI任务调度信息写入数据库
#

AI的应用已经在开发层面已经应用得非常广泛，其中一个场景是调用AI的任务会写进数据库，任务调用可能是瞬间极高的，而写入数据库的请求可能是没有并发控制的，所以会导致数据库的cpu或者其他资源使用率飙升。

这是一个AI时代背景下的一个新的数据库故障场景，careful。

vector hnsw
#

参考资料：https://postgresql.us/events/pgconfnyc2024/sessions/session/1862/slides/172/pgvector_best_practices_pgconfnyc2024.pdf

HNSW索引构建加速
#

HNSW索引在构建的时候可以非常慢，百万行数据可以慢到以小时计。

影响HNSW索引构建速度的，除了套餐的内存（和cpu）以外，还有索引构建参数，例如：

maintenance_work_mem=3g
max_parallel_maintenance_workers=2
m=12
ef_construction=100

创建HNSW可能非常折磨人，我们可以有以下手段加速创建索引：

在数据写入前建索引，其实是一个选择。虽然initial整体时间更慢，但是开发可接受慢一点，但接收不了建1个小时的索引
在数据写入后建索引优化
- SET maintenance_work_mem = '8GB'
- SET max_parallel_maintenance_workers = 8

after建索引需要注意内存问题，跟套餐内存，空闲内存强相关

注意maintenance_work_mem 是可以起到保护OS mem的作用，如果maintenance_work_mem超过了OS mem可分配内存，且表很大，则直接报错中断连接（快速报错）
```
ERROR: 53200: could not resize shared memory segment "/PostgreSQL.1390017142" to 6439348672 bytes: Cannot allocate memory
LOCATION: dsm_impl_posix, dsm_impl.c:314
```

注意创建过程中使用的内存超过maintenance_work_mem会有info提示（达到一定时间）

NOTICE: 00000: hnsw graph no longer fits into maintenance_work_mem after 886990 tuples
DETAIL: Building will take significantly more time.
HINT: Increase maintenance_work_mem to speed up builds.
LOCATION: InsertTuple, hnswbuild.c:525

HNSW索引查询速度
#

查询的召回率和性能之间需要做平衡，通过调整ef_search参数实现。

查询时除了ef_search参数影响较大外，还有一个影响查询返回速度的因素：HNSW索引是否缓存在内中。

索引不在内存中：

explain (analyze,buffers) SELECT image_id, applyNo, feature_vector <-> (select vectorsit
 FROM image_features_test2
 ORDER BY distance
 LIMIT 10;
 QUERY PLAN 
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit (cost=11852.80..11865.74 rows=10 width=35) (actual time=82193.073..82193.185 rows=10 loops=1)
 Buffers: shared hit=1796 read=9309
 I/O Timings: shared/local read=82108.559
 InitPlan 1 (returns $0)
 -> Limit (cost=0.00..0.02 rows=1 width=32) (actual time=0.008..0.009 rows=1 loops=1)
 Buffers: shared hit=1
 -> Seq Scan on test_0 (cost=0.00..23.60 rows=1360 width=32) (actual time=0.007..0.008 rows=1 loops=1)
 Buffers: shared hit=1
 -> Index Scan using idx_feature_hnsw on image_features_test2 (cost=11852.78..1292546.60 rows=989705 width=35) (actual time=82193.071..82193.179 rows=10 loops=1)
 Order By: (feature_vector <-> $0)
 Buffers: shared hit=1796 read=9309
 I/O Timings: shared/local read=82108.559
 Planning:
 Buffers: shared hit=1
 Planning Time: 0.130 ms
 Execution Time: 82193.279 ms

索引在内存中：

 QUERY PLAN 
----------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit (cost=11852.80..11865.74 rows=10 width=35) (actual time=20.240..20.350 rows=10 loops=1)
 Buffers: shared hit=11105
 InitPlan 1 (returns $0)
 -> Limit (cost=0.00..0.02 rows=1 width=32) (actual time=0.007..0.008 rows=1 loops=1)
 Buffers: shared hit=1
 -> Seq Scan on test_0 (cost=0.00..23.60 rows=1360 width=32) (actual time=0.007..0.007 rows=1 loops=1)
 Buffers: shared hit=1
 -> Index Scan using idx_feature_hnsw on image_features_test2 (cost=11852.78..1292546.60 rows=989705 width=35) (actual time=20.239..20.344 rows=10 loops=1)
 Order By: (feature_vector <-> $0)
 Buffers: shared hit=11105
 Planning:
 Buffers: shared hit=1
 Planning Time: 0.093 ms
 Execution Time: 20.392 ms

同一个索引，同一个执行计划，索引是否在内存中的性能差距是82193.279/20.392=4000倍！

这个差距是不可忽略的，关注HNSW索引性能时，一定要观测HNSW索引是否在内存中。SQL参考如下：

--buffercache查看hnsw是否在shared buffer中缓存
SELECT c.relname, pg_size_pretty(count(*) * 8192) as buffered, round(100.0 * count(*) / (SELECT setting FROM pg_settings WHERE name='shared_buffers')::integer, 1) AS buffer_percent, round(100.0 * count(*) * 8192 / pg_table_size(c.oid), 1) AS percent_of_relation FROM pg_class c INNER JOIN pg_buffercache b ON b.relfilenode = c.relfilenode INNER JOIN pg_database d ON (b.reldatabase = d.oid AND d.datname = current_database()) GROUP BY c.oid, c.relname ORDER BY 3 DESC LIMIT 10; 

 relname | buffered | buffer_percent | percent_of_relation 
---------------------------------+------------+----------------+---------------------
 idx_feature_hnsw_1 | 2117 MB | 91.9 | 44.5
 idx_feature_hnsw | 78 MB | 3.4 | 2.0
 pg_inherits_parent_index | 8192 bytes | 0.0 | 100.0

业务发版
#

ddl的技巧
#

online ddl工具pg-osc、pg_migrate都不支持分区表，而且工具还有一些其他问题，真实使用比较困难。所以DDL的技巧还算比较有用，可以降低锁级别、提前识别阻塞等以减少DDL阻塞和重写带来的风险。

理解这个图的关键点：

变更前的注意事项：

确保表上没有长事务——长事务会长期持有表上的锁，长事务在pg中是危害这是共识，应先处理长事务
确保表上没有autovacuum (to prevent wraparound)——autovacuum一般不会阻塞SQL，但做to prevent wraparound的除外

Autovacuum workers generally don’t block other commands. If a process attempts to acquire a lock that conflicts with the SHARE UPDATE EXCLUSIVE lock held by autovacuum, lock acquisition will interrupt the autovacuum. However, if the autovacuum is running to prevent transaction ID wraparound (i.e., the autovacuum query name in the pg_stat_activity view ends with (to prevent wraparound)), the autovacuum is not automatically interrupted.
lock_timeout=2000——即拿不到锁超过2s就不拿了，以免引发大面积阻塞

字段小改大的特例：

字段小改大一般不会重写表，但有几个例外。特别要注意int->bigint（常见主键字段）, char(n)->char(m)）
分区表索引。分区表字段小改大不会重写表，但会重建索引，而分区表重建索引一般都非常慢，很可能造成长期8级锁阻塞。这个特性是普通表没有的。

修改字段类型：

基本都会重写表，除了一些类型等价，或者属于另一种小改大的

DDL降低锁级别的注意点：

索引用CIC，分区不支持就子表CIC（记得attach index）
CIC执行分了好几个阶段。其中2、3阶段会获取share锁，阻塞dml（官方文档只说了SHARE UPDATE EXCL.（不等DML），CIC不是单纯的显式锁）
添加主键用using index，分区不支持就利用“子表加主键+父表添加主键可合并已存在的子表主键的特性”
约束用validate constraint
17以前不支持not null validate，可以用check(col1 IS NOT NULL)。这个check转not null也不会产生多余的扫描
加字段有default易失会重写，可以用非易失不重写特性先加字段，不会重写。存量数据看情况update
分区表attach时可以利用check约束减少停机时间，而添加check约束又可以用到validate constraint
create table like+attach比partition of的锁低很多（但我还是喜欢parition of）

变更后的注意事项：

记得收集统计信息（很多场景需要）

并发创建索引
#

在生产运维时，可能会碰到需要创建索引，但表又特别大，创建时间很长的情况。并发创建索引可以缩短建索引的时间。

普通表并发建索引：

并行参数：max_parallel_maintenance_workers

前提：

worker是够的，需要检查max_parallel_workers,max_worker_processes
调整maintenance_work_mem 上GB

注意事项：

对 B-tree or BRIN有效
maintenance_work_mem limit to entire utility command。跟parallel query不同，parallel query的资源限制是 per worker process

从测试结果来看，并发建索引在8个并发以后收益不明显（这个结论在不同环境可能不保真）。

分区表并发建索引：

推荐分区子表手搓并发，即一次在多个分区上创建，而不是使用原生并发，这可以减少多进程交互代价。

cached plan must not change resource
#

业务前晚新增字段后，早上业务连接报错：“cached plan must not change result type in PostgreSQL”

复现：

create table a(b varchar(10));
PREPARE p1 (varchar) AS SELECT * FROM a WHERE b=$1;
ALTER TABLE a ALTER COLUMN b TYPE varchar(20);
EXECUTE p1 ('abcd');

ERROR: 0A000: cached plan must not change result type
LOCATION: RevalidateCachedQuery, plancache.c:718

测试环境的解决办法： DEALLOCATE ALL主动丢弃prepared statement 或者， DISCARD ALL主动丢弃整个会话状态

DEALLOCATE ALL; --DISCARD ALL
PREPARE p1 (varchar) AS SELECT * FROM a WHERE b=$1;
EXECUTE p1 ('abcd');

生产环境的解决办法：

由于是业务层报错，JDBC可识别DEALLOCATE ALL,DISCARD ALL，但是业务可能没有做过。当下生产可执行如下方案：

解决办法（四选一）：

由于hikari等连接池的轮询启用连接和轮询timeout机制，可kill idle会话，报错会逐渐减少
同样是由于连接池的轮询启用连接和轮询timeout机制，可什么都不做，等连接池逐渐建立和启用新的连接
如果业务压力足够大，可考虑kill所有业务连接
轮询重启业务

不推荐：

DDL后重启应用。有效，但不要建议“所有DDL后都应该重启应用”这样的方案
autosave=conservative。有效，但会启用子事务。savepoint is set for each query, however the rollback is done only for rare cases like ‘cached statement cannot change return type’ or ‘statement XXX is not valid’ so JDBC driver rolls back and retries

jdbc配置建议：

配置jdbc事务回滚后自动重试：https://developer.aliyun.com/article/741750
其他jdbc配置参考：https://jdbc.postgresql.org/documentation/server-prepare/#corner-cases，注意有些建议是不能上生产的。

物理复制
#

查询冲突
#

查询冲突是一个非常坑的特性，它直接影响了PG从库的查询是不那么好用的。查询冲突会导致从库延迟增加，而从库的拉数SQL本身要跑一段时间是符合逻辑的，这就导致PG管理者不得不在延迟管理和长SQL管理中做出平衡。而这个特性在其他关系型数据库中是不存在的。

查询冲突要注意的隐蔽特性：

静态表同样会产生查询冲突（见-从静态表查询冲突到其原理），也就是说冲突是快照冲突，与查询的表本身的锁几乎没有关系，快照冲突是跨表的。
长查影响短查。长查把从库延迟推到max_standby_streaming_delay后，此时的短查也会被掐断。
不停的短查也会引起查询冲突。例如上个短查还没有结束，下一个短查又开始了，这两个短查逻辑可能是类似的，此时startup进程还没有来得应用日志。这在跑批中比较常见。这两个短查都持有那个需要应用的xid，可以检查pg_stat_activity.backend_xmin是否小于startup正在应用的xid

查询从库推荐的实践：

通过RTO SLO来调整max_standby_streaming_delay是一个不错的选择。当吵架到没有结果时，使用SLO来进行IT管理会救命。
短平快的业务查询与抽数、报表等长查询应该分到不同的从库，减少相互影响
从库查询SQL也是需要优化的
从库的日志应用延迟是需要监控的

逻辑复制
#

逻辑复制的坑可以说非常多了。24年有很多非常坑的案例，25年也遇到一些案例，但不算特别坑，而且主要是一些低版本pg上出现的，总体来看高版本的pg逻辑复制倾向稳定。

低版本PG+DDL/DCL语句解析较慢
#

案例-授权和walsender跑不动

PG13及之前的版本，对某些DDL、DCL语句解析较慢，可能会影响walsender延迟。这些DDL、DCL包括：

批量授权（含grant all tables）+ 安装了pathman extension（无论是否使用）
批量DDL/TRUNCATE/DCL/DROP PUBLICATION

低版本PG+多链路重复解析+flink
#

flink只能一个表一条链路，加上pg的walsender是重复解析的，一个pg库上几十条flink链路的walsender都是常见情况，而且改造困难。

而在pg11及以前，在walsender主循环中有PostmasterIsAlive()函数，导致主循环性能较差。从pg12开始WalSndLoop函数没有在主循环中频繁轮询PostmasterIsAlive()，而是将状态检查放到WalSndWait中，通过事件机制被动等待通知。这极大的缓解了CPU的争用。

如果库中有多个flink链路，而且pg版本较低，建议升级版本，可以缓解一定的walsender资源争用问题。这些可以缓解的资源问题包括：

可能会解决walsender启动时资源争用导致数据库长时间起不来的问题
可能会解决上游大量数据变动（含DDL重写）导致runtime walsender解析日志的cpu打满问题

低版本PG无法自动同步新分区
#

PG声明式分区在低版本需要注意仅能通过子表发布。pg版本>=13才支持按照父表配置发布，低于这个版本只能按分区子表的名称配置同步：

Allow partitioned tables to be logically replicated via publications (Amit Langote) § §

Previously, partitions had to be replicated individually. Now a partitioned table can be published explicitly, causing all its partitions to be published automatically. Addition/removal of a partition causes it to be likewise added to or removed from the publication. The CREATE PUBLICATION option publish_via_partition_root controls whether changes to partitions are published as their own changes or their parent’s.

也就是说，这个分区表如果是同步上游，每新增分区时，都要适配同步工具做发布，不然无法同步新分区数据。

迁移和升级
#

迁移信创和glibc升级
#

无论是信创迁移还是LINUX OS版本升级，都可能涉及glibc的升级，而glibc升级可能会非常坑。pg的排序在17以前都是完全依赖操作系统的。

pg没有办法检测glibc升级带来的兼容性问题。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)。

排序规则分了很多种，而很多环境用的是语义排序（例如en_US.utf8），语义排序也是最吃版本的。排序规则变化最常见的是引起查询索引时数据库奔溃，也还有其他不常见问题比如重复主键、分区表数据存入错误分区、merge join结果返回不一致等等。

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

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

但是，

builtin虽然是个好东西但是来得太迟了。大量已投入使用的数据库实例，想转builtin的字符集可不是一件容易的事。而且，信创迁移或者OS升级可能不会将数据库升级作为强制动作。

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

物理迁移后可以做什么？

一、官方必修方案

1.check索引，重建明显有问题的索引

2.REFRESH DATABASE COLLATION VERSION

3.检查依赖对象

4.REFRESH COLLATION VERSION

二、非官方邪修方案

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

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

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

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

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

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

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

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

4.未知问题

参考collation

丝滑大版本升级
#

https://gitlab.com/postgres-ai/postgresql-consulting/postgres-howtos/-/blob/main/0077_zero_downtime_major_upgrade.md?ref_type=heads

https://www.postgresql.eu/events/pgconfeu2023/sessions/session/4791/slides/439/2023.pgconf.eu%20Zero%20Downtime%20PostgreSQL%20Upgrades.pdf

一般的大版本升级方案：

pg_upgrade原地升级。不推荐，可能原地爆炸。
pgdump：适合小库，窗口期较长的库
逻辑同步+switchover（发布订阅/pg_logical/dts等）：适合小库，窗口期较短的库
物理正向同步+逻辑反向同步：适合大库，窗口期不太长的库
物理复制全量+逻辑同步增量+switchover：适合大库，窗口期极短的库

用逻辑同步同步全量数据可能是非常慢的，而用新从库原地升级本身带有不确定性，有一定的升级时间，而且也要解决反向逻辑同步的问题。“丝滑大版本升级”其实就是“物理复制全量+逻辑同步增量+switchover”。

丝滑大版本升级的主要技术：主库创建slot会返回LSN，新从库recovery_target_lsn 恢复到这个LSN，然后开启逻辑同步。

方案的大致流程：

预检查。多db（多db要考虑应用一个slot lsn）、插件、pathman、trigger、外键、unlogged表、crontab等等
物理同步。新老版本软件、对比和备份conf文件、pg_basebackup搭建低版本新库
逻辑同步准备一。主键和复制标识、创建发布；禁止业务发布DDL/DCL
新库恢复到target LSN。停新库；老库创建slot并记录LSN；新库以target LSN启动
新库大版本升级。升级、处理各种问题、环境变量切换
逻辑同步准备二。禁用trigger、外键、任务、插件等
逻辑同步。创建指定slot的copy_data=false订阅
逻辑同步后。索引损坏检查、检查日志报错并修复、重建同城远程
switchover。停业务；提升序列、启用外键、trigger、任务等
switchover。搭建反向链路（老库订阅）
switchover。业务切换

丝滑大版本升级的方案对于业务很丝滑，对于DBA很复杂。这个方案包含了逻辑迁移和物理迁移的所有缺点，做起来是比较痛苦的，以上步骤已经简化过了。该方案消耗DBA人力，对于非常重要的库可以考虑这个方案。

分区表的管理
#

Postgres分区表非常灵活，没有自增interval分区功能，而且版本多变，导致分区表运维管理问题几乎是年年发生。我相信有不少PG DBA对于新分区的各种问题还提心吊胆的。

我自己观察下来分区表的管理和使用主要有如下问题：

未使用声明式分区表。老版本仍然使用pathman分区或继承表分区，或者即便升级后仍然使用pathman分区或继承表分区。PG10开始支持声明式分区，由于早期版本有功能不足，建议至少PG12以后就仅使用声明式分区表，以减少环境的复杂性。
开发自建子表索引/主键。不通过父表默认继承而是通过SQL直接在子表建索引/主键，会导致下一次开发写SQL时可能就忘记了。这不仅会导致父子不一致，也会导致子子不一致，最终导致分区表结构面目全非。
新分区无管理策略。忘记建新分区或者用default分区。一般开发会建个几年的分区，下一次可能开发都换了一批了，没人会去管这个新分区建设。这会定时炸弹随时爆炸，或者数据写入default分区失去分区意义。
缺乏DBA的管理。是的，DBA！PG的分区表知识实在是多（参考PostgreSQL分区表），怎么基于自己的环境做管理策略和落地，需要专业DBA的主动推动。这可能是最重要的。

自己思考的分区表管理目标（copy的这个案例-20260101分区数据更新失败）：

以主表结构为标准结构，即主表面向开发，它上面应该有主键、索引、复制标识（pg版本不支持除外）
主表与子表保持一致，使用partition of创建新分区（是的，我不推荐attach）
子表与子表保持一致
提前创建新分区，分区数据量不宜过多
default分区不建议创建，如果创建必须监控其写入情况
频繁访问的表的SQL必须包含分区键，使用分区裁剪，不然改造为普通表

可观测性
#

从官方文档中基本都能看到数据库、表、索引、SQL、刷脏等等指标释义，还是比较清楚的。

其中有几个指标可能要特别注意一下，不仅解释的不是很清楚，而且常用且有理解成本。

buffers_alloc、blks_read
#

pg_stat_bgwriter.buffers_alloc： Number of buffers allocated，共享内存置换量
pg_stat_database.blks_read ：os cache读

（buffers_alloc在不同PG版本可能在不同视图中，但含义不变）

pg_stat_bgwriter.buffers_alloc是共享内存的buffer分配量，源码中叫buffer allocation。可以代表共享内存的置换量，新起的库一般这个值比较高。观察共享内存繁忙程度时，buffer allocate可能要比命中率好，命中率高可能就是小表频繁访问拉高了，allocate是产生了实质的置换的。

buffers_alloc是从cache读数后加载到新的共享内存buffer，其实也能一定程度代表os cache read吧？但是实际观察下来，buffers_alloc与blks_read含义如此相似但数值可能差异较大。为什么？没搞懂，待研究。

源码：numBufferAllocs

tup_fetched、tup_returned
#

这俩是pg_stat_database 中的指标：

tup_fetched ：索引扫描最终获取的行数，去掉了过滤条件、死亡元组、不可见行后的行。偏向于结果。
tup_returned ：索引扫描回表的行数，不管是否满足过滤条件、死亡元组、不可见行后的行。偏向于处理过程

所以，tup_returned 一般比tup_fetched 高不少。而异常高，也代表可能有优化空间，因为毕竟访问了这么多数据，实际上没有返回给客户端多少。

idx_tup_fetch 、idx_tup_read
#

这俩是pg_stat_all_indexes 中的指标：

idx_tup_read ：从索引计数的访问索引条目数，包含bitmap scan
idx_tup_fetch ：从表计数的索引扫描最终返回的行数，不包含bitmap scan

疯了

可以记住一个点：xx_tup_fetch是指经过索引回表访问后返回的最终行数，偏向于结果。

参考内容
#

postgres-ai howtos

Best practices for using pgvector

案例-20260101分区数据更新失败

PostgreSQL分区表

案例-从distinct不准确到DISTINCT的计算原理

案例-添加索引性能下降和generic plan

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

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

https://liuzhilong.blog.csdn.net/article/details/130783036

https://techcommunity.microsoft.com/blog/adforpostgresql/improving-postgres-connection-scalability-snapshots/1806462

https://www.postgresql.org/docs/17/sql-prepare.html

https://www.postgresql.org/docs/17/sql-deallocate.html

https://www.postgresql.org/docs/release/13.0/

https://jdbc.postgresql.org/documentation/use/

https://jdbc.postgresql.org/documentation/server-prepare/#server-prepared-statements

https://www.postgresql.eu/events/pgconfeu2023/sessions/session/4791/slides/439/2023.pgconf.eu%20Zero%20Downtime%20PostgreSQL%20Upgrades.pdf

感谢25年跟高大师的battle

案例-20260101分区数据更新失败

Sun, 04 Jan 2026 00:00:00 +0000

现象
#

12月30日发现业务报错，数据无法更新：

ERROR: 55000: cannot update table "tablzl_202601" because it does not have a replica identity and publishes updates
HINT: To enable updating the table, set REPLICA IDENTITY using ALTER TABLE.
LOCATION: CheckCmdReplicaIdentity, execReplication.c:575

临时恢复
#

因为报错信息充足，没有复制标识，表是一个分区表，又是26年的分区，所以直接怀疑新分区没有主键（新表的复制标识是default，default只能用主键作为复制标识，没有主键就会无法更新）。

然后发现，父表没有任何主键和索引，25年以前的老子分区有主键和索引，26年以后的新子分区没有任何主键和索引，且所有子分区有发布。大概如下：

p_parent --无主键无索引
p_child_202511 --有主键有索引，有发布
p_child_202512 --有主键有索引，有发布
p_child_202601 --无主键无索引，有发布
p_child_202602 --无主键无索引，有发布

因为父表什么都没有，所以partition of添加子分区也会什么都没有，只有自己准备子分区的主键和索引，所以推测新分区创建的有问题，老分区新建时应该是处理过的。

另外，通过父表发布分区表是PG13才开始支持，以前不能通过父表发布，只能通过子表发布，该库版本是PG11。

Allow partitioned tables to be logically replicated via publications (Amit Langote) § §

Previously, partitions had to be replicated individually. Now a partitioned table can be published explicitly, causing all its partitions to be published automatically. Addition/removal of a partition causes it to be likewise added to or removed from the publication. The CREATE PUBLICATION option publish_via_partition_root controls whether changes to partitions are published as their own changes or their parent’s.

初步知道问题后，因为情况紧急，可以通过3个办法来临时解决：

26年新分区添加主键
26年新分区设置replica identity full
26年新分区取消发布表

因为恢复时间都差不多，所以从减少运维成本的角度，通过添加主键恢复，至少先让业务不报错。

根因分析
#

问题看似清晰，就是“没有复制标识+发布过+没有主键”导致不能更新，但是还有一些问题需要解答。

疑问一：为什么update没有更新202601的数据（新分区根本没有数据），仍然报错
#

拿到SQL文本如下：

UPDATE tablzl_202601
 SET idid = $1,...
 date_updated = now()
 WHERE mykey = $4

tablzl_202601表的分区键是created_date，SQL条件就没有分区键，所以去更新202601分区发现连个主键都没有所以就报错了。

至于检查是否有行和检查复制标识谁先，从ExecSimpleRelationUpdate可以看到逻辑，这个函数在不同的PG版本中变化极小：

/*
 * Find the searchslot tuple and update it with data in the slot,
 * update the indexes, and execute any constraints and per-row triggers.
 *
 * Caller is responsible for opening the indexes.
 */
void
ExecSimpleRelationUpdate(EState *estate, EPQState *epqstate,
						 TupleTableSlot *searchslot, TupleTableSlot *slot)
{
...
	CheckCmdReplicaIdentity(rel, CMD_UPDATE); //检查复制标识

	/* BEFORE ROW UPDATE Triggers */ //before ROW UPDATE trigger
	if (resultRelInfo->ri_TrigDesc &&
		resultRelInfo->ri_TrigDesc->trig_update_before_row)
	{
		slot = ExecBRUpdateTriggers(estate, epqstate, resultRelInfo,
									&searchslot->tts_tuple->t_self,
									NULL, slot);

		if (slot == NULL)		/* "do nothing" */
			skip_tuple = true;
	}

	if (!skip_tuple)
	{
		List	 *recheckIndexes = NIL;

		/* Check the constraints of the tuple */ //检查约束
		if (rel->rd_att->constr)
			ExecConstraints(resultRelInfo, slot, estate);
		if (resultRelInfo->ri_PartitionCheck)
			ExecPartitionCheck(resultRelInfo, slot, estate, true);

		/* Materialize slot into a tuple that we can scribble upon. */
		tuple = ExecMaterializeSlot(slot);

		/* OK, update the tuple and index entries for it */ //更新行
		simple_heap_update(rel, &searchslot->tts_tuple->t_self,
						 slot->tts_tuple);

		if (resultRelInfo->ri_NumIndices > 0 && //插入索引条目
			!HeapTupleIsHeapOnly(slot->tts_tuple))
			recheckIndexes = ExecInsertIndexTuples(slot, &(tuple->t_self),
												 estate, false, NULL,
												 NIL);

		/* AFTER ROW UPDATE Triggers */ //after ROW UPDATE trigger
		ExecARUpdateTriggers(estate, resultRelInfo,
							 &searchslot->tts_tuple->t_self,
							 NULL, tuple, recheckIndexes, NULL);

		list_free(recheckIndexes);
	}
}

ExecSimpleRelationUpdate大致过程：

检查复制标识
before ROW UPDATE trigger
检查约束（包括非分区约束和分区约束）
更新行
插入索引条目
after ROW UPDATE trigger

所以pg逻辑就是先检查复制标识，然后才是更新行等等操作。

虽然SQL条件没有分区键，但是加上分区键就会裁剪吗？答案是可能不会。

分区裁剪的版本提升：

pg10刚支持声明式分区，没有enable_partition_pruning参数，可以通过constraint_exclusion在planning阶段裁剪。所以pg10没有query process pruning
pg11支持query process pruning，Allow partition elimination during query execution (David Rowley, Beena Emerson)。但只支持绑定变量裁剪，不支持非immutable函数裁剪（包括now()）
pg14支持最终裁剪，This wins in UPDATEs on partitioned tables when only some of the partitions will actually receive updates。即支持非immutable函数裁剪

因为pg11不支持now()裁剪，如果业务SQL加now()条件不会触发裁剪，仍然会报错。但是如果业务通过绑定变量传入，是会触发裁剪的，也就不会报错。注意，这个报错指的是更新202512的数据不会在202601分区上报错，更新202601的数据该报错还是报错。

疑问二：表是20251226创建的,为什么是10月30日发现有问题
#

这个就更简单了，“没有复制标识+发布过+没有主键”是且的关系。

虽然新分区建的比较早，但发布表的时间是12月29日晚20:47

cat postgresql-12-29.csv.bak |grep "alter publication"
2025-12-29 20:48:07.730 CST,"userlzlreplication","lzldb",xxx"statement: alter publication publzl add table ""public"".""tablzl_202601"", ""public"".""tablzl_202602"",...,,,,,,,,,""

首次报错时间是12月29日晚22:26，也就是1个半小时左右以后：

 cat postgresql-12-29.csv.bak |grep "REPLICA IDENTITY"
2025-12-29 22:26:01.404 CST,"userlzlreplication","lzldb",375121,xxx,"cannot update table ""tablzl_202601"" because it does not have a replica identity and publishes updates",,"To enable updating the table, set REPLICA IDENTITY using ALTER TABLE.",,,,"UPDATE tablzl

总结
#

原因概述：如果父表没有主键，新分区partition of创建时当然也不会有主键，老的子分区通过子分区主键实现，新的子分区没有去主动创建主键，导致202601主键缺失。链路同步需要依赖主键（default）作复制标识，没有复制标识会导致无法同步给下游，也会导致发布以后update/delete语句无法正常执行。在PG 11中，update SQL本身即使包含分区键条件，也可能会去访问新分区。

运气成分：因为各种原因，这个库提前发现了这个问题。在31号我们有1天的buffer来补救所有数据库实例，至少保证1号新分区数据update别报错，不然大概率2026年1月1日多个系统将原地爆炸。

临时措施（三选一）：

26年新分区添加主键
26年新分区设置replica identity full
26年新分区取消发布表

对于复制链路的优化：

应该提前发现没有主键的表，不然直接发布的话，可能会导致业务侧更新失败

对于分区管理的策略：

PG的分区表非常灵活，而且一般开发弄不懂怎么去正确创建分区，再加上分区表在大概PG10-15之间有较多的重要新特性，加上PG分区表没有interval分区功能，分区表可能弄的乱七八糟，所以规范管理分区表显得尤为重要。分区表的特性和运维技巧见：PostgreSQL分区表

针对管理手段就不说了，

针对管理目标：

以主表结构为标准结构，即主表面向开发，它上面应该有主键、索引、复制标识（pg版本不支持除外）
主表与子表保持一致，使用partition of创建新分区（是的，我不推荐attach）
子表与子表保持一致
提前创建新分区，分区数据量不宜过多
default分区不建议创建，如果创建必须监控其写入情况
频繁访问的表的SQL必须包含分区键，使用分区裁剪，不然改造为普通表

ref
#

https://www.postgresql.org/docs/release/10.0/

https://www.postgresql.org/docs/release/11.0/

https://www.postgresql.org/docs/release/12.0/

https://www.postgresql.org/docs/release/13.0/

https://www.postgresql.org/docs/release/14.0/

src/backend/executor/execReplication.c

PostgreSQL分区表

案例-行锁与LWlock-lockmanger

Sun, 21 Dec 2025 00:00:00 +0000

现象
#

数据库有大量行锁和少部分LWlock lockmanger，cpu打满，活动会话飙升。锁对应的block pid在变化，未见明显长事务阻塞。 (脑补cpu和活动会话高）

大量的锁对于的sql如下：

UPDATE lzl_record SET rc_lzl1= rc_lzl1 + $1, pc_lzl2 = pc_lzl2 + $2, rc_lzl3 = rc_lzl3 + $3 where lzl_id = $4

分析
#

SQL未见并发上涨
#

从hit和cpu的关联性看，可以从sql的hit分析。其中那个UPDATE sql占比80%左右，该sql的执行次数没有变化，但blks hit明显异常。

同时分析元数据访问，快照内均元数据表没有访问特别高的。

从现象分析看不出来SQL并发上涨，也看不出来元数据异常。SQL hit上涨暂时看不出来为什么。

LWlock lockmanager分析
#

因为SQL本身简单，lzl_record表的lzl_id字段是唯一字段，也就是通过唯一键进行更新。

现场的等待事件除了大量的显示锁以外，还有LWlock lockmanager。

但表是普通表不是分区表，且表上只有4、5个索引。

LWlock lockmanger跟没有用到fast path有关系，而简单的查询、DML可以用到fastpath

Weak relation locks. SELECT, INSERT, UPDATE, and DELETE must acquire a lock on every relation they operate on, as well as various system catalogs that can be used internally. Many DML operations can proceed in parallel against the same table at the same time; only DDL operations such as CLUSTER, ALTER TABLE, or DROP – or explicit user action such as LOCK TABLE – will create lock conflicts with the “weak” locks (AccessShareLock, RowShareLock, RowExclusiveLock) acquired by DML operations.

所以，一个不超过访问16个relation（含索引）的SELECT/DML是可以用到fastpath的，就不应该有很多LWlock lockmanager。

但是，DML肯定不能简单的用fastpath，fastpath是完全本地化处理锁，DML肯定需要校验其他会话是否持有行，需要访问共享内存。再加上SQL通过唯一字段更新还能有行锁，说明肯定更新的是同一行。

从日志上可以看到更新同一行的情况，其中一行有锁等待的更新有上万次。

压测
#

压测同一行更新产生LWLock LockManager
#

出于行锁肯定不能仅fastpath的考虑，以及LWLock LockManager会降低数据库性能的经验，压测不同场景性能情况。

#prompt
给我一个pgbench压测脚本
表结构：主键,唯一字段+唯一索引，其他字段
更新：通过唯一字段更新

压测重复更新同一行数据，也就是重复行锁更新
压测随机更新某一行数据，也就是无行锁更新

脚本略，套餐20c96g

pgbench命令如下

pgbench -h localhost -p $PGPORT -d lzldb -U dbmgr -f update_same_unique_key.sql -c 200 -j 32 -T 600 -r -S
pgbench -h localhost -p $PGPORT -d lzldb -U dbmgr -f update_random_unique_key.sql -c 200 -j 32 -T 600 -r -S

压测时的等待事件：

 --更新同一行，常见2次等待
 usename | state | wait_event | wait_event_type | cnt 
----------+--------+---------------------+-----------------+-----
 dbmgr | active | LockManager | LWLock | 105
 dbmgr | active | transactionid | Lock | 61
 dbmgr | active | tuple | Lock | 25
 dbmgr | active | [null] | [null] | 8
 dbmgr | active | WALSync | IO | 1
 
 usename | state | wait_event | wait_event_type | cnt 
----------+--------+---------------------+-----------------+-----
 dbmgr | active | transactionid | Lock | 180
 dbmgr | active | LockManager | LWLock | 18
 dbmgr | active | tuple | Lock | 1
 dbmgr | active | WALSync | IO | 1

--更新不同行，常见2次等待
usename | state | wait_event | wait_event_type | cnt 
----------+---------------------+---------------------+-----------------+-----
 dbmgr | active | [null] | [null] | 106
 dbmgr | idle | ClientRead | Client | 34
 dbmgr | idle in transaction | ClientRead | Client | 25
 dbmgr | active | WALWrite | LWLock | 21
 dbmgr | active | BufferMapping | LWLock | 7
 dbmgr | idle in transaction | [null] | [null] | 4
 dbmgr | idle in transaction | WALWrite | LWLock | 2
 
 usename | state | wait_event | wait_event_type | cnt 
----------+---------------------+---------------------+-----------------+-----
 dbmgr | active | [null] | [null] | 117
 dbmgr | idle | ClientRead | Client | 42
 dbmgr | idle in transaction | ClientRead | Client | 24
 dbmgr | active | WALWrite | LWLock | 12
 dbmgr | active | XactGroupUpdate | IPC | 1
 dbmgr | active | WALSync | IO | 1
 dbmgr | active | XactSLRU | LWLock | 1
 dbmgr | active | BufferContent | LWLock | 1
 dbmgr | active | ClientRead | Client | 1

从等待事件上可以看出差异，更新同一行会出现LWLock LockManager甚至占比较高的情况，不同行基本都是等cpu。场景1与生产情况类似。

行锁与fastpath浅析
#

lmgr readme对fastpath的解释：

Fast Path Locking
-----------------

Fast path locking is a special purpose mechanism designed to reduce the
overhead of taking and releasing certain types of locks which are taken
and released very frequently but rarely conflict. Currently, this includes
two categories of locks:

(1) Weak relation locks. SELECT, INSERT, UPDATE, and DELETE must acquire a
lock on every relation they operate on, as well as various system catalogs
that can be used internally. Many DML operations can proceed in parallel
against the same table at the same time; only DDL operations such as
CLUSTER, ALTER TABLE, or DROP -- or explicit user action such as LOCK TABLE
-- will create lock conflicts with the "weak" locks (AccessShareLock,
RowShareLock, RowExclusiveLock) acquired by DML operations.

能使用fastpath的锁的条件lmgr/lock.c：

/*
 * The fast-path lock mechanism is concerned only with relation locks on
 * unshared relations by backends bound to a database. The fast-path
 * mechanism exists mostly to accelerate acquisition and release of locks
 * that rarely conflict. Because ShareUpdateExclusiveLock is
 * self-conflicting, it can't use the fast-path mechanism; but it also does
 * not conflict with any of the locks that do, so we can ignore it completely.
 */
#define EligibleForRelationFastPath(locktag, mode) \
	((locktag)->locktag_lockmethodid == DEFAULT_LOCKMETHOD && \
	(locktag)->locktag_type == LOCKTAG_RELATION && \
	(locktag)->locktag_field1 == MyDatabaseId && \
	MyDatabaseId != InvalidOid && \
	(mode) < ShareUpdateExclusiveLock)

SELECT/DML是可以使用fastpath的，但是仅限于locktype=relation。

实际查看行锁时的锁情况：

--窗口1
begin;
update lzl1 set b='zzz' where a=1;

--窗口2
begin;
update lzl1 set b='zzz' where a=1;
--waiting


--窗口3
 select * from pg_locks where pid<>(select pg_backend_pid()) order by pid,locktype;
 locktype | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid | mode | granted | fastpath 
---------------+----------+----------+--------+--------+------------+---------------+---------+--------+----------+--------------------+--------+------------------+---------+----------
 relation | 4267681 | 5290151 | [null] | [null] | [null] | [null] | [null] | [null] | [null] | 5/4791 | 220559 | RowExclusiveLock | t | t
 transactionid | [null] | [null] | [null] | [null] | [null] | 170706189 | [null] | [null] | [null] | 5/4791 | 220559 | ExclusiveLock | t | f
 transactionid | [null] | [null] | [null] | [null] | [null] | 170706190 | [null] | [null] | [null] | 5/4791 | 220559 | ExclusiveLock | t | f
 transactionid | [null] | [null] | [null] | [null] | [null] | 170706187 | [null] | [null] | [null] | 5/4791 | 220559 | ShareLock | f | f
 tuple | 4267681 | 5290151 | 0 | 1 | [null] | [null] | [null] | [null] | [null] | 5/4791 | 220559 | ExclusiveLock | t | f
 virtualxid | [null] | [null] | [null] | [null] | 5/4791 | [null] | [null] | [null] | [null] | 5/4791 | 220559 | ExclusiveLock | t | t
 relation | 4267681 | 5290151 | [null] | [null] | [null] | [null] | [null] | [null] | [null] | 7/562 | 253641 | RowExclusiveLock | t | t
 transactionid | [null] | [null] | [null] | [null] | [null] | 170706187 | [null] | [null] | [null] | 7/562 | 253641 | ExclusiveLock | t | f
 virtualxid | [null] | [null] | [null] | [null] | 7/562 | [null] | [null] | [null] | [null] | 7/562 | 253641 | ExclusiveLock | t | t

pg的行锁实现比较复杂，不仅有tuple锁，还需要transactionid和relation锁。其中只有locktype=relation、virtualxid能用到fastpath，其他都用不到。

对比没有行锁：

--窗口1
begin;
update lzl1 set b='zzz' where a=1;

--窗口2
begin;
update lzl1 set b='zzz' where a=2;
--waiting

select * from pg_locks where pid<>(select pg_backend_pid()) order by pid,locktype;
 locktype | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid | mode | granted | fastpath 
---------------+----------+----------+--------+--------+------------+---------------+---------+--------+----------+--------------------+--------+------------------+---------+----------
 relation | 4267681 | 5290151 | [null] | [null] | [null] | [null] | [null] | [null] | [null] | 5/4792 | 220559 | RowExclusiveLock | t | t
 relation | 4267681 | 5290151 | [null] | [null] | [null] | [null] | [null] | [null] | [null] | 5/4792 | 220559 | AccessShareLock | t | t
 transactionid | [null] | [null] | [null] | [null] | [null] | 170706214 | [null] | [null] | [null] | 5/4792 | 220559 | ExclusiveLock | t | f
 virtualxid | [null] | [null] | [null] | [null] | 5/4792 | [null] | [null] | [null] | [null] | 5/4792 | 220559 | ExclusiveLock | t | t
 relation | 4267681 | 5290151 | [null] | [null] | [null] | [null] | [null] | [null] | [null] | 7/563 | 253641 | AccessShareLock | t | t
 relation | 4267681 | 5290151 | [null] | [null] | [null] | [null] | [null] | [null] | [null] | 7/563 | 253641 | RowExclusiveLock | t | t
 transactionid | [null] | [null] | [null] | [null] | [null] | 170706212 | [null] | [null] | [null] | 7/563 | 253641 | ExclusiveLock | t | f
 virtualxid | [null] | [null] | [null] | [null] | 7/563 | [null] | [null] | [null] | [null] | 7/563 | 253641 | ExclusiveLock | t | t

fastpath=f的也就少了2、3个。2个会话持有的transactionid锁是肯定用不到fastpath了。

总结使用fastpath锁机制的场景（且）：

锁等级<=3，即SELECT/DML语句
locktype=relation。pg的行锁还至少需要transactionid和tuple锁，所以这俩用不到fastpath
relation数少于16个（一般分区表全分区访问就超了）

总结
#

1.行锁是因是果，是行锁的问题还是数据库性能下降SQL跑的慢了出现行锁？

行锁是因。sql执行次数没有变化，但是sql的传参从离散变成集中，即更新同一行的情况明显增加。从压测数据来看更新同一行会出现行锁和LWLock LockManager的等待。

2.sql执行次数没有上涨，SQL性能是否下降？

SQL性能其实是下降了，但是索引肯定没有走错，只是因为反复更新了同一行。

解决方案：

从业务层了解SQL是某接口开关调用后讲调用次数更新到表里。如果是同一接口反复调用，是可能出现反复更新同一行的情况的。所以，减少同一接口反复调用或者更大批次的更新数据库，预计可以减缓这个问题。

案例-从distinct不准确到DISTINCT的计算原理

Sun, 19 Oct 2025 00:00:00 +0000

问题现象
#

统计信息的n_distinct不准确

这个问题在多个库中出现，例如：

表有2亿行数据，真实DISTINCT有800w，统计信息中的DISTINCT只有4w。

问题分析
#

采样模型
#

默认default_statistics_target=100，即采集30000 pages中的30000行数据。

analyze verbose tablzl1;
INFO: 00000: analyzing "public.tablzl1"
LOCATION: do_analyze_rel, analyze.c:332
INFO: 00000: "tablzl1": scanned 30000 of 22963751 pages, containing 1061942 live rows and 3953 dead rows; 30000 rows in sample, 812872389 estimated total rows
LOCATION: acquire_sample_rows, analyze.c:1340

注意 “scanned 30000” 和 “30000 rows in sample”

distinct预估算法
#

distinct的预估算法analyze.c:

			/*----------
			 * Estimate the number of distinct values using the estimator
			 * proposed by Haas and Stokes in IBM Research Report RJ 10025:
			 *		n*d / (n - f1 + f1*n/N)
			 * where f1 is the number of distinct values that occurred
			 * exactly once in our sample of n rows (from a total of N),
			 * and d is the total number of distinct values in the sample.
			 * This is their Duj1 estimator; the other estimators they
			 * recommend are considerably more complex, and are numerically
			 * very unstable when n is much smaller than N.
			 *
			 * In this calculation, we consider only non-nulls. We used to
			 * include rows with null values in the n and N counts, but that
			 * leads to inaccurate answers in columns with many nulls, and
			 * it's intuitively bogus anyway considering the desired result is
			 * the number of distinct non-null values.
			 *
			 * We assume (not very reliably!) that all the multiply-occurring
			 * values are reflected in the final track[] list, and the other
			 * nonnull values all appeared but once. (XXX this usually
			 * results in a drastic overestimate of ndistinct. Can we do
			 * any better?)
			 *----------
			 */
			int			f1 = nonnull_cnt - summultiple;
			int			d = f1 + nmultiple;
			double		n = samplerows - null_cnt;
			double		N = totalrows * (1.0 - stats->stanullfrac);
			double		stadistinct;

n*d / (n - f1 + f1*n/N)

n = 样本行数（扫描的行数）
d = 样本中发现的distinct值的数量
f1 = 样本中只出现一次值的数量
N = 表的总行数

算法论文：https://hugepdf.com/download/download-extended-version-of-this-paper_pdf

论文看起来比较费劲，下面做一些假设来理解这个disticnt算法：

1.假设全是出现一次值，且表很大n«N，即f1=d，n/N=0

d*d / (d - d + d*0)=d*2/0，这应该是-1了.

2.假设全是出现一次值，且表很小n=N，即f1=d，n/N=1

n*d / (n - d + d*1)=d，即采集的distinct数，也等于采集的行数

3.假设采集样本中没有只出现一次值，即f1=0，

n*d / (n - f1 + f1*n/N)=n*d / (n)=n*d / (n)=d ，也就是采样中的distinct数.

如果一个列均是插入几条同样的值，然后再插入几条同样的值，比如：

11,2,2,2,2,3,3,3,..

3.1且表小，3w行采集全部采完，真实distinct=10000（假设），预估distinct=d=10000

3.2且表大，采样中有重复出现的值，也有出现一次值（因为某个重复数据只采到一条），即n=30000,n/N=0，

n*d / (n - f1 + f1*n/N)=n*d / (n - f1)=30000*d/(30000-f1)，也就是采样中的distinct数越大，预估的distinct越大；采样只出现一次值数越大，预估的distinct越大

总结：

distinct预估跟采样中的distinct数、只出现一次值数直接相关
如果只出现一次值数=0，那么采样越多，预估的distinct越大

验证
#

由于默认采样数最大是3w行，也就是说这种采样算法只要超过3w，即表比较大的时候，预估distinct很可能偏小。注意这里的数据不能有太多唯一值。

测试一张表不同采样数的差异：

表有reltuples=8亿，relpages=2kw，size=175GB，真实的某字段distinct 1亿

target statistics	pages采样比例（1）	tuples采样比例（1）	n_distinct	执行时间
50	0.00075	0.00001875	6w	2秒
100	0.0015	0.0000375	11w	5秒
1000	0.015	0.000375	103w	58秒
3000	0.045	0.001125	268w	3分01秒
10000	0.15	0.00375	675w	7分21秒

（target statistics 最大值10000）

可以粗糙的总结：n_distinct和analyze的执行时间随采样数量成倍增长。

n_distinct随采样数量增长，pages和tuples却一直都很准确。

解决
#

由于表特别大，可以考虑改造分区表或根据实际SQL进行优化

还可以调整收集阈值，默认阈值default_statistics_target=100，即3w个pages中的3w条数据。

临时方案：

set default_statistics_target=3000;
analyze tab1;

长期方案：

alter table tab1 alter column col1 set STATISTICS 3000;

注意：

列的收集阈值优先级最高，大于default_statistics_target参数
收集阈值最大为10000
表的收集阈值为最大的列阈值：

	/*
	 * Determine how many rows we need to sample, using the worst case from
	 * all analyzable columns. We use a lower bound of 100 rows to avoid
	 * possible overflow in Vitter's algorithm. (Note: that will also be the
	 * target in the corner case where there are no analyzable columns.)
	 */
	targrows = 100;
	for (i = 0; i < attr_cnt; i++)
	{
		if (targrows < vacattrstats[i]->minrows)
			targrows = vacattrstats[i]->minrows;
	}
	for (ind = 0; ind < nindexes; ind++)
	{
		AnlIndexData *thisdata = &indexdata[ind];

		for (i = 0; i < thisdata->attr_cnt; i++)
		{
			if (targrows < thisdata->vacattrstats[i]->minrows)
				targrows = thisdata->vacattrstats[i]->minrows;
		}
	}

如果执行analyze发现收集多了或者少了，可以看下pg_statistic是不是有设置字段stattarget

select attrelid::regclass,attname,attstattarget from pg_attribute where attrelid = 'tab1'::regclass and attstattarget not in (-1,0);

总结
#

对于大表，字段非唯一但distinct值比较高（符合真实场景），采样算法会低估distinct值，且跟采样比例正相关。默认的采样比例对于大表来说偏小，可以调大，但是最大也大不到哪去。

案例-添加索引性能下降和generic plan

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

问题现象
#

前晚添加索引，第二天早上cpu打爆，sql容易定位，问题sql就1条。该sql跑了30多s，但是昨天跑3s左右，所以要看下前后执行计划变化。

执行计划只贴关键部分。

加索引前的执行计划：

 -> Nested Loop (cost=19.92..2259694.20 rows=265822 width=33)
 -> Index Scan using uk_lzl_task on lzl_task t (cost=0.29..20007.99 rows=195 width=24)
 Filter: ((created_by)::text = 'LIUZHILONG62'::text)
 -> Append (cost=19.63..11337.15 rows=14842 width=57)
 -> Bitmap Heap Scan on lzl_202501 cc_1 (cost=19.63..3053.69 rows=1467 width=66)
 Recheck Cond: ((task_no)::text = (t.task_no)::text)
 Filter: ((created_date > '2025-01-07 09:00:00'::timestamp without time zone) AND (created_date < '2025-09-03 12:56:44.973'::timestamp without time zone))
 -> Bitmap Index Scan on lzl_202501_task_no_idx (cost=0.00..19.27 rows=1594 width=0)
 Index Cond: ((task_no)::text = (t.task_no)::text)
 -> Bitmap Heap Scan on lzl_202502 cc_2 (cost=21.67..3066.85 rows=1604 width=66)
 Recheck Cond: ((task_no)::text = (t.task_no)::text)
 Filter: ((created_date > '2025-01-07 09:00:00'::timestamp without time zone) AND (created_date < '2025-09-03 12:56:44.973'::timestamp without time zone))
 -> Bitmap Index Scan on lzl_202502_task_no_idx (cost=0.00..21.27 rows=1605 width=0)
 Index Cond: ((task_no)::text = (t.task_no)::text)
 -> Index Scan using lzl_202503_task_no_idx on lzl_202503 cc_3 (cost=0.43..1362.61 rows=1637 width=57)
 Index Cond: ((task_no)::text = (t.task_no)::text)
 Filter: ((created_date > '2025-01-07 09:00:00'::timestamp without time zone) AND (created_date < '2025-09-03 12:56:44.973'::timestamp without time zone))
 -> Index Scan using lzl_202504_task_no_idx on lzl_202504 cc_4 (cost=0.43..604.64 rows=1795 width=56)
 Index Cond: ((task_no)::text = (t.task_no)::text)
 Filter: ((created_date > '2025-01-07 09:00:00'::timestamp without time zone) AND (created_date < '2025-09-03 12:56:44.973'::timestamp without time zone))
 -> Index Scan using lzl_202505_task_no_idx on lzl_202505 cc_5 (cost=0.43..445.30 rows=1450 width=56)
 Index Cond: ((task_no)::text = (t.task_no)::text)
 Filter: ((created_date > '2025-01-07 09:00:00'::timestamp without time zone) AND (created_date < '2025-09-03 12:56:44.973'::timestamp without time zone))
 -> Index Scan using lzl_202506_task_no_idx on lzl_202506 cc_6 (cost=0.43..583.94 rows=1675 width=56)
 Index Cond: ((task_no)::text = (t.task_no)::text)
 Filter: ((created_date > '2025-01-07 09:00:00'::timestamp without time zone) AND (created_date < '2025-09-03 12:56:44.973'::timestamp without time zone))
 -> Index Scan using lzl_202507_task_no_idx on lzl_202507 cc_7 (cost=0.43..633.45 rows=1973 width=56)
 Index Cond: ((task_no)::text = (t.task_no)::text)
 Filter: ((created_date > '2025-01-07 09:00:00'::timestamp without time zone) AND (created_date < '2025-09-03 12:56:44.973'::timestamp without time zone))
 -> Index Scan using lzl_202508_task_no_idx on lzl_202508 cc_8 (cost=0.43..619.43 rows=1720 width=56)
 Index Cond: ((task_no)::text = (t.task_no)::text)
 Filter: ((created_date > '2025-01-07 09:00:00'::timestamp without time zone) AND (created_date < '2025-09-03 12:56:44.973'::timestamp without time zone))
 -> Index Scan using lzl_202509_task_no_idx on lzl_202509 cc_9 (cost=0.42..893.03 rows=1521 width=56)
 Index Cond: ((task_no)::text = (t.task_no)::text)
 Filter: ((created_date > '2025-01-07 09:00:00'::timestamp without time zone) AND (created_date < '2025-09-03 12:56:44.973'::timestamp without time zone))

created_date时间范围，找1年的数据，前晚变更加的索引是created_date。

加索引后的执行计划：

 -> Hash Join (cost=63.37..23740.82 rows=191 width=33)
 Hash Cond: ((cc.task_no)::text = (t.task_no)::text)
 -> Append (cost=0.00..23376.98 rows=114435 width=58)
 Subplans Removed: 28
 -> Index Scan using idx_lzltab_202501_created_date on lzltab_202501 cc_1 (cost=0.43..1450.59 rows=8958 width=66)
 Index Cond: ((created_date > $1) AND (created_date < $2))
 -> Index Scan using idx_lzltab_202502_created_date on lzltab_202502 cc_2 (cost=0.43..1822.73 rows=7405 width=66)
 Index Cond: ((created_date > $1) AND (created_date < $2))
 -> Index Scan using idx_lzltab_202503_created_date on lzltab_202503 cc_3 (cost=0.43..1430.03 rows=7917 width=57)
 Index Cond: ((created_date > $1) AND (created_date < $2))
 -> Index Scan using idx_lzltab_202504_created_date on lzltab_202504 cc_4 (cost=0.43..2412.44 rows=11041 width=56)
 Index Cond: ((created_date > $1) AND (created_date < $2))
 -> Index Scan using idx_lzltab_202505_created_date on lzltab_202505 cc_5 (cost=0.43..2260.73 rows=13381 width=56)
 Index Cond: ((created_date > $1) AND (created_date < $2))
 -> Index Scan using idx_lzltab_202506_created_date on lzltab_202506 cc_6 (cost=0.43..3930.10 rows=17832 width=56)
 Index Cond: ((created_date > $1) AND (created_date < $2))
 -> Index Scan using idx_lzltab_202507_created_date on lzltab_202507 cc_7 (cost=0.43..3878.77 rows=21786 width=56)
 Index Cond: ((created_date > $1) AND (created_date < $2))
 -> Index Scan using idx_lzltab_202508_created_date on lzltab_202508 cc_8 (cost=0.43..4736.72 rows=22033 width=56)
 Index Cond: ((created_date > $1) AND (created_date < $2))
 -> Index Scan using idx_lzltab_202509_created_date on lzltab_202509 cc_9 (cost=0.42..627.09 rows=1893 width=56)
 Index Cond: ((created_date > $1) AND (created_date < $2))
 -> Hash (cost=63.03..63.03 rows=27 width=24)
 -> Bitmap Heap Scan on ai_outbound_call_task t (cost=2.99..63.03 rows=27 width=24)
 Recheck Cond: ((created_by)::text = ($3)::text)
 -> Bitmap Index Scan on idx_ai_call_task_c (cost=0.00..2.99 rows=27 width=0)
 Index Cond: ((created_by)::text = ($3)::text)

新的执行计划从task_no索引变成走created_date索引，nl变成hash join。cost从2259694减少到23740，减少100倍。但是，实际执行时间增加了10倍左右。

问题定位
#

从3个问题来带入分析定位：

为什么优化人员建议了created_date索引？
为什么走到了新的索引？
为什么新的执行计划执行时间很长但预估rows很小？

为什么优化人员建议了created_date索引？
#

如果直接把pg日志中参数回填到sql文本，执行计划其实是好的那一个，也就是跑3s的走task_no索引的plan。优化人员也这么跑了，发现还可以。但是生产环境却不是这个执行计划。

即使强制不让走task_no索引，优化器选择全表扫描都不去走create date索引：

 Hash Cond: (((cc.task_no)::text || ''::text) = (t.task_no)::text)
 -> Append (cost=0.00..2794425.58 rows=22238757 width=57)
 -> Seq Scan on lzltab_202501 cc_1 (cost=0.00..193060.05 rows=1585238 width=66)
 Filter: ((created_date > '2025-01-08 11:00:00'::timestamp without time zone) AND (created_date < '2025-09-04 08:31:43'::timestamp without time zone))
 -> Seq Scan on lzltab_202502 cc_2 (cost=0.00..178567.54 rows=1480969 width=66)
 Filter: ((created_date > '2025-01-08 11:00:00'::timestamp without time zone) AND (created_date < '2025-09-04 08:31:43'::timestamp without time zone))
 -> Seq Scan on lzltab_202503 cc_3 (cost=0.00..191073.34 rows=1583356 width=57)

这就很奇怪，自己怎么跑都走不到created_date烂索引，生产环境又是怎么走到created_date的？

联想到有绑定变量，有可能会是generic plan。

generic plan的特性：

当force_custom_plan =auto时，对比generic plan和avg(前五次硬解析的执行计划的代价)，如果generic plan更小就用generic plan，后续不再进行硬解析；否则每次都硬解析（见源码choose_custom_plan）
generic plan长什么样子跟绑定变量本身是多少没有关系

使用绑定变量传值很容易复现：

PREPARE sql1(timestamp without time zone,timestamp without time zone,text) AS
SELECT COUNT(*)
xxxxxxx...;

=# EXECUTE sql1('2025-01-08 11:00:00','2025-09-04 08:31:43','LIUZHILONG62'); 
 count 
-------
 12016
(1 row)

Time: 367.220 ms
=# EXECUTE sql1('2025-01-08 11:00:00','2025-09-04 08:31:43','LIUZHILONG62'); 
 count 
-------
 12016
(1 row)

Time: 254.386 ms
=# EXECUTE sql1('2025-01-08 11:00:00','2025-09-04 08:31:43','LIUZHILONG62'); 
 count 
-------
 12016
(1 row)

Time: 235.343 ms
=# EXECUTE sql1('2025-01-08 11:00:00','2025-09-04 08:31:43','LIUZHILONG62'); 
 count 
-------
 12016
(1 row)

Time: 234.110 ms
=# EXECUTE sql1('2025-01-08 11:00:00','2025-09-04 08:31:43','LIUZHILONG62'); 
 count 
-------
 12016
(1 row)

Time: 233.570 ms
=# EXECUTE sql1('2025-01-08 11:00:00','2025-09-04 08:31:43','LIUZHILONG62'); 
 count 
-------
 12016
(1 row)

Time: 70678.344 ms (01:10.678) --第6次执行时间明显变长


=# select * from pg_prepared_statements\gx --pg14支持pg_prepared_statements
generic_plans | 1
custom_plans | 5

前5次硬解析用custom_plans跑出来都很快，第6次用到generic_plan，走的created_date，即为生产的故障计划，非常慢。

所以优化建议里用created_date是有些问题，但是替换变量为具体值后explain出来的执行计划是对的，而生产环境业务用绑定变量跑，跑到了generic plan，故障就此出现。

为什么新的执行计划执行时间很长但预估rows很小？
#

故障执行计划有个问题，预估的cost太小，rows太少

 -> Index Scan using idx_lzltab_202501_created_date on lzltab_202501 cc_1 (cost=0.43..1450.59 rows=8958 width=66)
 Index Cond: ((created_date > $1) AND (created_date < $2))

这从业务逻辑上看这有点不正常，因为create_date条件已经跨了多个分区，created_date是分区键，那么where created>=xx <=yy一定是连续的，在子分区上的选择率应该始终为1，rows应是子分区行数，应该是几百万而不是几千。

刚开始以为是统计信息的问题，但统计信息是比较准确的，202501的历史分区数据没有什么变动。

既然是generic plan需要从generic plan预估代价入手翻源码。cost要难一点，看rows的预估逻辑要相对简单些，也容易定位。

static double
calc_rangesel(TypeCacheEntry *typcache, VariableStatData *vardata,
			 const RangeType *constval, Oid operator)
{
...
		else
		{
			/* with any other operator, empty Op non-empty matches nothing */
			selec = (1.0 - empty_frac) * hist_selec;
		}
	}

	/* all range operators are strict */
	selec *= (1.0 - null_frac);

range_select=(1-null率)*直方图选择率，range直方图选择率看range命中的直方图对应的选择率再加个命中的MCV即可。不过这个案例不用算这些。

因为generic plan不看直方图：

/*
 * rangesel -- restriction selectivity for range operators
 */
Datum
rangesel(PG_FUNCTION_ARGS)
{
...
	/*
	 * If we got a valid constant on one side of the operator, proceed to
	 * estimate using statistics. Otherwise punt and return a default constant
	 * estimate. Note that calc_rangesel need not handle
	 * OID_RANGE_ELEM_CONTAINED_OP.
	 */
	if (constrange)
		selec = calc_rangesel(typcache, &vardata, constrange, operator);
	else
		selec = default_range_selectivity(operator);
...
}

calc_rangesel就是上面那个有常量值传入的选择率计算，else就是默认选择率函数default_range_selectivity，不传入常量

/*
 * Returns a default selectivity estimate for given operator, when we don't
 * have statistics or cannot use them for some reason.
 */
static double
default_range_selectivity(Oid operator)
{
	switch (operator)
	{
 ...
		case OID_RANGE_CONTAINS_ELEM_OP:
		case OID_RANGE_ELEM_CONTAINED_OP:

			/*
			 * "range @> elem" is more or less identical to a scalar
			 * inequality "A >= b AND A <= c".
			 */
			return DEFAULT_RANGE_INEQ_SEL;
	}
}

range的默认选择率define：

/* default selectivity estimate for range inequalities "A > b AND A < c" */
#define DEFAULT_RANGE_INEQ_SEL	0.005

返回生产环境计算rows

 select reltuples::bigint*0.005 from pg_class where relname='lzltab_202501'\gx
-[ RECORD 1 ]------
?column? | 8958.350

这跟实际的rows估算值8958相等：

idx_lzltab_202501_created_date on lzltab_202501 cc_1 (cost=0.43..1450.59 rows=8958 width=66)

所以新的执行计划估算不准确是因为generic plan使用了默认的选择率。

问题总结
#

为什么要有generic plan以及软解析的问题
#

把generic plan看成是DEFAULT estimate plan还更容易理解一点

为什么generic plan好像总是有问题？

理出以下思维链：

generic plan是为了减少硬解析，即使用软解析如果不是每次执行都是硬解析，那么可以不传入具体参数直接使用执行计划如果不传参直接用执行计划，那么需要提前生成执行计划

提前生成执行计划的方式：

不传参执行计划（generic plan）
用前几次传参生成的执行计划（pg没有这种东西）

如果使用generic plan，有可能是不准确的，比如

1.数据倾斜（如某个mcv极高，如where a=1，但a=1非常多），这极度依赖传入参数本身是啥，但generic plan不传参，所以执行计划不可能准确
2.数据均衡但无法准确计算选择率（如where a>$1 and a<$2），如果不知道range没人能计算出选择率，但generic plan不传参，所以执行计划不可能准确

如果前几次传参执行计划（pg没有这种东西），有可能也是不准确的，比如

数据倾斜，前几次传参没有普遍性，前几次传参极大的影响了后续固定的执行计划是什么

generic plan预估不准的问题分类
#

因为要5次对比，所以generic plan的问题可以分为2种：

前5次SQL的执行没有普遍性。跟前5次执行计划相关性大，依赖数据倾斜和前5次参数是否具有普遍性。
generic plan本身有问题。generic plan因为数据倾斜或数据均衡但无法准确计算选择率，导致generic plan本身执行效率低下

优化方案
#

从这个案例看下来，generic plan问题在分区表上可能会出现，分区键是连续的，扫描所有分区建选择率应该为1，但generic plan为0.05，很可能导致走“全索引”扫描这种场景。

所以在优化的时候需要考虑更多：

不要建太多索引迷惑优化器
排除generic plan的干扰。用EXECUTE真实跑6次
会话级别set plan_cache_mode='force_generic_plan'; or set plan_cache_mode='force_custom_plan';对比执行计划；或者在pg16+用explain (GENERIC_PLAN)对比执行计划

语法参考：

--prepare/excute
PREPARE sql1(text) AS
SELECT COUNT(*) FROM LZL where a=$1;

EXECUTE sql1('zzz'); --跑6次再说
EXPLAIN EXECUTE sql1('zzz');

select * from pg_prepared_statements --查看prepare语句信息，只能看当前会话

--对比执行计划，设置会话参数后执行EXPLAIN EXECUTE
set plan_cache_mode='force_generic_plan'
set plan_cache_mode='force_custom_plan'
--直接查看genetic plan,16+
explain (GENERIC_PLAN) xx 

案例-授权和walsender跑不动

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

现象
#

walsender LSN未推进，堆栈显示堵在pathman的invalidate_psin_entries_using_relid，relid改变，walsender cpu打满。

pstack 121327
#0 hash_seq_search (status=status@entry=0x7fffaadf8330) at dynahash.c:1441
#1 0x00002ba3b40ec728 in invalidate_psin_entries_using_relid (relid=relid@entry=42319501) at src/relation_info.c:251
#2 0x00002ba3b40ecb3d in forget_status_of_relation (relid=relid@entry=42319501) at src/relation_info.c:232
#3 0x00002ba3b40fcc96 in pathman_relcache_hook (arg=<optimized out>, relid=42319501) at src/hooks.c:934
#4 0x000000000087168a in LocalExecuteInvalidationMessage (msg=0x3a391c8) at inval.c:595
#5 0x000000000071d50e in ReorderBufferExecuteInvalidations (rb=0x1b63ff8, txn=0x1be5f58, txn=0x1be5f58) at reorderbuffer.c:2238
#6 ReorderBufferCommit (rb=0x1b63ff8, xid=xid@entry=4285897514, commit_lsn=405674661986920, end_lsn=<optimized out>, commit_time=commit_time@entry=799377897828299, origin_id=origin_id@entry=0, origin_lsn=origin_lsn@entry=0) at reorderbuffer.c:1819
#7 0x0000000000712d18 in DecodeCommit (xid=4285897514, parsed=0x7fffaadf8630, buf=0x7fffaadf87f0, ctx=0x1a359e8) at decode.c:637
#8 DecodeXactOp (ctx=0x1a359e8, buf=buf@entry=0x7fffaadf87f0) at decode.c:245
#9 0x00000000007130b2 in LogicalDecodingProcessRecord (ctx=0x1a359e8, record=0x1a35c80) at decode.c:114
#10 0x0000000000733662 in XLogSendLogical () at walsender.c:2885
#11 0x0000000000735942 in WalSndLoop (send_data=send_data@entry=0x733620 <XLogSendLogical>) at walsender.c:2287
#12 0x0000000000736692 in StartLogicalReplication (cmd=0x1846c68) at walsender.c:1213
#13 exec_replication_command (cmd_string=cmd_string@entry=0x181a288 "START_REPLICATION SLOT \"lzl_logical_rep\" LOGICAL 170F5/7C3EAE78 (\"proto_version\" '1', \"publication_names\" 'lzl_logical_rep')") at walsender.c:1640
#14 0x0000000000774e91 in PostgresMain (argc=<optimized out>, argv=argv@entry=0x1866478, dbname=0x18662b8 "lzldb", username=<optimized out>) at postgres.c:4325
#15 0x0000000000485989 in BackendRun (port=<optimized out>, port=<optimized out>) at postmaster.c:4526
#16 BackendStartup (port=0x18635b0) at postmaster.c:4210
#17 ServerLoop () at postmaster.c:1739
#18 0x0000000000702f08 in PostmasterMain (argc=argc@entry=3, argv=argv@entry=0x1814da0) at postmaster.c:1412
#19 0x000000000048660a in main (argc=3, argv=0x1814da0) at main.c:210

## 第二次执行，堆栈一致，relid改变
pstack 121327
#0 hash_seq_search (status=status@entry=0x7fffaadf8330) at dynahash.c:1441
#1 0x00002ba3b40ec728 in invalidate_psin_entries_using_relid (relid=relid@entry=26560221) at src/relation_info.c:251
#2 0x00002ba3b40ecb3d in forget_status_of_relation (relid=relid@entry=26560221) at src/relation_info.c:232
#3 0x00002ba3b40fcc96 in pathman_relcache_hook (arg=<optimized out>, relid=26560221) at src/hooks.c:934
#4 0x000000000087168a in LocalExecuteInvalidationMessage (msg=0x39f1f68) at inval.c:595
...

分析
#

relid改变说明walsender还在跑还没有死。LSN没有改变，可以分析LSN的位置，看看这个事务在做什么。

当时的信息还在的话，可以通过slot视图查restart LSN反查wal的位置。如果当时的信息不在，可以通过stack中的LSN来找到wal日志是哪个。

pg_waldump查看wal日志信息，过滤xid

rmgr: Heap len (rec/tot): 961/ 961, tx: 4285897514, lsn: 170F5/7DFE3470, prev 170F5/7DFE3430, desc: UPDATE+INIT off 2 xmax 4285897514 flags 0x00 ; new off 1 xmax 0, blkref #0: rel 1663/17662/1259 blk 8443, blkref #1: rel 1663/17662/1259 blk 7327

...
rmgr: Transaction len (rec/tot): 1778325/1778325, tx: 4285897514, lsn: 170F5/7E1F4268, prev 170F5/7E1F4220, desc: COMMIT 2025-05-01 09:24:57.828299 CST; inval msgs: catcache 22 catcache 22 catcache 22 catcache 22 catcache 50 catcache 49 catcache 50 catcache 49 catcache 50 catcache 49 catcache 50 catcache 49 catcache 50 catcache 49 catcache 50 
...
 relcache 48813261 relcache 48813255 relcache 51030741 relcache 48813252 relcache 50737247 relcache 48813246 relcache 48813243 relcache 48813237 relcache 50737241 relcache 48813234 relcache 48813224 relcache 49379811 relcache 48813216 relcache 48813210 relcache 45452775

rel 1663/17662/1259的record有18万条，最后一条record是inval msgs，catcache有7万，relcache 3万。

rel 1663/17662/1259是pg_class，通过xmin去查pg_class可以找到对应的表和xid提交时间：

select xmin,xmax,pg_xact_commit_timestamp(xmin),relname from pg_class where xmin='4285897514'::xid order by relname desc ;
 xmin | xmax | pg_xact_commit_timestamp | relname 
------------+------+-------------------------------+---------------------------------------------
 4285897514 | 0 | 2025-05-01 09:24:57.828299+08 | v$session
 4285897514 | 0 | 2025-05-01 09:24:57.828299+08 | tmp_20230801_id_seq
 4285897514 | 0 | 2025-05-01 09:24:57.828299+08 | tmp_20230801
 4285897514 | 0 | 2025-05-01 09:24:57.828299+08 | test_param
 4285897514 | 0 | 2025-05-01 09:24:57.828299+08 | test_20240105
 ...
 
 select count(*) from pg_class where xmin='4285897514'::xid ;
 count 
-------
 18523

 select count(*) from pg_class ;
 count 
--------
 139138

通过时间去查pglog日志：

2025-05-01 09:24:59.837 CST,"postgres","lzldb",61418,"[local]",6812cd65.efea,3,"DO",2025-05-01 09:24:53 CST,549/0,0,LOG,00000,"duration: 6036.275 ms statement: 
...
 EXECUTE 'GRANT SELECT ON ALL TABLES IN SCHEMA public TO r_lzldbdata_qry';
...
 END;
 $$",,,,,,,,,"psql","client backend"

基本可以定位是这个授权引起，因为授权会更新pgclass中的relacl，至少更新了1.8w个relation的权限，pgclass更新会触发invalidation消息，大量的invalidation消息在walsender进程中处理缓慢。

复现
#

--建逻辑复制链路，随便来个
select pg_create_logical_replication_slot('logical_test','test_decoding');
pg_recvlogical -h 127.0.0.1 -p 7997 -d lzldb -U repuser --slot=logical_test --start -f recv.sql &

--建多张表
DO $$
BEGIN
 FOR i IN 1..20000 LOOP
 EXECUTE format(
 'CREATE TABLE IF NOT EXISTS table_%s ( 
 col1 varchar(10)
 )', 
 lpad(i::text, 5, '0') -- 生成5位数字编号的表名
 );
 END LOOP;
END $$;

--一次授权
grant select on all tables in schema public to r_lzldb_qry;

--完美复现
postgres@lzlhost:~/lzl/grant]$ pstack 172862
#0 hash_seq_search (status=status@entry=0x7ffd664be280) at dynahash.c:1444
#1 0x00002ad31235e728 in invalidate_psin_entries_using_relid (relid=relid@entry=1002857) at src/relation_info.c:251
#2 0x00002ad31235eb3d in forget_status_of_relation (relid=relid@entry=1002857) at src/relation_info.c:232
#3 0x00002ad31236ec96 in pathman_relcache_hook (arg=<optimized out>, relid=1002857) at src/hooks.c:934
#4 0x000000000087168a in LocalExecuteInvalidationMessage (msg=0x2ad3c3f61a88) at inval.c:595
#5 0x000000000071d50e in ReorderBufferExecuteInvalidations (rb=0x17e5698, txn=0x180d698, txn=0x180d698) at reorderbuffer.c:2238


[postgres@lzlhost:~/lzl/grant]$ pstack 172862
#0 0x0000000000891d0c in hash_seq_search (status=status@entry=0x7ffd664be280) at dynahash.c:1441
#1 0x00002ad31235e728 in invalidate_psin_entries_using_relid (relid=relid@entry=1011110) at src/relation_info.c:251
#2 0x00002ad31235eb3d in forget_status_of_relation (relid=relid@entry=1011110) at src/relation_info.c:232
#3 0x00002ad31236ec96 in pathman_relcache_hook (arg=<optimized out>, relid=1011110) at src/hooks.c:934


--relid在动
--cpu打满:
ps -eo pid,%cpu,%mem|grep 172862
172862 99.3 0.0

--运行2h左右追平

without pathman加速walsender解析
#

因为库里面是没有用pathman分区表的，但有pathman extension，所以尝试绕过pathman hook以加速walsender解析过程。

drop extension pg_pathman;
grant update on all tables in schema public to r_lzldb_upd;

[postgres@lzlhost~/lzl/grant]$ pstack 133460
#0 hash_seq_search (status=status@entry=0x7ffe292d5c90) at dynahash.c:1418
#1 0x000000000087f228 in RelfilenodeMapInvalidateCallback (arg=<optimized out>, relid=1034036) at relfilenodemap.c:64
#2 0x000000000087168a in LocalExecuteInvalidationMessage (msg=0x2b9699795768) at inval.c:595
#3 0x000000000071d50e in ReorderBufferExecuteInvalidations (rb=0x195a358, txn=0x1a6ff38, txn=0x1a6ff38) at reorderbuffer.c:2238
#4 ReorderBufferCommit (rb=0x195a358, xid=xid@entry=328684387, commit_lsn=8016890875224, end_lsn=<optimized out>, commit_time=commit_time@entry=799851538975691, origin_id=origin_id@entry=0, origin_lsn=origin_lsn@entry=0) at reorderbuffer.c:1819

## 20s以内完成

没有注释shared_preload_libraries中的pg_pathman，同样有很好的效果，walsender从2小时缩短到20s。

这里感觉挺奇怪，没有注释shared_preload_libraries，hook应该还是要走的。分析源码发现，之所以有效果是因为hook的第一步就有pathman config表的判断，不会再走pathman中的invalidate逻辑了，所以很快可以执行完成：

/*
 * Invalidate PartRelationInfo cache entry if needed.
 */
void
pathman_relcache_hook(Datum arg, Oid relid)
{
	Oid pathman_config_relid;

	/* See cook_partitioning_expression() */
	if (!pathman_hooks_enabled)
		return;

	if (!IsPathmanReady())
		return;

...

	/*
	 * Invalidation event for PATHMAN_CONFIG table (probably DROP EXTENSION).
	 * Digging catalogs here is expensive and probably illegal, so we take
	 * cached relid. It is possible that we don't know it atm (e.g. pathman
	 * was disabled). However, in this case caches must have been cleaned
	 * on disable, and there is no DROP-specific additional actions.
	 */
	pathman_config_relid = get_pathman_config_relid(true);
	if (relid == pathman_config_relid)
	{
		delay_pathman_shutdown();
	}

	/* Invalidation event for some user table */
	else if (relid >= FirstNormalObjectId)
	{
		/* Invalidate PartBoundInfo entry if needed */
		forget_bounds_of_rel(relid);

		/* Invalidate PartStatusInfo entry if needed */
		forget_status_of_relation(relid);

		/* Invalidate PartParentInfo entry if needed */
		forget_parent_of_partition(relid);
	}
}

get_pathman_config_relid获取了pathman_config表，drop extension pg_pathman把db中pathman_config表删掉了，所以源码就不会走forget那一堆逻辑。

也有其他办法可以加速walsender解析，比如将pg_pathman.enable=off，会走if (!IsPathmanReady())直接return。或者最直接的注释shared_preload_libraries中的pg_pathman并重启实例（这是实例级不是db级）。

pg14的提升
#

pg14.0 release note:

Allow logical decoding to more efficiently process cache invalidation messages (Dilip Kumar) This allows logical decoding to work efficiently in presence of a large amount of DDL.

https://www.postgresql.org/docs/release/14.0/

patch:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=d7eb52d71

pg14ReorderBufferAddInvalidations的注释：

We require to record it in form of the change so that we can execute only the required invalidations instead of executing all the invalidations on each CommandId increment.

对比pg14和pg13，ReorderBufferCommit逻辑大改

13中处理事务的逻辑直接放在commit函数里ReorderBufferCommit

				case REORDER_BUFFER_CHANGE_INTERNAL_COMMAND_ID:
					Assert(change->data.command_id != InvalidCommandId);

					if (command_id < change->data.command_id)
					{
						command_id = change->data.command_id;

						if (!snapshot_now->copied)
						{
							/* we don't use the global one anymore */
							snapshot_now = ReorderBufferCopySnap(rb, snapshot_now,
																 txn, command_id);
						}

						snapshot_now->curcid = command_id;

						TeardownHistoricSnapshot(false);
						SetupHistoricSnapshot(snapshot_now, txn->tuplecid_hash);

						/*
						 * Every time the CommandId is incremented, we could
						 * see new catalog contents, so execute all
						 * invalidations.
						 */
						ReorderBufferExecuteInvalidations(rb, txn);
					}

14中的主要逻辑是ReorderBufferReplay->ReorderBufferProcessTXN

在ReorderBufferProcessTXN中新增case REORDER_BUFFER_CHANGE_INVALIDATION判断以执行ReorderBufferExecuteInvalidations执行reorderbuffer中的invalidate

				case REORDER_BUFFER_CHANGE_INVALIDATION:
					/* Execute the invalidation messages locally */
					ReorderBufferExecuteInvalidations(
													 change->data.inval.ninvalidations,
													 change->data.inval.invalidations);
					break;

ReorderBufferExecuteInvalidations之后的逻辑都差不多，没有多大变动。13对比14的ReorderBufferCommit主要差异：

ReorderBufferCommit不再是主要process txn的函数，调用栈更深
新增case REORDER_BUFFER_CHANGE_INVALIDATION判断，与REORDER_BUFFER_CHANGE_INTERNAL_COMMAND_ID标识区分，单独处理invalidation
移除以每个command_id处理invalidation的逻辑

根因和解决办法
#

walsender卡住的根因是有批量授权任务，导致pg_class多个元组更新，触发大量invalidation消息。GRANT privs ON ALL TABLES IN SCHEMA public TO role1 这样的授权语句在pg中是1个事务多个command处理的，而pg13 逻辑复制处理invalidation message时，会通过每个command去处理一次reorder buffer invalidate，并处理各个hook的inval hash表。在这个场景中，pathman hook在处理inval hash表较慢，从而导致复制延迟。

pathman处理较慢的触发条件（且）：

pg13-
批量授权
安装了pathman extension（无论是否使用）
逻辑复制链路

即使将pathman干掉，也会在RelfilenodeMapInvalidateCallback等函数上花较多cpu。pg13目前测下来，有pathman对比没有pathman，处理时间是小时级和分钟级的差距。

其他未测试但社区提及的场景（且）：

pg13-
批量DDL/TRUNCATE/DCL/DROP PUBLICATION
逻辑复制链路

短期解决办法：如果没有用到pathman表的，可以drop extension或者不加载pathman so；重启链路

长期解决办法：升级到pg14+（已测试非常快无延迟）

#

ref
#

https://www.postgresql.org/message-id/flat/17716-1fe42e7b44fc2f25%40postgresql.org

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=d7eb52d71

pg数据库运维经验2024

Wed, 08 Jan 2025 00:00:00 +0000

这篇文章主要是讲pg运维常见问题，两三年见一次的疑难杂症就不说了。

主要是技术性运维总结，主打通俗易懂和快速上手，尽量避免源码层面等深入分析。

SQL性能与执行计划
#

执行计划突变
#

pg官方不支持hint功能，并且计划永远不支持！ PG社区大概是这个意思"我们的优化器是完美的，如果当前执行计划不够优秀，那是开发不懂优化”。

不管pg社区怎么看，生产环境的执行计划突变问题是时常发生的，而且我们没有ORACLE那样原生且丰富的绑定执行计划手段来处理问题。这对生产运维来说是一个挑战，例如：某天早上，一个敏感的sql突然执行计划改变了，运行时间从0.1s上涨到1s，由于SQL有一定的并发导致数据库的cpu打满，业务感知明显。由于我们没有绑定执行计划的手段，此时我们唯二能做的快速恢复手段就是1.收集统计信息 2.scale up扩容cpu。

这里的快速恢复手段有个问题是：收集统计信息一定有用吗？好的DBA可以找到优化器中的关键问题步骤在哪，但是也不能快速脑补一个完整的执行计划出来，特别是SQL比较复杂的时候。收集统计信息这个恢复手段，实际上把SQL优化问题返还给了优化器，同时相信优化器是可以胜任这个工作的。虽然这看上去有些扯，但是在PG数据库中，绝大部分情况是有用的（对于已知收集统计信息无用的场景，见"order by limit问题"小节)。

为什么执行计划会突变且性能变差？

执行计划是基于成本的，而成本又基于统计信息，统计信息又是永远滞后的
SQL足够复杂的话执行路径就会有非常多种，优化器会根据成本选择最优的一条
PG提供了很多优化器参数可以调整，目的是以适配本地硬件设置（如seq_page_cost ,effective_cache_size等等），我们可以通过调整这些参数来微调优化器的倾向。但是这些参数太底层，虽然理论上是有优化空间，但都是牵一发而动全身的。特别是数据库上线后，调整这些参数就是一个极高风险的操作。从这些参数设置的理由来看，也可以推测执行计划不可能是100%完美的，因为优化器的推理也依赖环境

即使强如oracle，提供了各种方案稳固执行计划，它也保证不了SQL 100%不会出问题，因为SQL、数据、统计信息、绑定变量等等都是动态的。对于PGer来说还想不了那么远，不过我们可以尽可能地考虑稳定执行计划的方案，如下：

不要用太多的表连接。表越多可能的执行计划也就越多，甚至PG GEQO会放弃生成所有的执行计划，这就降低了最优执行计划的概率
不要写太过复杂的SQL。还要考虑SQL可能是框架（ORM）生成而不是业务人员手工编写的，这样的SQL一般是为了实现某个目标而几乎不考虑SQL的简洁性和阅读性，优化起来十分棘手。
不要乱建索引以迷惑优化器，必须有明确的目标
调整表的统计信息搜集阈值autovacuum_vacuum_scale_factor（参考“统计信息收集不及时”小节）
可以使用pg_hint_plan来提示优化器。

pg_hint_plan
#

pg_hint_plan是第三方插件，通过hint来提示优化器选择正确的执行计划。 pg_hint_plan支持：

指定扫描方式（如索引扫描）、连接方式（NL/HASH/MERGE）、连接顺序、memoize、指定预估行数、并行、GUC参数
通过hint_plan.hints绑定sql的执行计划，不需要改变业务SQL文本

pg_hint_plan缺陷：

子查询、外部表、CTE、视图、PL/SQL等有使用限制
compute_query_id会把hint当做注释忽略
未知的bug

这个插件虽然在持续更新，但是（我）还没有找到大规模生产应用的案例。另外我们在少量的生产应用场景中发现了一些问题，执行计划可能不会生效，这跟jdbc执行计划缓存有关系，至于有没有其他问题暂时不好下定论。总之pg_hint_plan是个好东西，但是生产大规模部署有待商榷。推荐静待其变，可以试用但不要对它产生依赖性。

统计信息收集不及时
#

统计信息是sql优化的基础，pg统计信息并不难但还是有很多人没弄明白。

pg的统计信息主要看这3个表：pg_class、pg_stat_all_tables、pg_stat

-- pg_class看pages和tuples
select relname,relpages,reltuples::bigint from pg_class where relname='lzlpg'\gx
-[ RECORD 1 ]------
relname | lzlpg
relpages | 187501
reltuples | 6000032

--pg_stat_all_tables看活元组、死元组，上次统计信息收集时间
 select relname,n_live_tup,n_dead_tup,last_analyze,last_autoanalyze from pg_stat_all_tables where relname='lzlpg'\gx
-[ RECORD 1 ]----+------------------------------
relname | lzlpg
n_live_tup | 6000032
n_dead_tup | 0
last_analyze | 2025-01-04 15:54:44.553057+08
last_autoanalyze | [null]

--pg_stats看列的统计信息，每个字段都需要了解含义
 select * from pg_stats where tablename='lzlpg' and attname='a'\gx
-[ RECORD 1 ]----------+-------
schemaname | public
tablename | lzlpg
attname | a
inherited | f
null_frac | 0
avg_width | 70
n_distinct | -1
most_common_vals | [null]
most_common_freqs | [null]
histogram_bounds | [null]
correlation | [null]
most_common_elems | [null]
most_common_elem_freqs | [null]
elem_count_histogram | [null]

统计信息过久很有可能会造成SQL执行计划改变，引起SQL性能问题。此时就需要查看pg_stat_all_tables表的last_autovacuum,last_autoanalyze时间来判断表的收集是不是滞后了。

为什么要调整？因为表的统计信息收集阈值autovacuum_analyze_scale_factor 默认值是0.1，也就是数据变化达到10%时，才会收集统计信息。例如一个10亿数据的表，数据变化达到1亿时才会收集，频率可能太低了。

应该结合是否核心业务表、SQL表连接个数、SQL复杂度、表访问频率、月初越界问题、数据倾斜问题等判断是否需要针对性的调整表的autovacuum_vacuum_scale_factor,autovacuum_analyze_scale_factor以提高统计信息收集频率，降低SQL执行计划突变的概率，同时也要避免收集过于频繁老是跑vacuum浪费资源。

到底该调整到多少？举个例子：

以月表（或月分区表）及SQL统计当天数据为例，由于autovacuum_analyze_scale_factor =0.1，月表在前10天基本每天都会收集，在第12天左右的时候可能不会收集，这时候统计信息可能越界，执行计划就有可能有问题。为了保证月表在每月的10-31天都收集统计信息，应该把autovacuum_analyze_scale_factor设置得小于0.03，所以推荐autovacuum_analyze_scale_factor=0.02

参数调整参考（请考虑表上的业务数据模型！）：

参数名	默认值	建议值
`autovacuum_vacuum_scale_factor`	`0.2`	`0.04`
`autovacuum_analyze_scale_factor`	`0.1`	`0.02`

优化器可能选择其他索引而不是主键
#

一般来说主键的过滤性已经是最高了，但是优化器可能也不会选择走主键

--复现命令
create table t1(a char(1000) primary key,b char(1000));
insert into t1 select md5(g::text),md5(g::text) from generate_series(1,10000) g;
create index idxa on t1(a);
create index idxb on t1(b);
analyze t1;

explain (analyze,buffers) select * from t1 where a='qwer' and b='qwer';
explain (analyze,buffers) select * from t1 where a='qwer' and b||''='qwer';

--a、b字段有同样的过滤性，但是优化器没有走主键而是走普通索引
explain (analyze,buffers) select * from t1 where a='qwer' and b='qwer';
 QUERY PLAN 
------------------------------------------------------------------------------------------------------------
 Index Scan using idxb on t1 (cost=0.41..5.43 rows=1 width=2008) (actual time=0.045..0.046 rows=0 loops=1)
 Index Cond: (b = 'qwer'::bpchar)
 Filter: (a = 'qwer'::bpchar)
 Buffers: shared hit=3

--强行走主键，cost只多一丢丢丢
explain (analyze,buffers) select * from t1 where a='qwer' and b||''='qwer';
 QUERY PLAN 
------------------------------------------------------------------------------------------------------------
 Index Scan using idxa on t1 (cost=0.41..5.44 rows=1 width=2008) (actual time=0.079..0.079 rows=0 loops=1)
 Index Cond: (a = 'qwer'::bpchar)`
 Filter: (((b)::text || ''::text) = 'qwer'::text)
 Buffers: shared read=3

虽然a、b两个字段类型和选择率是一样的，但是优化器没有选择走主键而是走了普通索引，从cost来看走主键的cost多了0.01。

这有什么问题？

从当前这个表数据分布来看选择普通索引问题不大，但是数据一旦变化，两个索引的执行计划效率就会有差别：

alter table t1 set (autovacuum_enabled ='off');
insert into t1 select md5(g::text),'repeat' from generate_series(20001,30000) g;

--b='repeat'过滤性很差，但是还是走b字段索引
explain (analyze,buffers) select * from t1 where a='qwer' and b='repeat';
 QUERY PLAN 
--------------------------------------------------------------------------------------------------------------
 Index Scan using idxb on t1 (cost=0.41..5.43 rows=1 width=2008) (actual time=15.823..15.824 rows=0 loops=1)
 Index Cond: (b = 'repeat'::bpchar)
 Filter: (a = 'qwer'::bpchar)
 Rows Removed by Filter: 10000
 Buffers: shared hit=2511

--对比走主键的执行计划
 explain (analyze,buffers) select * from t1 where a='qwer' and b||''='repeat';
 QUERY PLAN 
------------------------------------------------------------------------------------------------------------
 Index Scan using idxa on t1 (cost=0.41..5.44 rows=1 width=2008) (actual time=0.041..0.041 rows=0 loops=1)
 Index Cond: (a = 'qwer'::bpchar)
 Filter: (((b)::text || ''::text) = 'repeat'::text)
 Buffers: shared hit=3

即使真实的过滤性不好，优化器仍然选择走普通索引，但是走普通索引的效率要低很多，因为shared hit=2511远大于shared hit=3。如果是敏感业务sql或者数据量比较大的时候，就会有问题，这个问题在生产中也常见。解决办法：

手动收集统计信息；调高统计信息收集频率
pg_hint_plan
改写sql让其不能走普通索引

order by limit问题
#

order by limit的sql已是一个常见的问题了，网上案例和分析也比较多，这里就不详细分析了（可以参考我写这篇ORDER BY limit 10比ORDER BY limit 100更慢)。根本原因在于优化器目前无法评估数据以索引顺序存放在表的哪个位置，可能数据靠后而导致扫描过多的数据才返回limit。注意这个场景不是仅出现在order by limit，任何可以用到排序操作的+limit都可能有这个问题，如：group by +limit、distinct +limit、merge..

解决办法：

SQL改造：添加表达式防止走到排序列的索引上（含主键），如 order by ''||col1 limit xxx
创建复合索引：创建排序字段的索引字段的复合索引，优化器可能会选择这个索引，效率一般都比排序字段的索引高。这个方案也不用动sql。

表膨胀
#

某个东西阻止了死元组回收
#

抛开autovacuum配置问题和一些边缘场景，常见的阻塞是：

长事务。注意：不是同一个表的长事务也会阻止死元组回收；查询语句也会造成这个问题
复制槽。复制槽延迟和死的复制槽会造成这个问题

这两种常见都是比较好解决的，1.terminate长事务会话 2.删除复制槽或者让消费端分析消费为什么这么慢。

update并发高导致表膨胀
#

不同于某个东西阻止vacuum回收死元组，频繁的update导致表膨胀是因为死元组生成的速度快于vacuum回收的速度。一般来说这个场景的表的pg_stat_all_tables.n_tup_upd比较高，如果是因为表膨胀问题发现需要做repack的话，最好同时评估下是不是表的写入量大，应避免反复的手工repack。此时就需要调整表/索引的fillfactor参数。

原理参考这篇文章从很慢的唯一索引扫描到索引膨胀，结论我直接copy下来：

fillfactor原理：

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

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

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

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

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

推荐设置：

alter table lzlpg set (fillfactor=60);
alter index lzlpg_pkey set (fillfactor=70);
--以上命令只会对新page生效，对存量page需要做repack

--repack:
1.检查是否有长事务，有则先处理长事务
2.nohup pg_repack -d lzldb --table lzlpg -p 6666 -no-kill-backend > pgrepack_lzlpg_log.log 2>&1 &

长事务问题
#

长事务的知识点没有多少，及时告警及时处理就行了，但长事务问题绝对值得拿出来单独批斗。

长事务会导致许多问题，例如：

锁不释放导致应用阻塞
wal不回收导致磁盘告警
死元组不回收导致sql性能下降
还有些奇葩性能问题跟长事务相关
…

pg的长事务危害要比oracle、mysql来得大的多，pg中的长事务一定要严格管理。

子事务问题
#

“Subtransactions are basically cursed. Rip em out.”

子事务会造成很多问题，也是我们常踩的坑，在行业中也经常遇到子事务导致的问题。

行业踩坑记录：

Waiting for Postgres 17: Configurable SLRU cache sizes for increased performance

Subtransactions-overflow-and-the-performance-cliff

Why we spent the last month eliminating PostgreSQL subtransactions

子事务的出现：

PL/pgSQL functions containing a block with an exception clause
savepoints
JDBC+autosave=always （默认autosave=never ）
ODBC

注意OGG使用ODBC驱动，ODBC不能关闭子事务。

GaussDB提供的ODBC可以关闭子事务，参数ForExtensionConnector

所以我们可以建议应用使用子事务不超过64个，但很难建议他们不去使用OGG，因为脱O意味着使用依赖OGG 的数据同步工具。

子事务问题出现的场景和现象：

1(+)个长事务+子事务溢出+高并发业务，性能急剧下降
子事务溢出(64+)，性能稍微下降
子事务溢出(64+)+multixact，性能急剧下降
1(+)个长事务+1(+)个子事务，查询库性能急剧下降

pg17的提升：

SLRU是clog、multixact、subtrans等用来在共享内存中管理事务关系的。相关的源码定义如下：

/* Number of SLRU buffers to use for subtrans */
#define NUM_SUBTRANS_BUFFERS	32 //SLRU页面个数32个，这是共享内存中的

/*
 * Each backend advertises up to PGPROC_MAX_CACHED_SUBXIDS TransactionIds
 * for non-aborted subtransactions of its current top transaction. These
 * have to be treated as running XIDs by other backends.
 *
 * We also keep track of whether the cache overflowed (ie, the transaction has
 * generated at least one subtransaction that didn't fit in the cache).
 * If none of the caches have overflowed, we can assume that an XID that's not
 * listed anywhere in the PGPROC array is not a running transaction. Else we
 * have to look at pg_subtrans.
 */
#define PGPROC_MAX_CACHED_SUBXIDS 64	//超过64个则溢出，each backend

pg17对SLRU的提升：新增GUC参数可以配置SLRU槽的个数，拆分现有的SLRU锁由单个集中控制锁变为多个bank锁

提升效果：

（https://www.pgevents.ca/events/pgconfdev2024/sessions/session/53/slides/27/SLRU%20Performance%20Issues.pdf）

子事务处理方案：

开发规范：不要用savepoints，考虑on conflict语法处理写入冲突
开发规范：不要用exception
开发规范：确保jdbc没有显示打开autosave=always
添加监控：针对性的监控pg_stat_slru
添加监控：针对性的监控SAVEPOINT and EXCEPTION
CDC规范：谨慎使用ODBC，OGG或其他用到ODBC的工具，需要切割事务，一个大事务最高子事务个数上限为5W
升级版本：升级到PG17

并发与性能
#

快照和并发参数调整
#

参数名	参数类型	默认值	建议值	是否需要重启
`old_snapshot_threshold`	cpu	-1（社区版）	-1	是
`max_parallel_workers_per_gather`	cpu	2	0	否

old_snapshot_threshold参数打开很容易引起性能问题，网上资料已经很多了自行搜索，哪怕是需要重启数据库，也强烈推荐关闭参数。

max_parallel_workers_per_gather 参数会自动开墙大sql的并行，但是并行为2效率不会成比例提高2倍，参数建议在特殊场景下使用，如跑批时显示指定并行度。由于不需要重启，也就顺手一改的事。

关闭old_snapshot_threshold会不会有问题？

不会。old_snapshot_threshold参数目的是为了限制长事务，因为pg长事务很容易引起性能问题，但是参数本身也会引发性能问题就得不偿失了。

处理长事务可以很多手段：

长事务监控。这是最重要的，而且监控已经比较成熟了。
设置statement_timeout，默认0
设置transaction_timeout ，默认0，版本17=+支持
设置lock_timeout ，默认0，DDL语句建议会话级别开启
设置idle_in_transaction_session_timeout，默认0，已开启2h
设置idle_session_timeout ，默认0，这个场景没用

高并发提交导致LWLOCK:WALWrite
#

案例-insert value偶发慢分析

记忆点：

IO:WALWrite只有1个，而LWLOCK:WALWrite有几十个
不能直接看到LWLOCK的blocking chain，但是我可以从源码中得知，LWLOCK:WALWrite在等待IO:WALWrite
在这种并发高的小事务场景中，提高wal buffer内存大小理论上效果不会太理想

会引起什么问题？

并发写入阻塞，写入接口变慢，活动会话可能上涨
高并发小事务无法压榨磁盘IO

解决办法：

业务打散并发写入
业务合并提交
分析FPI，尝试减少FPI（参考FPI小节）
组提交（待研究）

WAL与延迟
#

FPI与checkpoint参数
#

pg的wal FPI发生在checkpoint后首次写入相关page时，所以checkpoint越频繁FPI出现的概率越高。

checkpoint频率与两个参数相关：

checkpoint_timeout
max_wal_size

原理如下：

(Egor Rogov PoStgreSQL 14 Internals)

max_wal_size默认是1GB，这对于负载高的库来说太小了，一般来说可以调大这个参数以减少FPI。

checkpoint_timeout默认是5分钟，目前来看比较合理。

FPI与离散写
#

即使调大了checkpoint的间隔，可能还是会有 FPI 问题，此时需要再排查业务是否有 UUID 离散写情况，可能需要业务改造为 sequence 或其他 UUID 方案。

找到具体索引示例：

1.查看FPI是否严重

--stats=record比较好用

pg_waldump -z --stats=record 00000001000001860000001B

2.排序哪个rel的FPW比较多

pg_waldump 00000001000001860000001B|grep FPW|awk -F ':' '{print $7}'|awk '{print $2}'|sort -n|uniq -c |sort -r|head -10

逻辑复制和复制槽
#

逻辑复制问题非常多，也是社区重点优化项之一，几乎每个版本都有很大提升。

逻辑复制和复制槽基础知识

spill问题
#

PG起库逻辑和spill导致起库慢问题分析

spill记忆点：

spill是逻辑解码的时候内存放不下事务信息了所以放到磁盘，spill文件存放的就是事务信息
每个walsender都有独立的解码，所以每个逻辑复制都有自己的spill
大事物spill时，会有大spill文件，一般文件数比较少
子事务spill时，每个子事务对应一个spill文件

版本：

PG12及以前是写死的4096条changes
PG13新增logical_decoding_work_mem参数，可调整内存大小以减少spill概率
PG14及以后支持流式复制Streaming
触发流式复制也需要一定的条件，所以即使有流式复制也可能会发生spill
PG17新增debug_logical_replication_streaming参数以强制触发流式传输

walsender阻止停库
#

PG停库逻辑和walsender阻止停库问题分析

其实任意进程不退出都会阻止停库，问题在于哪些比较容易搞出事。从停库代码流程来看archiver、walsender会常阻止停库，因为他们在停库阶段会做最后一次归档or日志传递。

如果停库卡在walsender，尝试用kill杀掉walsender而不是直接kill -9 ，此时checkpoint还没有跑完，强制停库会造成不一致停库。注意强制停库也最好用pg_ctl stop -D $PGDATA -m i来停库，而不是直接kill -9
如果停库卡在archiver，可以直接kill -9，因为checkpoint已经跑完了，库是一致性状态

分区表
#

分区表基础知识

由于PG分区表其实是很有特点的，有些特性知识不研究就不知道，开发一般弄不明白pg分区表，所以在使用分区表时会留下很多坑

分区表父表和子表索引不一致
#

由于创建子分区不规范，很多索引是在子表上建的（实际上不应该单独在子表上建索引），也没有做 ”所有子表创建索引+attach索引“的操作，导致父表其实没有索引或没用有效索引。父表因为没有数据所以其上没索引对业务没有影响，影响的是新建子分区时，只会继承父表索引，导致新的子表可能会缺少索引。

父表失效索引比较好处理，参考创建分区索引的正确姿势

--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;

父表没有主键比较难处理，参考分区表添加主键和唯一索引

添加主键在主表上申请AccessExclusiveLock，阻塞一切。分区表上添加索引很慢，主键又会造成后续的阻塞，目前没有影响较小的在分区表上添加主键的办法。虽然没有达到目的，可以考虑用“attach唯一索引+非空约束”的办法；或者只能申请较长的停分区表业务，等待创建索引完成；或者通过第三方同步工具将数据插入一个带主键的分区表。

滥用default分区
#

default分区过大导致parition of创建子分区长期阻塞

原因很简单：分区表新增子分区时，由于建分区的语句需要校验default分区中的数据，保证新分区数据范围与default分区的现有数据不冲突，导致create table partition of读取了大量的default分区数据，新建分区一直未完成。随后阻塞扩大，业务数据无法查询和写入。

default分区滥用是普遍的问题！社区pg本来也没有提供interval分区功能，开发哪天忘记创建分区了，数据就跑到default分区，也不会有任何报错和告警。但是日复一日···default分区就越来越大，最后发版建分区搞出问题。

default分区过大不能一直这么放着，虽然attach建分区可以避开阻塞问题，但出于各种角度考虑还是需要排这个雷。

default分区数据处理方案1：

detach default子分区，然后合理创建子分区，再将default表数据回插到分区表中。
如有必要，可在detach且创建合理子分区后，创建一个空的default分区，以保持业务数据的连续性。
注意detach跟attach不同，detach需要主表的8级锁。PG14支持detach concurrently，但不能有default分区。

default分区数据处理方案2：

detach default子分区，然后合理创建子分区，detached后的default表attach成普通子分区，需要注意range的范围。
如有必要，可在detach且创建合理子分区后，创建一个空的default分区，以保持业务数据的连续性。
注意detach跟attach不同，detach需要主表的8级锁。PG14支持detach concurrently，但不能有default分区。

default分区数据处理方案3：

新建表所有数据通过dts同步
rename表

方案3看起来是最矬的，但是我个人最推荐。原因是如果你的手里有5套库需要处理，那么可以用精湛方案没问题，如果你的手里有200套库需要处理，那么要投入的人力成本，dts应该是最佳落地方案。

分区表select权限丢失导致执行计划异常
#

用户对分区子表没用select权限，会导致用户执行的sql不能访问子表的统计信息，从而导致执行计划异常。正常partition of创建的分区表是不带select权限的，从主表访问数据可以访问到，所以这是范围比较大的问题。

解决方案

让云平台解决，自动化处理
落地select子分区权限的开发规范

高并发分区全扫描和LWLock:lockmanager
#

这也是一个很常见的问题！

推荐看下aws的文档，写的很清楚了：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/wait-event.lw-lock-manager.html

问题现象：

活动会话暴涨
LWLock:lockmanager等待事件严重
数据库性能cliff

发生场景：

sql查询多个分区
该sql并发较高

记忆点：

fastpath锁机制本身是为了“弱锁”快速访问，提升数据库并发而设计的
fastpath锁等级小于等于3。即是select、select for xxx、DML才能使用（弱锁便是锁模式必须小于ShareUpdateExclusiveLock，也就是1、2、3级锁有机会使用到fastpath）。换句话说就是为了正常业务都受益
FP_LOCK_SLOTS_PER_BACKEND，本地进程持有fastpath的锁不超过16个，超过16就要到内存中去获得锁，LWLock:lockmanager在此时产生
不仅是表，每个被访问的索引都要加锁
这个问题跟分区数量没有多大关系，即便分区比较少也可能触发LWLock:lockmanager等待导致性能下降

可以计算一下，如果一个分区表上有1个主键和2个普通索引，多少个分区就会用不到fastpath？

16/（3个索引+1表本身）-1父表本身=3个子分区

是的，3个子分区的全分区扫描就会可能会出现这个LWLock:lockmanager等待了。

如果是普通表的话，表上建16个索引也会用不到fastpath。

解决办法：

对于表不是特别大的，合并分区成普通表
sql加入分区过滤条件
减少索引（比较没用，因为一般子分区数就超过16个了）

难点：

在oracle脱O到PG库的场景中，由于oracle支持全局索引，主键和唯一索引可以不带分区键，到pg后主键和唯一索引必须要带分区键。

主键示例如下：

idxlzl(primarykey) --oracle
idxlzl(primarykey,partitionkey) --pg

常见的表上的sql是这样：

select col from tlzl where primarykey=12345;

这个场景要推动业务在这个sql上添加分区条件吗？很难。阻力在于“我已经传入主键了，你还要我怎样？如果我什么数据都知道，我还要查数据库吗？”

如果是这样，只能推荐改造分区表为普通表，目前没有想出其他好办法。

内存
#

对象过多导致relcache过大
#

记忆点：

relcache保留relation相关的元数据：oid、pg_class、分区表、子事务、行安全策略、统计信息、索引元数据、am等等。
每个会话都有自己的(rel)cache缓存系统数据（元数据等）
一般这个cache很小。当catalog很大且会话访问过所有catalog时，cache会变的很大
cache的管理很简单，没有删除机制和limit限制（其实有invalidation消息）
关闭会话会释放cache

解决办法：

减少对象，特别是要检查分区表子分区数是否太多了
设置激进的连接池断连参数，让业务连接中断更频繁

内存碎片问题
#

命令推荐：

cat /proc/meminfo|grep whatyouneed
cat /proc/buddyinfo

## cg内存
/opt/cgtools/cginfo -t perf -s mem 

#重点关注 pgscand/s直接内存回收指标，一般几万就代表有问题
sar -B -s "08:00:00" -e "09:00:00"
#min_free_kbytes设置:
cat /proc/sys/vm/min_free_kbytes
#所有进程的物理总内存使用量：
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}'

min_free_kbytes：

（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的状态是理想的。

vm.min_free_kbytes也就是min_pages线，十分重要的操作系统参数。非常低的值会阻止系统有效地回收内存，这可能会导致系统崩溃并中断服务。太高的值会增加系统回收活动，造成分配延迟，这可能导致系统立即进入内存不足状态。

优化效果：

min_free_kbytes调大+部署非业务时段drop cache，问题已经少很多了。

为什么是调高min_free_kbytes？

This is used to force the Linux VM to keep a minimum number of kilobytes free. The VM uses this number to compute a watermark[WMARK_MIN] value for each lowmem zone in the system. Each lowmem zone gets a number of reserved free pages based proportionally on its size.

min_free_kbytes调高的本质不是为了把对应的min page线提高已更高概率地触发直接内存回收，而是因为low page线在linux7以前是无法调整的，只能通过调高min page线以等比例的提高low page线以更容易触发异步回收，并给直接内存回收的触发创造缓冲时间。

Redhat 8 版本增加了2个内存参数来优化内存回收：watermark_scale_factor 可以在不调整min_free_kbytes情况下，抬高水位线。

建议开启大页：

大页在业务（pg库）申请连续内存的时候性能较好
大页也有助于减少page cache大小
shared_buffer可使用大页，需开启Huge_pages和操作系统已开启大页
生产开启了大页的库，性能有提升，问题更少
aws大页标准：除了几个测试套餐外，其他均默认开启大页且不可关闭

Huge_pages parameter is turned on by default for all DB instance classes other than t3.medium,db.t3.large,db.t4g.medium,db.t4g.large instance classes. You can’t change the huge_pages parameter value or turn off this feature in the supported instance classes of Aurora PostgreSQL.

cgroup和主机内存错位
#

cgroup中的内存达到cg内存限制后，kswapd 进程会优先回收cg中的内存，云主机售卖资源和cgroup配置，可能存在主机空闲内存在水位之上，而cg内存紧张，主机层面的pages_low ，导致kswapd 不会异步回收主机内存也不会回收cg内存，最终是通过触发直接回收内存CG中的DB内存需求。

根因在于cgroup中没有单独的free page内存管理机制。

这种情况只能把cg内存调高，云主机内存更多的超卖，以达更容易达到主机的pages_low。

shared_buffer和pagecache
#

pg是double buffer机制，目前还没有direct IO。

double buffer是指DB shared buffer一层共享内存，OS pagecache一层共享内存。在真实场景中，pagecache一般远大于shared buffer，而pagecache又是算在cgroup mem中的，没有算到监控cg内存中···

总之，要留足内存给pagecache使用，shared buffer不要超过太大（目前来看20GB足够），除非可以明显观察到等待事件中有buffer mapping相关内存等待，不然不要去调太大。

work_mem无法限制hash join/hash aggregate使用的内存
#

hash_mem_multiplier 用于限制基于hash-based operations的内存大小（应该包括hash join，hash agg等），限制是hash_mem_multiplier*work mem。hash_mem_multiplier默认为2。

在pg13以前虽然可以限制work mem，但是无法限制1个query使用了多少个hash操作，所以pg13增加了这个参数。也就是说13以前，是很难限制hash table的内存的。

在pg12-的生产环境中找到消耗300G内存的一个会话，罪魁祸首就是低版本没有hash table限制和执行计划错误的使用hash table

其他问题
#

排他备份和起库问题
#

正常来说，数据库停库再起库，起库的位置从pg_controldata中的LSN位置获取，但是如果PGDATA目录下有一个backup_label文件，启动位置LSN会从backup_label文件获取。

会引起什么问题：

磁盘快照直接打的是data目录快照，label文件有可能在里面，如果库大备份时间长的话，起库时间就很长
大问题：某些原因生产停库后，库启动会很久。根因在于起库的LSN应该从controldata中获取，而不是备份中

版本变化：

pg13:

pg_start_backup() pg_stop_backup()

支持排他和非排他模式，默认就是排他模式。排他模式会在start的时候在data目录下创建backup_label文件，stop的时候会清理。非排他模式start的时候不会创建label文件，stop的时候返回label信息。

pg15: pg_backup_start() pg_backup_stop()

函数名称变化，移除了排他备份模式。不会在启动备份的时候写backup_label文件，而是在结束备份的时候写入到备份区域。

pg_stat_activty无法查询
#

现象：

pg_stat_activty无法查询

当时的pstack如下：

#0 pgstat_read_current_status () at pgstat.c:3642
#1 0x0000000000727181 in pgstat_read_current_status () at pgstat.c:2788
#2 pgstat_fetch_stat_numbackends () at pgstat.c:2789
#3 0x000000000083f2ee in pg_stat_get_activity (fcinfo=0x25c2d98) at pgstatfuncs.c:575
#4 0x000000000065058f in ExecMakeTableFunctionResult (setexpr=0x25b1d28, econtext=0x25b1c48, argContext=<optimized out>, expectedDesc=0x2545218, randomAccess=false) at execSRF.c:234
#5 0x00000000006609dc in FunctionNext (node=node@entry=0x25b1b38) at nodeFunctionscan.c:94
#6 0x000000000065110c in ExecScanFetch (recheckMtd=0x660700 <FunctionRecheck>, accessMtd=0x660720 <FunctionNext>, node=0x25b1b38) at execScan.c:133

分析：

代码定位比较明确，卡在st_changecount成为奇数进入死循环。

什么场景会触发？OOM（可复现），backend异常退出（可能），terminate（maybe）；这三个场景不代表一定会造成这个问题。

社区邮件没有讨论出结果，目前来看触发概率不高。

解决方案：重启数据库

连接问题和连接池问题
#

IO error报错
#

IO error报错一般是业务层与数据库连接断开，业务层仍在使用已断连的连接导致的报错。该问题出现比较频繁，而且由于整个链路上涉及的组件多、知识域宽，所以诊断起来比较困难，以下做一个简单总结。

已知的主动断连场景：

1.hikari maxLifetime 现象：会话保持时间与参数一致。可能报错原因：业务显示事务执行 select 未提交，连接池断开会话，业务报 io error；could not rollback 相关错误。

pg.datasouce.maxLifetime

2.druid timeout 现象：业务 sql 执行超 20s 后连接断开

spring.datasource.dynamic.druid.socketTimeout=20000 
spring.datasource.dynamic.druid.connectTimeout=20000 
改为
spring.datasource.socketTimeout=3600000
spring.datasource.connectTimeout=3600000 

业务容器扩容和数据库连接上限
#

业务横向扩容和pg库的连接瓶颈：

HikariCP目前已是SpringBoot默认的连接池，伴随着SpringBoot和微服务的普及，HikariCP 的使用也越来越多。业务每扩容一个pod，数据库连接数都会上涨。原因在于maximumPoolSize虽然每个pod中配置没有动，但业务节点横向扩展了。从已有节点数、增加节点数、现有数据库连接总数可以成比例的计算出来数据库的空闲连接会加多少。

应用可以无状态的横向扩容，但是数据库不是，pg的连接上限参数max_connections，应用成倍的扩容是有可能造成idle连接数就打满了。max_connections的调整是个很麻烦的工作因为要重启数据库生效。

pg库连接上限:

还有一个点在于，业务无限横向扩容，max_connections应该随云实例套餐调整而调整，但是可以无限往上调整吗？很明显不是的。pg库，无论什么库，idle连接越多性能都会下降。

可参考AWS的做法： max_connections与套餐相关，最大值5000 ,LEAST({DBInstanceClassMemory/9531392},5000).这可以减少人力运维连接数，也给出了比较合理的最大值

PG起库逻辑和spill导致起库慢问题分析

Sat, 04 Jan 2025 00:00:00 +0000

问题现象-起库缓慢
#

版本pg13.2

数据库启动缓慢，startup进程在读取spill文件，文件名在变化。查看spill文件也很慢，ls -l最后跑出来有800w个文件spill文件。

为什么有上千万个spill文件
#

wal段和LSN的含义
#

LSN
#

LSN总体是一个64位的bigint，LSN实际长这样42D3B/1732C540（hex），斜杠/前是32位逻辑日志号，/后32位是段号+块号+块内偏移。这4个部分分别是：

32位	8位	11位	13位
逻辑日志号	日志段号	块号	块内偏移

块内偏移 8192=2^13

块号=16M（默认wal段大小）/8192

wal segment
#

wal文件名由3组16进制数字组成。

以8k的wal文件0000000300042D3B00000002为例：

32位	32位	32位
timeline	逻辑日志号	日志段号
00000003	00042D3B	00000002

可以看出LSN可以定位到wal文件名及文件中offset位置。

其中，LSN斜杠/前是逻辑日志号，斜杠/后8位的日志段号下面都会用到。

spill文件名转换
#

复制槽名：logical_ex2209_rep

spill文件名：xid-407989064-lsn-42D1E-20000000.spill

42D1E不是一个完整的LSN，不能直接用pg_walfile_name来定位wal文件名。42D1E是一个逻辑日志号，如果直接过滤文件名含42D1E的wal文件，可以找到16个wal文件。

能否通过数字20000000定位到wal日志段号从而定位到哪一个文件呢？

spill文件名：

/*
 * Given a replication slot, transaction ID and segment number, fill in the
 * corresponding spill file into 'path', which is a caller-owned buffer of size
 * at least MAXPGPATH.
 */
static void
ReorderBufferSerializedPath(char *path, ReplicationSlot *slot, TransactionId xid,
 XLogSegNo segno)
{
 XLogRecPtr recptr;

 XLogSegNoOffsetToRecPtr(segno, 0, wal_segment_size, recptr);

 snprintf(path, MAXPGPATH, "pg_replslot/%s/xid-%u-lsn-%X-%X.spill",
 NameStr(MyReplicationSlot->data.name),
 xid,
 (uint32) (recptr >> 32), (uint32) recptr);
}

pg_replslot/%s和xid-%u-lsn比较好理解，就是复制槽名称和xid。后面的recptr还要再看下定义：

/*
 * Pointer to a location in the XLOG. These pointers are 64 bits wide,
 * because we don't want them ever to overflow.
 */
typedef uint64 XLogRecPtr;

XLogSegNoOffsetToRecPtr是通过wal日志段号、段大小、offset计算LSN:

#define XLogSegNoOffsetToRecPtr(segno, offset, wal_segsz_bytes, dest) \
 (dest) = (segno) * (wal_segsz_bytes) + (offset)

XLogRecPtr就是LSN！那么

(uint32) (recptr >> 32)表示取LSN前32位，(uint32) recptr)取LSN后32位。

LSN前32位也就是刚才看到的LSN前半段，lsn-42D1E；LSN后32位实际上信息多了，这里只要LSN后32位中的前几位的段号即可。

因为传入的offset=0，也传入了segno，那么根本不需要wal日志段内偏移量信息，就可以计算出dest的值。wal_segsz_bytes的真实值是128M*1014*1024，将XLogSegNoOffsetToRecPtr中的式子转化下为：

segno= dest/(128*1024*1024)
-- 再把16进制20000000转化下
segno= x'20000000'::int/(128*1024*1024)
segno= 4

可以从式子算出日志段号segno，也就可以定位到wal文件号了。

所以，这里的spill文件名：xid-407989064-lsn-42D1E-20000000.spill对应的wal文件为

逻辑日志号=42D1E，段号=04：

ls 42D1E*04
0000000200042D1E00000004

pg_waldump可以看到xid 407989064在里面。

实际上wal大小在实例创建后也是固定的，即(128*1024*1024)是一个常量，那么segno跟(uint32) recptr绝对相关，但不相等。也就是说切换一个wal日志就会切换一个spill。

最后总结spill文件生成规则如下：

同一个事务id，如果跨wal就会产生多个spill。如：一个不含子事务的大事务跨越3个wal，就会对应3个spill文件
不同的事务id对应不同的spill。如：1000w个子事务对应1000w个spill

spill文件名结构xid-407989064-lsn-42D1E-20000000.spill：

xid	lsn前32位；即wal逻辑日志号	由wal日志段号换算；不等于段号
xid-407989064	lsn-42D1E	20000000

## 恢复出的环境

[postgres]$ ll |head -100
total 40000276
-rw------- 1 postgres postgres 184 Dec 6 15:20 state
-rw------- 1 postgres postgres 196 Dec 6 13:25 xid-407989064-lsn-42D1E-0.spill
-rw------- 1 postgres postgres 208 Dec 6 13:25 xid-407989064-lsn-42D1E-20000000.spill
...
-rw------- 1 postgres postgres 540 Dec 6 16:44 xid-407989064-lsn-42D2A-D0000000.spill
-rw------- 1 postgres postgres 152 Dec 6 13:09 xid-407989065-lsn-42D1D-C8000000.spill
-rw------- 1 postgres postgres 152 Dec 6 13:09 xid-407989066-lsn-42D1D-C8000000.spill
-rw------- 1 postgres postgres 152 Dec 6 13:09 xid-407989068-lsn-42D1D-C8000000.spill
-rw------- 1 postgres postgres 152 Dec 6 13:09 xid-407989070-lsn-42D1D-C8000000.spill
-rw------- 1 postgres postgres 152 Dec 6 13:09 xid-407989072-lsn-42D1D-C8000000.spill
-rw------- 1 postgres postgres 152 Dec 6 13:09 xid-407989076-lsn-42D1D-C8000000.spill
-rw------- 1 postgres postgres 152 Dec 6 13:09 xid-407989079-lsn-42D1D-C8000000.spill
-rw------- 1 postgres postgres 152 Dec 6 13:09 xid-407989080-lsn-42D1D-C8000000.spill
-rw------- 1 postgres postgres 152 Dec 6 13:09 xid-407989082-lsn-42D1D-C8000000.spill

[postgres@lzlhost /myhost/liuzhilong/pg_replslot/logical_ex9e15_rep]$ ll |awk '{print $9}'|awk -F '-' '{print $2}'|sort|uniq -c|wc -l
10000003
[postgres@lzlhost /myhost/liuzhilong/pg_replslot/logical_ex9e15_rep]$ ll |wc -l
10000070

所以我们在实际环境中看到了10000070个文件，文件的distinct xid有10000003个，也就是说1个父事务跨越约70个wal文件，这个父事务有1000w个子事务。

复制槽溢出测试
#

--发布订阅搭建复制链路
logical_decoding_work_mem = 64MB #pg_ctl reload
wal_segment_size =128 MB

--source
CREATE TABLE replication_table (
 id BIGSERIAL PRIMARY KEY,
 column1 char(2000),
 column2 char(2000),
 column3 char(2000)
);
create publication pub_test for table replication_table ;

--dest
CREATE TABLE replication_table (
 id BIGSERIAL PRIMARY KEY,
 column1 char(2000),
 column2 char(2000),
 column3 char(2000)
);

CREATE SUBSCRIPTION sub_test
CONNECTION 'host=127.0.0.1 port=8094 dbname=lzl user=lzl password=qwer'
PUBLICATION pub_test;

--source
select * from pg_replication_slots;

大事务、无子事务、复制表溢出测试
#

--创建一个大事务暂时不提交
begin;
insert into replication_table(column1,column2,column3) 
select 'a','b','c' from generate_series(1,1000000) g;

--复制槽溢出
 ll
total 331924
-rw------- 1 postgres postgres 184 Dec 9 20:22 state
-rw------- 1 postgres postgres 88226964 Dec 9 20:22 xid-5074343-lsn-163-38000000.spill
-rw------- 1 postgres postgres 119698488 Dec 9 20:22 xid-5074343-lsn-163-40000000.spill

大事务提交后，等待消费直至复制链路延迟为0，spill文件消失

M=# select pid,usename,sent_lsn,write_lsn,flush_lsn,replay_lsn,write_lag,flush_lag,replay_lag,reply_time from pg_stat_replication;
 pid | usename | sent_lsn | write_lsn | flush_lsn | replay_lsn | write_lag | flush_lag | replay_lag | reply_time 
--------+---------+--------------+--------------+--------------+--------------+-----------+-----------+------------+------------------------------
 163525 | lzl | 163/4996E1C8 | 163/4996E1C8 | 163/4996E1C8 | 163/4996E1C8 | [null] | [null] | [null] | 2024-12-09 20:25:35.14769+08
(1 row)

M=# select pid,usename,pg_wal_lsn_diff(pg_current_wal_lsn(),sent_lsn) diff_sent_mb,pg_wal_lsn_diff(pg_current_wal_lsn(),write_lsn) diff_write_mb,pg_wal_lsn_diff(pg_current_wal_lsn(),flush_lsn) diff_flush_mb,pg_wal_lsn_diff(pg_current_wal_lsn(),replay_lsn) diff_replay_mb,pg_walfile_name_offset(sent_lsn) sentoffset,pg_walfile_name_offset(write_lsn) writeoffset,pg_walfile_name_offset(flush_lsn) flush_lsn from pg_stat_replication;
 pid | usename | diff_sent_mb | diff_write_mb | diff_flush_mb | diff_replay_mb | sentoffset | writeoffset | flush_lsn 
--------+---------+--------------+---------------+---------------+----------------+-------------------------------------+-------------------------------------+-------------------------------
 163525 | lzl | 0 | 0 | 0 | 0 | (000000010000016300000009,26665416) | (000000010000016300000009,26665416) | (000000


[/mypg/pg8094/data/pg_replslot/sub_test]$ ll
total 357392
-rw------- 1 postgres postgres 184 Dec 9 20:23 state
-rw------- 1 postgres postgres 88226964 Dec 9 20:22 xid-5074343-lsn-163-38000000.spill
-rw------- 1 postgres postgres 137696328 Dec 9 20:23 xid-5074343-lsn-163-40000000.spill
-rw------- 1 postgres postgres 26076708 Dec 9 20:23 xid-5074343-lsn-163-48000000.spill
[/mypg/pg8094/data/pg_replslot/sub_test]$ ll
total 4
-rw------- 1 postgres postgres 184 Dec 9 20:25 state2666
(1 row)

大事务、无子事务、非复制表溢出测试
#

--source 创建一个不相干的表，准备写入数据
CREATE TABLE no_replication_table (
 id BIGSERIAL PRIMARY KEY,
 column1 char(2000),
 column2 char(2000),
 column3 char(2000)
);

--创建一个大事务暂时不提交
begin;
insert into no_replication_table(column1,column2,column3) 
select 'a','b','c' from generate_series(1,1000000) g;

--溢出
[postgres@lzldb:MYINST:8094 /mypg/pg8094/data/pg_replslot/sub_test]$ ll
total 357492
-rw------- 1 postgres postgres 184 Dec 9 20:09 state
-rw------- 1 postgres postgres 107511456 Dec 9 20:08 xid-5074106-lsn-163-28000000.spill
-rw------- 1 postgres postgres 137698804 Dec 9 20:09 xid-5074106-lsn-163-30000000.spill
-rw------- 1 postgres postgres 4308444 Dec 9 20:09 xid-5074106-lsn-163-38000000.spill

大事务、子事务、非复制表溢出测试
#

## 一次insert一行，每个insert一个子事务
echo "begin;">subtx.sql
for i in {1..1000000}
do
 echo "savepoint p$i;">>subtx.sql
 echo "insert into no_replication_table(column1,column2,column3) select 'a','b','c';">>subtx.sql
done


nohup psql -d lzl -f subtx.sql &

#执行过程中，观察到溢出80w+文件
[/myhost/pg8094/data/pg_replslot/sub_test]$ ll |wc -l
823749
[/myhost/pg8094/data/pg_replslot/sub_test]$ ll |head -10
total 1099532
-rw------- 1 postgres postgres 184 Dec 9 21:10 state
-rw------- 1 postgres postgres 1236 Dec 9 21:10 xid-5519686-lsn-163-70000000.spill
-rw------- 1 postgres postgres 252 Dec 9 21:09 xid-5519687-lsn-163-70000000.spill
-rw------- 1 postgres postgres 252 Dec 9 21:09 xid-5519688-lsn-163-70000000.spill
-rw------- 1 postgres postgres 252 Dec 9 21:09 xid-5519689-lsn-163-70000000.spill
-rw------- 1 postgres postgres 252 Dec 9 21:09 xid-5519690-lsn-163-70000000.spill
-rw------- 1 postgres postgres 252 Dec 9 21:09 xid-5519691-lsn-163-70000000.spill
-rw------- 1 postgres postgres 252 Dec 9 21:09 xid-5519692-lsn-163-70000000.spill
-rw------- 1 postgres postgres 252 Dec 9 21:09 xid-5519693-lsn-163-70000000.spill

数据库启动慢分析
#

startup进程起库流程分析
#

这里以堆栈编号逐栈解析起库流程：

11：main：没啥好说的

10：PostmasterMain：

在主循环前，会先调用起库流程 StartupPID = StartupDataBase();本质上是调用StartChildProcess(StartupProcess)

#define StartupDataBase()		StartChildProcess(StartupProcess)

9：StartChildProcess ：fork一个进程。该进程为启动postmaster的辅助进程，正常的子进程启动都走这个逻辑，在这一步fork。这里的入参AuxProcType=StartupProcess

8：AuxiliaryProcessMain：

因为MyAuxProcType=StartupProcess，所以走的是StartupProcessMain流程，这不同于walsender,walwrite,bgwriter这些子进程的流程。startup进程本身是为了宕机恢复读wal的进程，但是它还做了很多事情

	switch (MyAuxProcType)
	{
		case CheckerProcess:
			/* don't set signals, they're useless here */
			CheckerModeMain();
			proc_exit(1);		/* should never return */

		case BootstrapProcess:

			/*
			 * There was a brief instant during which mode was Normal; this is
			 * okay. We need to be in bootstrap mode during BootStrapXLOG for
			 * the sake of multixact initialization.
			 */
			SetProcessingMode(BootstrapProcessing);
			bootstrap_signals();
			BootStrapXLOG();
			BootstrapModeMain();
			proc_exit(1);		/* should never return */

		case StartupProcess: //这里这里这里这里
			/* don't set signals, startup process has its own agenda */
			StartupProcessMain();
			proc_exit(1);		/* should never return */

		case BgWriterProcess:
			/* don't set signals, bgwriter has its own agenda */
			BackgroundWriterMain();
			proc_exit(1);		/* should never return */

		case CheckpointerProcess:
			/* don't set signals, checkpointer has its own agenda */
			CheckpointerMain();
			proc_exit(1);		/* should never return */

		case WalWriterProcess:
			/* don't set signals, walwriter has its own agenda */
			InitXLOGAccess();
			WalWriterMain();
			proc_exit(1);		/* should never return */

		case WalReceiverProcess:
			/* don't set signals, walreceiver has its own agenda */
			WalReceiverMain();
			proc_exit(1);		/* should never return */

		default:
			elog(PANIC, "unrecognized process type: %d", (int) MyAuxProcType);
			proc_exit(1);
	}

7：StartupProcessMain：主要是为了调用StartupXLOG()

6：StartupXLOG：

函数注释：

This must be called ONCE during postmaster or standalone-backend startup

StartupXLOG无论怎样都会被postmaster调用，无论是否是崩溃停库还是一致性停库

	switch (ControlFile->state)
	{
 ...
			case DB_IN_PRODUCTION:
			ereport(LOG,
					(errmsg("database system was interrupted; last known up at %s",
							str_time(ControlFile->time))));
			break;

这跟log日志能对上，以下是log的停库起库输出：

2024-12-06 17:02:57.534 CST,,,447560,,65693cde.6d448,1325,,2023-12-01 09:54:38 CST,,0,LOG,00000,"database system is shut down",,,,,,,,,"","postmaster"
2024-12-06 17:03:49.536 CST,,,211844,,6752bdf3.33b84,1,,2024-12-06 17:03:47 CST,,0,LOG,00000,"ending log output to stderr",,"Future log output will go to log destination ""csvlog"".",,,,,,,"","postmaster"
2024-12-06 17:03:49.536 CST,,,211844,,6752bdf3.33b84,2,,2024-12-06 17:03:47 CST,,0,LOG,00000,"starting PostgreSQL 13.2 (RaseSQL 1.3) on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39.0.1), 64-bit",,,,,,,,,"","postmaster"
2024-12-06 17:03:49.537 CST,,,211844,,6752bdf3.33b84,3,,2024-12-06 17:03:47 CST,,0,LOG,00000,"listening on IPv4 address ""0.0.0.0"", port 7284",,,,,,,,,"","postmaster"
2024-12-06 17:03:49.539 CST,,,211844,,6752bdf3.33b84,4,,2024-12-06 17:03:47 CST,,0,LOG,00000,"listening on Unix socket ""/tmp/.s.PGSQL.7284""",,,,,,,,,"","postmaster"
2024-12-06 17:03:49.557 CST,,,211995,,6752bdf5.33c1b,1,,2024-12-06 17:03:49 CST,,0,LOG,00000,"database system was interrupted; last known up at 2024-12-06 17:00:10 CST",,,,,,,,,"","startup"

所以，当时停库后，控制文件记录的数据库状态为in production

Database cluster state: in production

in production这个状态是数据库正在运行，而不是正常的shutdown状态，说明当时数据库停库时不是一致性停库。

继续其中关于fsync的关键代码：

	/*----------
	 * If we previously crashed, perform a couple of actions:
	 *
	 * - The pg_wal directory may still include some temporary WAL segments
	 * used when creating a new segment, so perform some clean up to not
	 * bloat this path. This is done first as there is no point to sync
	 * this temporary data.
	 *
	 * - There might be data which we had written, intending to fsync it, but
	 * which we had not actually fsync'd yet. Therefore, a power failure in
	 * the near future might cause earlier unflushed writes to be lost, even
	 * though more recent data written to disk from here on would be
	 * persisted. To avoid that, fsync the entire data directory.
	 */
	if (ControlFile->state != DB_SHUTDOWNED &&
		ControlFile->state != DB_SHUTDOWNED_IN_RECOVERY)
	{
		RemoveTempXlogFiles();
		SyncDataDirectory();
	}

这里因为控制文件记录的状态不是正常停库的，所以走到if中调用SyncDataDirectory()做fsync持久化。

StartupXLOG做了很多很多事，其中跟spill相关的除了SyncDataDirectory()还有StartupReorderBuffer()：

	/*
	 * Initialize replication slots, before there's a chance to remove
	 * required resources.
	 */
	StartupReplicationSlots();

	/*
	 * Startup logical state, needs to be setup now so we have proper data
	 * during crash recovery.
	 */
	StartupReorderBuffer();

StartupReorderBuffer虽然也会被调用，它会调用ReorderBufferCleanupSerializedTXNs清理所有slot目录的spill文件（不是删除目录和state文件）

/*
 * Delete all data spilled to disk after we've restarted/crashed. It will be
 * recreated when the respective slots are reused.
 */
void
StartupReorderBuffer(void)
{
	DIR		 *logical_dir;
	struct dirent *logical_de;

	logical_dir = AllocateDir("pg_replslot");
	while ((logical_de = ReadDir(logical_dir, "pg_replslot")) != NULL)
	{
		if (strcmp(logical_de->d_name, ".") == 0 ||
			strcmp(logical_de->d_name, "..") == 0)
			continue;

		/* if it cannot be a slot, skip the directory */
		if (!ReplicationSlotValidateName(logical_de->d_name, DEBUG2))
			continue;

		/*
		 * ok, has to be a surviving logical slot, iterate and delete
		 * everything starting with xid-*
		 */
		ReorderBufferCleanupSerializedTXNs(logical_de->d_name);
	}
	FreeDir(logical_dir);
}

5：SyncDataDirectory：

这段函数注释非常重要：

/*
 * Issue fsync recursively on PGDATA and all its contents.
 *
 * We fsync regular files and directories wherever they are, but we
 * follow symlinks only for pg_wal and immediately under pg_tblspc.
 * Other symlinks are presumed to point at files we're not responsible
 * for fsyncing, and might not have privileges to write at all.
 *
 * Errors are logged but not considered fatal; that's because this is used
 * only during database startup, to deal with the possibility that there are
 * issued-but-unsynced writes pending against the data directory. We want to
 * ensure that such writes reach disk before anything that's done in the new
 * run. However, aborting on error would result in failure to start for
 * harmless cases such as read-only files in the data directory, and that's
 * not good either.
 *
 * Note that if we previously crashed due to a PANIC on fsync(), we'll be
 * rewriting all changes again during recovery.
 *
 * Note we assume we're chdir'd into PGDATA to begin with.
 */

fsync所有data目录文件使之持久化
这个动作只会发生在起库阶段
这个动作是为了保证在数据库运行前data目录是完全持久化的

SyncDataDirectory主体是递归遍历目录并fsync（link文件稍微特殊处理一下）：

	walkdir(".", datadir_fsync_fname, false, LOG);
	if (xlog_is_symlink)
		walkdir("pg_wal", datadir_fsync_fname, false, LOG);
	walkdir("pg_tblspc", datadir_fsync_fname, true, LOG);

4：walkdir：递归到.

3：walkdir：递归到./pg_replslot

2：walkdir：递归到./pg_replslot/slotname

1：lstat ：C库调用。walkdir不仅要做fsync（入参函数datadir_fsync_fname），walkdir函数本体还要做 lstat获取文件信息，如inode、文件大小、最近修改时间等等，类似linux的stat命令。

0：_lxstat：C库调用

起库逻辑汇总：

pg会启动一个辅助进程startup以协助起库，不同于在常见的childprocess（walwriter、bgwriter、checkpointer等等）进程，它是起库过程中必定会启动的进程，它会做很多事情
StartupXLOG起库时一定会被调用，无论数据库是否一致性停库
只有非正常停库状态下，才会触发SyncDataDirectory
SyncDataDirectory会fsync持久化所有data文件，并查看所有data文件的stat信息
fsync是为了在库启动前保证data文件都一致；stat应该是为了验证文件是否正常和可读（在startup进程启动前只验证过datadir目录可读性）
无论停库状态，StartupReorderBuffer一定会被调用并清理所有复制槽的spill文件

什么时候是ready状态
#

startup进程把活干完后数据库还不是ready状态，在pmState状态机改变状态时会调用reaper回收进程函数。reaper函数本身是为了子进程退出后进行一些回收或者启动工作。pmState状态机记录状态为PM_STARTUP，状态机是控制启停库状态的。

PostmasterMain的最后几步：

	StartupPID = StartupDataBase();
	Assert(StartupPID != 0);
	StartupStatus = STARTUP_RUNNING;
	pmState = PM_STARTUP; //状态机改变状态

	/* Some workers may be scheduled to start now */
	maybe_start_bgworkers();

	status = ServerLoop();

	/*
	 * ServerLoop probably shouldn't ever return, but if it does, close down.
	 */
	ExitPostmaster(status != STATUS_OK);

	abort();					/* not reached */
}

PostmasterMain起库的核心流程会走到reaper以处理startup进程的正常退出，

PMState注释：

/*
 * We use a simple state machine to control startup, shutdown, and
 * crash recovery (which is rather like shutdown followed by startup).
 *
 * After doing all the postmaster initialization work, we enter PM_STARTUP
 * state and the startup process is launched. The startup process begins by
 * reading the control file and other preliminary initialization steps.
 * In a normal startup, or after crash recovery, the startup process exits
 * with exit code 0 and we switch to PM_RUN state. 

PMState会被信号传递和处理，startup进程退出后reaper会被激活以回收进程。

reaper函数处理startup子进程的正常退出态：

		if (pid == StartupPID)
		{
			StartupPID = 0;
...

			/*
			 * Startup succeeded, commence normal operations
			 */
			StartupStatus = STARTUP_NOT_RUNNING; //由STARTUP_RUNNING转成STARTUP_NOT_RUNNING
			FatalError = false; //上面一堆if未命中后，才不是fatal的
			AbortStartTime = 0;
			ReachedNormalRunning = true;
			pmState = PM_RUN; //状态机由PM_STARTUP转成PM_RUN
			connsAllowed = ALLOW_ALL_CONNS;

			/*
			 * Crank up the background tasks, if we didn't do that already
			 * when we entered consistent recovery state. It doesn't matter
			 * if this fails, we'll just try again later.
			 */
 //以下都在启动核心子进程
			if (CheckpointerPID == 0)
				CheckpointerPID = StartCheckpointer();
			if (BgWriterPID == 0)
				BgWriterPID = StartBackgroundWriter();
			if (WalWriterPID == 0)
				WalWriterPID = StartWalWriter();

			/*
			 * Likewise, start other special children as needed. In a restart
			 * situation, some of them may be alive already.
			 */
 //以下都在启动非核心子进程
			if (!IsBinaryUpgrade && AutoVacuumingActive() && AutoVacPID == 0)
				AutoVacPID = StartAutoVacLauncher();
			if (PgArchStartupAllowed() && PgArchPID == 0)
				PgArchPID = pgarch_start();
			if (PgStatPID == 0)
				PgStatPID = pgstat_start();

			/* workers may be scheduled to start now */
			maybe_start_bgworkers();
		 //此时才是正式的可接受连接状态
			/* at this point we are really open for business */
			ereport(LOG,
					(errmsg("database system is ready to accept connections")));

			/* Report status */
			AddToDataDirLockFile(LOCK_FILE_LINE_PM_STATUS, PM_STATUS_READY);
#ifdef USE_SYSTEMD
			sd_notify(0, "READY=1");
#endif

			continue;
		}

“database system is ready to accept connections”信息就在这里了

checkpointer、bgwrite、walwrite、autovacuum、arch（如有）、stat这些进程都需要启动，在这个阶段拉起这些进程不是必须返回成功的，后续也可以在ServerLoop或者再次执行reaper时尝试启动，只有startup进程是必须一次性必须启动并完成所有相关任务的：

	if (pid < 0)
	{
		/* in parent, fork failed */
		int			save_errno = errno;

		errno = save_errno;
		switch (type)
		{
			case StartupProcess:
				ereport(LOG,
						(errmsg("could not fork startup process: %m")));
				break;
			case BgWriterProcess:
				ereport(LOG,
						(errmsg("could not fork background writer process: %m")));
				break;
			case CheckpointerProcess:
				ereport(LOG,
						(errmsg("could not fork checkpointer process: %m")));
				break;
			case WalWriterProcess:
				ereport(LOG,
						(errmsg("could not fork WAL writer process: %m")));
				break;
			case WalReceiverProcess:
				ereport(LOG,
						(errmsg("could not fork WAL receiver process: %m")));
				break;
			default:
				ereport(LOG,
						(errmsg("could not fork process: %m")));
				break;
		}

		/*
		 * fork failure is fatal during startup, but there's no need to choke
		 * immediately if starting other child types fails.
		 */
		if (type == StartupProcess)
			ExitPostmaster(1);
		return 0;
	}

spill文件生成逻辑各版本差异
#

spill在各个版本都是spill最大的事务，这里重点关注啥时候spill的逻辑

PG12：pg12的changes是4096条写死

static const Size max_changes_in_memory = 4096;

/*
 * Check whether the transaction tx should spill its data to disk.
 */
static void
ReorderBufferCheckSerializeTXN(ReorderBuffer *rb, ReorderBufferTXN *txn)
{
	/*
	 * TODO: improve accounting so we cheaply can take subtransactions into
	 * account here.
	 */
	if (txn->nentries_mem >= max_changes_in_memory)
	{
		ReorderBufferSerializeTXN(rb, txn);
		Assert(txn->nentries_mem == 0);
	}
}

PG13:超过logical_decoding_work_mem内存大小就spill

static void
ReorderBufferCheckMemoryLimit(ReorderBuffer *rb)
{
...
	while (rb->size >= logical_decoding_work_mem * 1024L)
	{
		/*
		 * Pick the largest transaction (or subtransaction) and evict it from
		 * memory by serializing it to disk.
		 */
		txn = ReorderBufferLargestTXN(rb);

		ReorderBufferSerializeTXN(rb, txn);
...
}

PG14：多个了一个流式传输ReorderBufferStreamTXN

static void
ReorderBufferCheckMemoryLimit(ReorderBuffer *rb)
{
...
	while (rb->size >= logical_decoding_work_mem * 1024L)
	{
		/*
		 * Pick the largest transaction (or subtransaction) and evict it from
		 * memory by streaming, if possible. Otherwise, spill to disk.
		 */
		if (ReorderBufferCanStartStreaming(rb) &&
			(txn = ReorderBufferLargestTopTXN(rb)) != NULL)
		{...
			ReorderBufferStreamTXN(rb, txn);
		}
		else
		{...
			ReorderBufferSerializeTXN(rb, txn);
		}
...
}

14虽然有了流式复制，但是触发是要一定条件的：

/* Returns true, if the streaming can be started now, false, otherwise. */
static inline bool
ReorderBufferCanStartStreaming(ReorderBuffer *rb)
{
	LogicalDecodingContext *ctx = rb->private_data;
	SnapBuild *builder = ctx->snapshot_builder;

	/* We can't start streaming unless a consistent state is reached. */
	if (SnapBuildCurrentState(builder) < SNAPBUILD_CONSISTENT)
		return false;

	/*
	 * We can't start streaming immediately even if the streaming is enabled
	 * because we previously decoded this transaction and now just are
	 * restarting.
	 */
	if (ReorderBufferCanStream(rb) &&
		!SnapBuildXactNeedsSkip(builder, ctx->reader->EndRecPtr))
		return true;

	return false;
}

	/*
	 * Found a point after SNAPBUILD_FULL_SNAPSHOT where all transactions that
	 * were running at that point finished. Till we reach that we hold off
	 * calling any commit callbacks.
	 */
	SNAPBUILD_CONSISTENT = 2

额外的steam触发条件：

条件1：快照中的事务涵盖的所有事务都已完成（应该指commit or rollback）
条件2：context是私有数据（是不是说两条链路一张表就不会触发steam？）
条件3：快照中的事务是不可忽略的事务（可能指特殊的事务可以忽略，就不做了）

PG15：跟14差不多，只是函数更清晰，套娃少一些了

PG16：差不多

PG17：差不多，新增一个DEBUG_LOGICAL_REP_STREAMING_IMMEDIATE可以强制stream

记忆点：

PG12及以前是写死的4096条changes
PG13新增logical_decoding_work_mem参数，可调整内存大小以减少spill概率
PG14及以后支持流式复制Streaming
触发流式复制也需要一定的条件，所以即使有流式复制也可能会发生spill
PG17新增debug_logical_replication_streaming参数以强制触发流式传输

spill文件清理逻辑
#

起库时清理spill其实只是一种场景，还有启动walsender清理和drop slot清理。

walsender启动时清理
#

ReorderBufferCleanupSerializedTXNs会在数据库启动（walsender还没有启动）、walsender启动（数据库运行中）时被调用，注意这两部分场景是不一样的，只是他们会调用同一个函数。从函数注释部分也可以看出，该函数是为了“删除残留的序列化的reorder buffers”，即清理spill文件。

/*
 * Remove any leftover serialized reorder buffers from a slot directory after a
 * prior crash or decoding session exit.
 */
static void
ReorderBufferCleanupSerializedTXNs(const char *slotname)
{
	DIR		 *spill_dir;
	struct dirent *spill_de;
	struct stat statbuf;
	char		path[MAXPGPATH * 2 + 12];

	sprintf(path, "pg_replslot/%s", slotname);

	/* we're only handling directories here, skip if it's not ours */
	if (lstat(path, &statbuf) == 0 && !S_ISDIR(statbuf.st_mode))
		return;

	spill_dir = AllocateDir(path);
	while ((spill_de = ReadDirExtended(spill_dir, path, INFO)) != NULL)
	{
		/* only look at names that can be ours */
 //只对比前3个字符
		if (strncmp(spill_de->d_name, "xid", 3) == 0)
		{
			snprintf(path, sizeof(path),
					 "pg_replslot/%s/%s", slotname,
					 spill_de->d_name);

			if (unlink(path) != 0)
				ereport(ERROR,
						(errcode_for_file_access(),mkdir 
						 errmsg("could not remove file \"%s\" during removal of pg_replslot/%s/xid*: %m",
								path, slotname)));
		}
	}
	FreeDir(spill_dir);
}

以上清理逻辑需要注意两点：

清理文件名以“xid”开头的文件。很明显state文件是不能清理的
unlink清理，一次清理一个文件。考虑这一点可以帮助我们构建加速起库方案

数据库启动时清理
#

数据库启动时会fork一个startup进程来清理slot，清理函数跟walsender调用的清理函数一致：ReorderBufferCleanupSerializedTXNs。

还有一个区别在于，walsender重启后，只会清理当前同名slot spill；而数据库启动时会顺序清理所有slot spill。

数据库启动startup进程，while顺序清理逻辑：

void
StartupReorderBuffer(void)
{
	DIR		 *logical_dir;
	struct dirent *logical_de;

	logical_dir = AllocateDir("pg_replslot");
	while ((logical_de = ReadDir(logical_dir, "pg_replslot")) != NULL)
	{	//排除.和..
		if (strcmp(logical_de->d_name, ".") == 0 ||
			strcmp(logical_de->d_name, "..") == 0)
			continue;
		//验证slotname是否规范
		/* if it cannot be a slot, skip the directory */
		if (!ReplicationSlotValidateName(logical_de->d_name, DEBUG2))
			continue;

		/*
		 * ok, has to be a surviving logical slot, iterate and delete
		 * everything starting with xid-*
		 */
		ReorderBufferCleanupSerializedTXNs(logical_de->d_name);
	}
	FreeDir(logical_dir);
}

while循环调用ReorderBufferCleanupSerializedTXNs，后面跟walsender启动清理逻辑就一样了。

pg_drop_replication_slot手动清理
#

drop slot清理逻辑跟自动清理spill文件的逻辑不一样，它没有调用到ReorderBufferCleanupSerializedTXNs。

drop slot流程如下：

pg_drop_replication_slot(PG_FUNCTION_ARGS)->ReplicationSlotDrop(const char *name, bool nowait)->ReplicationSlotDropAcquired(void)->ReplicationSlotDropPtr

ReplicationSlotDropPtr清理复制槽的逻辑也很有意思:

/*
 * Permanently drop the replication slot which will be released by the point
 * this function returns.
 */
static void
ReplicationSlotDropPtr(ReplicationSlot *slot)
{
	char		path[MAXPGPATH];
	char		tmppath[MAXPGPATH];

	/*
	 * If some other backend ran this code concurrently with us, we might try
	 * to delete a slot with a certain name while someone else was trying to
	 * create a slot with the same name.
	 */
	LWLockAcquire(ReplicationSlotAllocationLock, LW_EXCLUSIVE);

	/* Generate pathnames. */
	sprintf(path, "pg_replslot/%s", NameStr(slot->data.name));
	sprintf(tmppath, "pg_replslot/%s.tmp", NameStr(slot->data.name));

	/*
	 * Rename the slot directory on disk, so that we'll no longer recognize
	 * this as a valid slot. Note that if this fails, we've got to mark the
	 * slot inactive before bailing out. If we're dropping an ephemeral or a
	 * temporary slot, we better never fail hard as the caller won't expect
	 * the slot to survive and this might get called during error handling.
	 */
	if (rename(path, tmppath) == 0) //rename文件
	{
		/*
		 * We need to fsync() the directory we just renamed and its parent to
		 * make sure that our changes are on disk in a crash-safe fashion. If
		 * fsync() fails, we can't be sure whether the changes are on disk or
		 * not. For now, we handle that by panicking;
		 * StartupReplicationSlots() will try to straighten it out after
		 * restart.
		 */
 //fsync持久化
		START_CRIT_SECTION();
		fsync_fname(tmppath, true);
		fsync_fname("pg_replslot", true);
		END_CRIT_SECTION();
	}
...

	/*
	 * If removing the directory fails, the worst thing that will happen is
	 * that the user won't be able to create a new slot with the same name
	 * until the next server restart. We warn about it, but that's all.
	 */
 
	if (!rmtree(tmppath, true))
		ereport(WARNING,
				(errmsg("could not remove directory \"%s\"", tmppath)));
	/*
	 * We release this at the very end, so that nobody starts trying to create
	 * a slot while we're still cleaning up the detritus of the old one.
	 */
	LWLockRelease(ReplicationSlotAllocationLock);
}

drop slot不是直接去复制槽目录下面去unlink，而是先把复制槽目录slotname/rename成 slotname.tmp/，然后再去做unlink目录下的文件，最后再删除 slotname.tmp/目录本身。

其中rmtree也是在循环unlink文件。

复制槽溢出发生后加速起库方案测试
#

1000w个spill删除起来肯定是很慢的，直接mv目录的话就非常快。但是直接mv需要注意mv后的名称和state文件，以及需要知道mv到底跳过了哪一个源码步骤。

mv的名称注意事项
#

由于是异常停库，startup进程会执行SyncDataDirectoryfsync和stat所有data文件，这一点是比较难绕过的。SyncDataDirectory做完以后，才开始处理复制槽。处理复制槽时会调用StartupReorderBuffer()->ReorderBufferCleanupSerializedTXNs全量清理spill文件。

在进入清理前，会调用ReplicationSlotValidateName校验复制槽名称的有效性，我们可以在ReplicationSlotValidateName上做文章，以骗过startup进程跳过ReorderBufferCleanupSerializedTXNs的过程。

ReplicationSlotValidateName规则：

bool
ReplicationSlotValidateName(const char *name, int elevel)
{
...

	for (cp = name; *cp; cp++)
	{ //关键规则在这里
		if (!((*cp >= 'a' && *cp <= 'z')
			 || (*cp >= '0' && *cp <= '9')
			 || (*cp == '_')))
		{
			ereport(elevel,
					(errcode(ERRCODE_INVALID_NAME),
					 errmsg("replication slot name \"%s\" contains invalid character",
							name),
					 errhint("Replication slot names may only contain lower case letters, numbers, and the underscore character.")));
			return false;
		}
	}
	return true;
}

有效slot name只包含a-z;0-9;_。

所以rename时建议加个点.，

建议slotname.bak,slotname.20241215等。
不建议slotnamebackup,slotname20241215,slotname_bak等等
不建议.tmp后缀，slotname有.tmp后缀有特殊含义

最后rename后，要创建目录和拷贝state，不然启动的slot会表现的很反常（比如重复的slotname、自动生产一个slotname、删不到slot、下游起不来链路等等）。

汇总推荐mv操作如下：

cd pg_replslot
mv slotname slotname.bak 
mkdir slotname
cp slotname.bak/state slotname/

起库时间对比
#

对比不同源码流程起库速度，看看手工mv/rm加速起库到底有没有意义。

参考源码逻辑原理：

正常停库，走fsync和stat
异常停库，走fsync和stat；
有效mv，将slotname目录命名为.bak，不走unlink
无效mv，将slotname目录命名为_bak且spill文件命名为xid开头，走unlink

由于正常spill文件实在太慢，这里手工伪造slot目录和spill文件，总共50个slot，每个slot 40w个spill，总共2000w个spill来测试起库时间（用cp目录的方式要比cp文件、dd文件快很多）。

编号	测试方案	起库时间
1	正常停库；起库不做fsync和stat，不做unlink	0.1秒
2	正常停库，无效mv；起库不做fsync和stat，做unlink	11分41秒
3	异常停库，有效mv；起库做fsync和stat，不做unlink	4分35秒
4	异常停库，无效mv；起库做fsync和stat，做unlink	32分2秒
5	异常停库，rm（创建slot目录并保留state）	13分04秒

对比方案3、5，理论上当时的场景我们有效mv可以做到4分钟左右起库，rm的话13分钟左右。（这是一个粗糙的对比，恢复环境已经观察到有些东西不一样了）

PG停库逻辑和walsender阻止停库问题分析

Sat, 04 Jan 2025 00:00:00 +0000

walsender阻止停库现象
#

生产停库日志输出如下：

2024-12-06 17:00:02.036 CST,,,447560,,65693cde.6d448,1320,,2023-12-01 09:54:38 CST,,0,LOG,00000,"received fast shutdown request",,,,,,,,,"","postmaster"
2024-12-06 17:00:02.295 CST,,,447560,,65693cde.6d448,1322,,2023-12-01 09:54:38 CST,,0,LOG,00000,"background worker ""logical replication launcher"" (PID 448996) exited with exit code 1",,,,,,,,,"","postmaster"
2024-12-06 17:00:10.627 CST,,,448990,,65693ce0.6d9de,213833,,2023-12-01 09:54:40 CST,,0,LOG,00000,"checkpoint complete: wrote 426844 buffers (5.1%); 0 WAL file(s) added, 0 removed, 5 recycled; write=91.427 s, sync=0.055 s, total=91.508 s; sync files=761, longest=0.028 s, average=0.001 s; distance=2197531 kB, estimate=2680783 kB",,,,,,,,,"","checkpointer"
2024-12-06 17:00:10.628 CST,,,448990,,65693ce0.6d9de,213834,,2023-12-01 09:54:40 CST,,0,LOG,00000,"shutting down",,,,,,,,,"","checkpointer"
...
--checkpointer做完checkpoint，并处于shutting down状态，pm没有退出

--160s后pm接收到immediate shutdown，由探活脚本触发
2024-12-06 17:02:43.348 CST,,,447560,,65693cde.6d448,1323,,2023-12-01 09:54:38 CST,,0,LOG,00000,"received immediate shutdown request",,,,,,,,,"","postmaster"
2024-12-06 17:02:43.370 CST,"logicaluser","lzldb",283840,"10.33.77.159:39865",6751a2dc.454c0,7,"idle",2024-12-05 20:55:56 CST,89/847309655,0,WARNING,57P02,"terminating connection because of crash of another server process","The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.","In a moment you should be able to reconnect to the database and repeat your command.",,,,,,,"Debezium Streaming","walsender"
2024-12-06 17:02:43.370 CST,"logicaluser","lzldb",157641,"10.33.77.159:39407",67408354.267c9,7,"idle",2024-11-22 21:12:52 CST,9/3193590104,0,WARNING,57P02,"terminating connection because of crash of another server process","The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.","In a moment you should be able to reconnect to the database and repeat your command.",,,,,,,"Debezium Streaming","walsender"
2024-12-06 17:02:43.370 CST,"logicaluser","lzldb",157916,"10.33.77.159:57038",67408356.268dc,7,"idle",2024-11-22 21:12:54 CST,115/3293293502,0,WARNING,57P02,"terminating connection because of crash of another server process","The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.","In a moment you should be able to reconnect to the database and repeat your command.",,,,,,,"Debezium Streaming","walsender"
2024-12-06 17:02:43.370 CST,"repuser","",164392,"30.151.40.19:41641",66b25869.28228,3,"streaming 42D3B/1732C5F0",2024-08-07 01:07:53 CST,296/0,0,WARNING,57P02,"terminating connection because of crash of another server process","The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.","In a moment you should be able to reconnect to the database and repeat your command.",,,,,,,"standby_6666","walsender"
2024-12-06 17:02:43.371 CST,,,447560,,65693cde.6d448,1324,,2023-12-01 09:54:38 CST,,0,LOG,00000,"archiver process (PID 448994) exited with exit code 2",,,,,,,,,"","postmaster"
2024-12-06 17:02:43.371 CST,"logicaluser","lzldb",57755,"10.33.77.159:38918",67125534.e19b,7,"idle",2024-10-18 20:31:48 CST,243/902018192,0,WARNING,57P02,"terminating connection because of crash of another server process","The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.","In a moment you should be able to reconnect to the database and repeat your command.",,,,,,,"Debezium Streaming","walsender"
2024-12-06 17:02:43.372 CST,"logicaluser","lzldb",157915,"10.33.77.159:43433",67408356.268db,7,"idle",2024-11-22 21:12:54 CST,60/3248014863,0,WARNING,57P02,"terminating connection because of crash of another server process","The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.","In a moment you should be able to reconnect to the database and repeat your command.",,,,,,,"Debezium Streaming","walsender"


--pm停完
2024-12-06 17:02:57.534 CST,,,447560,,65693cde.6d448,1325,,2023-12-01 09:54:38 CST,,0,LOG,00000,"database system is shut down",,,,,,,,,"","postmaster"
2024-12-06 17:03:49.536 CST,,,211844,,6752bdf3.33b84,1,,2024-12-06 17:03:47 CST,,0,LOG,00000,"ending log output to stderr",,"Future log output will go to log destination ""csvlog"".",,,,,,,"","postmaster"

17:00:02 postmaster接到fast停库

17:00:10 checkpoint做完，checkpointer停了

17:02:43 postmaster接到immediate停库

17:02:43 1个物理链路和5个逻辑链路walsender停了

17:02:57 postmaster停了

17:03:49 postmaster接到启动任务

从以上信息可以看出，实际上还是walsender阻止了停库

停库和信号
#

在撸源码前需要先了解信号和pg中的信号注册

pg中的常用信号
#

操作系统信号：

$ kill -l
 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP
 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1
11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM
16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP
...

PG常用的信号：

-1 或-SIGHUP：挂起信号，在PG中通常是通知进程重新加载配置。
-2 或-SIGINT：中断信号（通常是Ctrl+C），在pg中同城对应取消命令。
-3或-SIGQUIT：pg中通常是强制退出die
-9 或 -SIGKILL：无条件终止信号。
-15或 -SIGTERM：终止信号，pg_terminate_backend使用的信号，pg中通常是合理退出
-10或-SIGUSR1：自定义信号
-12或-SIGUSR2：自定义信号
-17或SIGCHLD：pm进程使用的信号，一般是子进程退出后pm接受该信号触发回收子进程任务

PG中具体哪种类型的进程注册的信号含义，看各自进程源码基本都能找到。

pg_ctl 定义的停库
#

有几种方法可以关闭pg库。在底层，它们都归结为向postmaster进程发送一个信号。

signal	pg_ctl	含义
`SIGTERM`	Smart Shutdown	不允许新的连接，但允许现有会话正常结束其工作。只有在所有会话终止后，它才会关闭
`SIGINT`	Fast Shutdown	服务器不允许新的连接，并向所有现有的子进程发送SIGTERM，中止当前的事务并迅速退出。等待几乎所有子进程（有几个子进程不需要）退出，最后关闭
`SIGQUIT`	Immediate Shutdown	将向所有子进程发送SIGQUIT，并等待它们终止。如果在5秒内有子进程没有终止，它们将被发送SIGKILL

注意，pg_ctl没有发送SIGKILL（kill -9）的参数，但其实是可以直接对pm发送SIGKILL的，但肯定不推荐这么做，SIGKILL pm时pm不会对子进程、共享内存、信号量做任何处理。因为SIGQUIT pm有兜底逻辑做子进程的SIGKILL，所以SIGQUIT pm基本能保证pm能停下来。

在源码中，停库状态总共只有3种，跟停库方式相对应：

/* Startup/shutdown state */
#define			NoShutdown		0
#define			SmartShutdown	1
#define			FastShutdown	2
#define			ImmediateShutdown	3

这些状态会在停库routine源码中常见，一般通过变量Shutdown来判断当前停库状态，如：

Shutdown >= FastShutdown

pm信号
#

当pm收到对应信号时做相应的处理：

void
PostmasterMain(int argc, char *argv[])
{...
	pqsignal_pm(SIGHUP, SIGHUP_handler);	/* reread config file and have
											 * children do same */
	pqsignal_pm(SIGINT, pmdie); /* send SIGTERM and shut down */
	pqsignal_pm(SIGQUIT, pmdie);	/* send SIGQUIT and die */
	pqsignal_pm(SIGTERM, pmdie);	/* wait for children and shut down */
	pqsignal_pm(SIGALRM, SIG_IGN);	/* ignored */
	pqsignal_pm(SIGPIPE, SIG_IGN);	/* ignored */
	pqsignal_pm(SIGUSR1, sigusr1_handler);	/* message from child process */
	pqsignal_pm(SIGUSR2, dummy_handler);	/* unused, reserve for children */
	pqsignal_pm(SIGCHLD, reaper);	/* handle child termination */

pmdie：停库的三种信号会调用pmdie函数，pmdie是停库的关键函数，下面会重点分析。
reaper：停库时会处理子进程退出清理，所以在停库的逻辑中。子进程退出会给pm发生SIGCHLD信号，然后进入reaper清理子进程，每种子进程的清理也有自己的逻辑，比如checkpointer进程的正常退出会判断archiver和walsender是否完成了各自的任务。
sigusr1、sigusr2：sigusr1_handler是SIGUSER1的标准routine，每种子进程对于SIGUSR1的处理行为各不同；SIGUSR2完全是子进程自定义行为了，有些子进程没有注册这个信号。

walsender的信号
#

子进程fork出来时，首先就要注册信号。

WalSndSignals注册walsender进程的信号：

/* Set up signal handlers */
void
WalSndSignals(void)
{
	/* Set up signal handlers */
	pqsignal(SIGHUP, SignalHandlerForConfigReload);
	pqsignal(SIGINT, StatementCancelHandler);	/* query cancel */
	pqsignal(SIGTERM, die);		/* request shutdown */
	pqsignal(SIGQUIT, quickdie);	/* hard crash time */
	InitializeTimeouts();		/* establishes SIGALRM handler */
	pqsignal(SIGPIPE, SIG_IGN);
	pqsignal(SIGUSR1, procsignal_sigusr1_handler);
	pqsignal(SIGUSR2, WalSndLastCycleHandler);	/* request a last cycle and
												 * shutdown */
}

要注意SIGUSR1和SIGUSR2

checkpointer的信号
#

CheckpointerMain注册checkpointer的信号：

void
CheckpointerMain(void)
{
...
 //checkpointer会屏蔽SIGTERM，真正的停止是SIGUSR2
	pqsignal(SIGHUP, SignalHandlerForConfigReload);
	pqsignal(SIGINT, ReqCheckpointHandler); /* request checkpoint */
	pqsignal(SIGTERM, SIG_IGN); /* ignore SIGTERM */
	pqsignal(SIGQUIT, SignalHandlerForCrashExit);
	pqsignal(SIGALRM, SIG_IGN);
	pqsignal(SIGPIPE, SIG_IGN);
	pqsignal(SIGUSR1, procsignal_sigusr1_handler);
	pqsignal(SIGUSR2, SignalHandlerForShutdownRequest);

要注意SIGUSR1和SIGUSR2，同时要注意checkpointer是没有注册SIGTERM的

停库源码分析
#

pm信号处理和状态机
#

pmdie函数用于处理不同的postmaster signals，包括子进程给pm发送的SIGCHILD和pg_ctl发送的停库信号。pm信号处理主体逻辑是根据signal转换pmState状态机状态，并进入状态机PostmasterStateMachine处理。

pmdie：

/*
 * pmdie -- signal handler for processing various postmaster signals.
 */
static void
pmdie(SIGNAL_ARGS)
{
	int			save_errno = errno;

...

	switch (postgres_signal_arg)
	{
		case SIGTERM://Smart Shutdown
			...
			if (pmState == PM_RUN)
				connsAllowed = ALLOW_SUPERUSER_CONNS;
			...
 //smart shutdown没有处理pmstate，直接交给状态机处理
			//此时正常情况pmState = PM_RUN
			PostmasterStateMachine();
			break;

		case SIGINT://Fast Shutdown
			...
			else if (pmState == PM_RUN ||
					 pmState == PM_HOT_STANDBY)
			{
				/* Report that we're about to zap live client sessions */
				ereport(LOG,
						(errmsg("aborting any active transactions")));
				pmState = PM_STOP_BACKENDS;
			}

			//Fast Shutdown将pmstate转换为PM_STOP_BACKENDS
 //然后交给状态机处理
			PostmasterStateMachine();
			break;

		case SIGQUIT://Immediate Shutdown
			...

			TerminateChildren(SIGQUIT);//abort all children with SIGQUIT, wait for them to exit
			pmState = PM_WAIT_BACKENDS;

			/* set stopwatch for them to die */
			AbortStartTime = time(NULL);

 //Immediate Shutdown将pmstate转换为PM_WAIT_BACKENDS
 //进入状态机前处理也会children
 //先用SIGQUIT中断children，等待他们退出
 //然后用SIGKILL处理还在的children
 //最后非一致性退出
			PostmasterStateMachine();
			break;
	}
...
}

在进入状态机处理函数前先看下postmaster的状态有哪些：

typedef enum
{
	PM_INIT,					/* postmaster starting */
	PM_STARTUP,					/* waiting for startup subprocess */
	PM_RECOVERY,				/* in archive recovery mode */
	PM_HOT_STANDBY,				/* in hot standby mode */
	PM_RUN,						/* normal "database is alive" state */
	PM_STOP_BACKENDS,			/* need to stop remaining backends */
	PM_WAIT_BACKENDS,			/* waiting for live backends to exit */
	PM_SHUTDOWN,				/* waiting for checkpointer to do shutdown
								 * ckpt */
	PM_SHUTDOWN_2,				/* waiting for archiver and walsenders to
								 * finish */
	PM_WAIT_DEAD_END,			/* waiting for dead_end children to exit */
	PM_NO_CHILDREN				/* all important children have exited */
} PMState;

由于正常都是running态关库，这里只需要关注PM_RUN以下的状态即可。

PostmasterStateMachine的执行函数实际上有顺序逻辑：

/*
 * Advance the postmaster's state machine and take actions as appropriate
 *
 * This is common code for pmdie(), reaper() and sigusr1_handler(), which
 * receive the signals that might mean we need to change state.
 */
static void
PostmasterStateMachine(void)
{
	//smart shutdown，此时的pmState应是PM_RUN
	if (pmState == PM_RUN || pmState == PM_HOT_STANDBY)
	{
	...

		if (connsAllowed == ALLOW_NO_CONNS)
		{
 //当所有normal backend都退出后，pmState转换PM_STOP_BACKENDS
			if (CountChildren(BACKEND_TYPE_NORMAL) == 0)
				pmState = PM_STOP_BACKENDS;
		}
	}

 //PM_STOP_BACKENDS会中止一些比较核心的子进程，有些子进程会继续运行
 //autovacuum，bgwriter，walwriter，startup，walreiver会停止
 //walsender，checkpointer, archiver, stats, and syslogger会继续跑
 //smart shutdown后段会进入此逻辑，fast shutdown直接进入此逻辑
	if (pmState == PM_STOP_BACKENDS)
	{
		...		
		//注意walsender这句话！
		/* Signal all backend children except walsenders */
		SignalSomeChildren(SIGTERM,
						 BACKEND_TYPE_ALL - BACKEND_TYPE_WALSND);
		/* and the autovac launcher too */
		if (AutoVacPID != 0)
			signal_child(AutoVacPID, SIGTERM);
		/* and the bgwriter too */
		if (BgWriterPID != 0)
			signal_child(BgWriterPID, SIGTERM);
		/* and the walwriter too */
		if (WalWriterPID != 0)
			signal_child(WalWriterPID, SIGTERM);
		/* If we're in recovery, also stop startup and walreceiver procs */
		if (StartupPID != 0)
			signal_child(StartupPID, SIGTERM);
		if (WalReceiverPID != 0)
			signal_child(WalReceiverPID, SIGTERM);
		/* checkpointer, archiver, stats, and syslogger may continue for now */

 //将pmState从PM_STOP_BACKENDS转换为PM_WAIT_BACKEND
 //PM_WAIT_BACKEND表示等待backend退出
		pmState = PM_WAIT_BACKENDS;
	}

	/*
	 * If we are in a state-machine state that implies waiting for backends to
	 * exit, see if they're all gone, and change state if so.
	 */
 //
 //smart shutdown,fast shutdown后段会进入此逻辑
 //immediate shutdown进入状态机处理时，直接进入此逻辑
	if (pmState == PM_WAIT_BACKENDS)
	{
 //crash recovery和immediate shutdown时，checkpointer需要妥善退出
 //archiver, stats, and syslogger不需要处理，因为他们没有连到shared memory
 //Walsenders也不需要处理，它将在checkpoint记录写入之后退出，就像archiver进程一样
		if (CountChildren(BACKEND_TYPE_ALL - BACKEND_TYPE_WALSND) == 0 &&
			StartupPID == 0 &&
			WalReceiverPID == 0 &&
			BgWriterPID == 0 &&
			(CheckpointerPID == 0 ||
			 (!FatalError && Shutdown < ImmediateShutdown)) &&
			WalWriterPID == 0 &&
			AutoVacPID == 0)
		{
			if (Shutdown >= ImmediateShutdown || FatalError)
			{
				//ImmediateShutdown会等待dead end进程结束
				pmState = PM_WAIT_DEAD_END;

				/*
				 * We already SIGQUIT'd the archiver and stats processes, if
				 * any, when we started immediate shutdown or entered
				 * FatalError state.
				 */
			}
			else
			{
 //smart，fast shutdown走此逻辑
 //常规子进程都退出了，此时该通知checkpointer做shutdown checkpoint
				Assert(Shutdown > NoShutdown);
				//如果checkpointer进程没有，就启动
				if (CheckpointerPID == 0)
					CheckpointerPID = StartCheckpointer();
				/* And tell it to shut down */
				if (CheckpointerPID != 0)
				{
 //向Checkpointer发送SIGUSR2
 //pmState = PM_SHUTDOWN
					signal_child(CheckpointerPID, SIGUSR2);
					pmState = PM_SHUTDOWN;
				}
				else
				{
 //没有启动起来Checkpointer是一个比较严重的问题
					FatalError = true;
					pmState = PM_WAIT_DEAD_END;

					/* Kill the walsenders, archiver and stats collector too */ 
 //注释说kill walsender，实际上根本没有；至少不是SIGQUIT去停的
					SignalChildren(SIGQUIT);
					if (PgArchPID != 0)
						signal_child(PgArchPID, SIGQUIT);
					if (PgStatPID != 0)
						signal_child(PgStatPID, SIGQUIT);
				}
			}
		}
	}
	
 //pmdie函数和状态机函数不会制造PM_SHUTDOWN_2这个状态，但是reaper会
 //reaper在处理checkpointer的退出时，会设置pmState = PM_SHUTDOWN_2；当然在reaper函数最后会进入状态机函数，也就是这里
	if (pmState == PM_SHUTDOWN_2)
	{
		/*
		 * PM_SHUTDOWN_2 state ends when there's no other children than
		 * dead_end children left. There shouldn't be any regular backends
		 * left by now anyway; what we're really waiting for is walsenders and
		 * archiver.
		 */
 //PM_SHUTDOWN_2本质上是等待walsender和archiver
 //只是更改了pmState状态
		if (PgArchPID == 0 && CountChildren(BACKEND_TYPE_ALL) == 0)
		{
			pmState = PM_WAIT_DEAD_END;
		}
	}

	if (pmState == PM_WAIT_DEAD_END)
	{
 //PM_WAIT_DEAD_END表示BackendList已经完全清空
		if (dlist_is_empty(&BackendList) &&
			PgArchPID == 0 && PgStatPID == 0)
		{
			/* These other guys should be dead already */
			Assert(StartupPID == 0);
			Assert(WalReceiverPID == 0);
			Assert(BgWriterPID == 0);
			Assert(CheckpointerPID == 0);
			Assert(WalWriterPID == 0);
			Assert(AutoVacPID == 0);
			/* syslogger is not considered here */
			pmState = PM_NO_CHILDREN;
		}
	}

 //PM_NO_CHILDREN是停库的最后一个状态，表示可以正常停库了
	if (Shutdown > NoShutdown && pmState == PM_NO_CHILDREN)
	{
		if (FatalError)
		{
			ereport(LOG, (errmsg("abnormal database system shutdown")));
 //异常退出pm
			ExitPostmaster(1);
		}
		...

		 	//正常退出pm
			ExitPostmaster(0);
		}
	}
	...
}

reaper是进程回收函数，子进程退出后会发送pm SIGCHLD信号，pm通过reaper函数清理进程。如backend、startup、checkpointer等进程都有自己的清理流程。

这里只看checkpointer的清理，另外reaper中没有关于walsender的清理逻辑：

		if (pid == CheckpointerPID)
		{
			CheckpointerPID = 0;
 //Checkpointer进程是正常退出，且pmState为PM_SHUTDOWN:等待checkpoint完成态
			if (EXIT_STATUS_0(exitstatus) && pmState == PM_SHUTDOWN)
			{
				/*
				 * OK, we saw normal exit of the checkpointer after it's been
				 * told to shut down. We expect that it wrote a shutdown
				 * checkpoint. (If for some reason it didn't, recovery will
				 * occur on next postmaster start.)
				 *
				 * At this point we should have no normal backend children
				 * left (else we'd not be in PM_SHUTDOWN state) but we might
				 * have dead_end children to wait for.
				 *
				 * If we have an archiver subprocess, tell it to do a last
				 * archive cycle and quit. Likewise, if we have walsender
				 * processes, tell them to send any remaining WAL and quit.
				 */
				Assert(Shutdown > NoShutdown);

				//最后一次唤醒pgarch
				if (PgArchPID != 0)
					signal_child(PgArchPID, SIGUSR2); //pgarch SIGUSR2=pgarch_waken_stop

 //最后一次唤醒walsender
				SignalChildren(SIGUSR2);//walsender SIGUSR2=WalSndLastCycleHandler
 
 //这里设置了PM_SHUTDOWN_2
 //此时Checkpointer正常退出完成了，这里应该等pgarch和walsender最后一个任务完成
 //即PM_SHUTDOWN_2态
 pmState = PM_SHUTDOWN_2;

				...
			}
			else
			{
 //checkpointer进程异常退出都认为是crash
				HandleChildCrash(pid, exitstatus,
								 _("checkpointer process"));
			}

			continue;
		}
...
	//最后reaper还是会进入状态机函数
	PostmasterStateMachine();

...
}

checkpointer和walsender进程的退出
#

checkpointer主循环处理请求和关闭进程：

void
CheckpointerMain(void)
{
	/*
	 * Loop forever
	 */
	for (;;)
	{
		bool		do_checkpoint = false;
		int			flags = 0;
		pg_time_t	now;
		int			elapsed_secs;
		int			cur_timeout;

		/* Clear any already-pending wakeups */
		ResetLatch(MyLatch);

		/*
		 * Process any requests or signals received recently.
		 */
 //处理近期的同步请求和信号
		AbsorbSyncRequests();
		HandleCheckpointerInterrupts();

checkpointer关闭函数：

/*
 * Process any new interrupts.
 */
static void
HandleCheckpointerInterrupts(void)
{
 ...
	if (ShutdownRequestPending)
	{
		/*
		 * From here on, elog(ERROR) should end with exit(1), not send control
		 * back to the sigsetjmp block above
		 */
		ExitOnAnyError = true;
		
		ShutdownXLOG(0, 0);//这里会写shutdown checkpoint 
		
		proc_exit(0);//正常退出态为0
	}
}

checkpointer的退出需要等待ShutdownXLOG完成。

ShutdownXLOG：

/*
 * This must be called ONCE during postmaster or standalone-backend shutdown
 */
void
ShutdownXLOG(int code, Datum arg)
{
...

	//这里有个checkpointer的shutting down的日志，这个日志一般都会看到
	ereport(IsPostmasterEnvironment ? LOG : NOTICE,
			(errmsg("shutting down")));

	/*
	 * Signal walsenders to move to stopping state.
	 */
 //walsender初始化stopping
	WalSndInitStopping();

 //等待所有walsender处于stopping状态
	WalSndWaitStopping();

	if (RecoveryInProgress())
		CreateRestartPoint(CHECKPOINT_IS_SHUTDOWN | CHECKPOINT_IMMEDIATE);
	else
	{
		/*
		 * If archiving is enabled, rotate the last XLOG file so that all the
		 * remaining records are archived (postmaster wakes up the archiver
		 * process one more time at the end of shutdown). The checkpoint
		 * record will go to the next XLOG file and won't be archived (yet).
		 */
		if (XLogArchivingActive() && XLogArchiveCommandSet())
			RequestXLogSwitch(false);
		//这里就是shutdown checkpoint的创建函数
		CreateCheckPoint(CHECKPOINT_IS_SHUTDOWN | CHECKPOINT_IMMEDIATE);
	}
	ShutdownCLOG();
	ShutdownCommitTs();
	ShutdownSUBTRANS();
	ShutdownMultiXact();
}

checkpointer通知所有walsender开始stopping：

/*
 * Signal all walsenders to move to stopping state.
 *
 * This will trigger walsenders to move to a state where no further WAL can be
 * generated. See this file's header for details.
 */
void
WalSndInitStopping(void)
{
	int			i;

	for (i = 0; i < max_wal_senders; i++)
	{
		WalSnd	 *walsnd = &WalSndCtl->walsnds[i];
		pid_t		pid;

		SpinLockAcquire(&walsnd->mutex);
		pid = walsnd->pid;
		SpinLockRelease(&walsnd->mutex);

		if (pid == 0)
			continue;

		SendProcSignal(pid, PROCSIG_WALSND_INIT_STOPPING, InvalidBackendId);
	}
}

walsender通过SendProcSignal函数收到信号，信号为SIGUSR1

/*
 * SendProcSignal
 *		Send a signal to a Postgres process
 *
 * Providing backendId is optional, but it will speed up the operation.
 *
 * On success (a signal was sent), zero is returned.
 * On error, -1 is returned, and errno is set (typically to ESRCH or EPERM).
 *
 * Not to be confused with ProcSendSignal
 */
int
SendProcSignal(pid_t pid, ProcSignalReason reason, BackendId backendId)
{
	else
	{
		/*
		 * BackendId not provided, so search the array using pid. We search
		 * the array back to front so as to reduce search overhead. Passing
		 * InvalidBackendId means that the target is most likely an auxiliary
		 * process, which will have a slot near the end of the array.
		 */
		int			i;

		for (i = NumProcSignalSlots - 1; i >= 0; i--)
		{
			slot = &ProcSignal->psh_slot[i];

			if (slot->pss_pid == pid)
			{
				/* the above note about race conditions applies here too */

				/* Atomically set the proper flag */
				slot->pss_signalFlags[reason] = true;
				/* Send signal */
				return kill(pid, SIGUSR1);
			}
		}
	}

	errno = ESRCH;
	return -1;
}

walsender中SIGUSR1的注册为如下：

	pqsignal(SIGUSR1, procsignal_sigusr1_handler);
	pqsignal(SIGUSR2, WalSndLastCycleHandler);	/* request a last cycle and
												 * shutdown */

sigusr1根据信号的reason来分类处理

/*
 * procsignal_sigusr1_handler - handle SIGUSR1 signal.
 */
void
procsignal_sigusr1_handler(SIGNAL_ARGS)
{
...
	if (CheckProcSignal(PROCSIG_WALSND_INIT_STOPPING))
		HandleWalSndInitStopping();
...
}

处理PROCSIG_WALSND_INIT_STOPPING的函数为HandleWalSndInitStopping

/*
 * Handle PROCSIG_WALSND_INIT_STOPPING signal.
 */
void
HandleWalSndInitStopping(void)
{
	Assert(am_walsender);

	/*
	 * If replication has not yet started, die like with SIGTERM. If
	 * replication is active, only set a flag and wake up the main loop. It
	 * will send any outstanding WAL, wait for it to be replicated to the
	 * standby, and then exit gracefully.
	 */
	if (!replication_active)
		kill(MyProcPid, SIGTERM);
	else
		got_STOPPING = true;//如果walsender是active的，initstopping函数只会设置状态，让主循环去处理
}

这个注释中的main loop有点意义不明，walsender有主循环ServerLoop，但实际上只有WalSndWaitForWal中的循环才有关于got_STOPPING的判断。

WalSndWaitForWal函数是walsender等待新的wal日志的主循环函数。由于wal record生成之初还在内存中，walwriter会根据一定的条件flush，不是随时都flush。WalSndWaitForWal函数通过对比当前sent的LSN和flushed的LSN，以判断是否需要send新的wal日志。换句话说，没有flush的wal不会传递，flush过的wal才会传给下游。

WalSndWaitForWal关于stopping的代码段：

/*
 * Wait till WAL < loc is flushed to disk so it can be safely sent to client.
 *
 * Returns end LSN of flushed WAL. Normally this will be >= loc, but
 * if we detect a shutdown request (either from postmaster or client)
 * we will return early, so caller must always check.
 */
static XLogRecPtr
WalSndWaitForWal(XLogRecPtr loc)
{
 ...
	for (;;)
	{
 ...
 //收到got_STOPPING信息后，做一次flush wal操作
 //这是必须的！因为walwriter进程在此时可能已经关闭了，可能还有wal没有刷盘
		if (got_STOPPING)
			XLogBackgroundFlush();

		/* Update our idea of the currently flushed position. */
		if (!RecoveryInProgress())
			RecentFlushPtr = GetFlushRecPtr();
		else
			RecentFlushPtr = GetXLogReplayRecPtr(NULL);

 //跳出for循环
 //有了新的RecentFlushPtr位置后，还需要send
		if (got_STOPPING)
			break;
 ...
	}
	/* reactivate latch so WalSndLoop knows to continue */
	SetLatch(MyLatch);
	return RecentFlushPtr;
}

回到walsender主循环：WalSndLoop(XLogSendLogical);

/* Main loop of walsender process that streams the WAL over Copy messages. */
static void
WalSndLoop(WalSndSendDataCallback send_data)
{
...
	for (;;)
	{
		/* Clear any already-pending wakeups */
		ResetLatch(MyLatch);
		...

		//处理下游返回的信息
		ProcessRepliesIfAny();

		/*
		 * If we have received CopyDone from the client, sent CopyDone
		 * ourselves, and the output buffer is empty, it's time to exit
		 * streaming.
		 */
 //streaming做完就退出循环
		if (streamingDoneReceiving && streamingDoneSending &&
			!pq_is_send_pending())
			break;

 //output buffer是否还有pending的data，有就send
		if (!pq_is_send_pending())
			send_data();
		else
			WalSndCaughtUp = false;

		/* Try to flush pending output to the client */
		if (pq_flush_if_writable() != 0)
			WalSndShutdown();//下游不可写入，下游端关闭了，正常关闭walsender，退出码0

		/* If nothing remains to be sent right now ... */
		if (WalSndCaughtUp && !pq_is_send_pending())
		{
			/*
			 * If we're in catchup state, move to streaming. This is an
			 * important state change for users to know about, since before
			 * this point data loss might occur if the primary dies and we
			 * need to failover to the standby. The state change is also
			 * important for synchronous replication, since commits that
			 * started to wait at that point might wait for some time.
			 */
 //数据已经传完了，但是仍然要发送提交信息
			if (MyWalSnd->state == WALSNDSTATE_CATCHUP)
			{
				ereport(DEBUG1,
						(errmsg("\"%s\" has now caught up with upstream server",
								application_name)));
				WalSndSetState(WALSNDSTATE_STREAMING);
			}

 //收到SIGUSR2，表示shutdown checkpoint做完了。
 //把shutdown checkpoint record发出去，等待完成再退出
			if (got_SIGUSR2)
				WalSndDone(send_data);//退出码0
		}
		
		...
	}
}

走远了，回到checkpointer的ShutdownXLOG逻辑，以上只是在分析WalSndInitStopping()。这个信号发送给walsender后，会执行WalSndWaitStopping以等待walsender。

只要有walsender没有退出，这里就是一个死循环不会return：

/*
 * Wait that all the WAL senders have quit or reached the stopping state. This
 * is used by the checkpointer to control when the shutdown checkpoint can
 * safely be performed.
 */
void
WalSndWaitStopping(void)
{
	for (;;)
	{
		int			i;
		bool		all_stopped = true;

		for (i = 0; i < max_wal_senders; i++)
		{
			WalSnd	 *walsnd = &WalSndCtl->walsnds[i];

			SpinLockAcquire(&walsnd->mutex);

			if (walsnd->pid == 0)
			{
				SpinLockRelease(&walsnd->mutex);
				continue;
			}

			if (walsnd->state != WALSNDSTATE_STOPPING)
			{
				all_stopped = false;
				SpinLockRelease(&walsnd->mutex);
				break;
			}
			SpinLockRelease(&walsnd->mutex);
		}

		/* safe to leave if confirmation is done for all WAL senders */
		if (all_stopped)
			return;

		pg_usleep(10000L);		/* wait for 10 msec */
	}
}

最后结合walsender.c的注释：

 * If the server is shut down, checkpointer sends us
 * PROCSIG_WALSND_INIT_STOPPING after all regular backends have exited. If
 * the backend is idle or runs an SQL query this causes the backend to
 * shutdown, if logical replication is in progress all existing WAL records
 * are processed followed by a shutdown. Otherwise this causes the walsender
 * to switch to the "stopping" state. In this state, the walsender will reject
 * any further replication commands. The checkpointer begins the shutdown
 * checkpoint once all walsenders are confirmed as stopping. When the shutdown
 * checkpoint finishes, the postmaster sends us SIGUSR2. This instructs
 * walsender to send any outstanding WAL, including the shutdown checkpoint
 * record, wait for it to be replicated to the standby, and then exit.

当所有的常规backend都退出后，checkpointer会发送PROCSIG_WALSND_INIT_STOPPING给walsender
walsender可能进入stopping状态
当所有walsender都进入stopping状态后，checkpointer才会做shutdown checkpoint
当shutdown checkpoint完成后，pm发送SIGUSR2给walsender，walsender会发送额外的wal，包括shutdown checkpoint记录本身，并等待standby完成再退出

停库流程图
#

撸完源码好像懂了又好像没懂，需要一个停库流程图来理清思路。汇总fast shutdown停库流程图：

（高清大图：https://www.processon.com/view/link/6778a73a04a8344b9502637a）

PG通过信号、各进程主循环、PM状态机、pmdie进程回收函数来共同管理停库逻辑
还需注意：信号本身是异步的。如果需要等待目标进程处理信号的结果，通常需要通过其他同步机制（如管道、信号量、共享内存等）来实现。PG主要通过进程依赖和进程是否正常退出来判断信号是否被正确处理。
pgarch、walsender被认为是同一类进程，与其他进程（walwriter、bgwriter）等处理不同。pgarch、walsender需要额外做“最后一个任务”这件事。“最后一个任务”的信号通常定义为SIGUSR2
checkpointer的正常退出依赖pgarch、walsender的正常退出
pgarch的最后一个任务是最后一次归档。所以归档会影响停库
walsender的倒数第二个任务是传递最后的wal，最后一个任务是传递checkpoint shutdown信息。且这些任务需要下游回复消息，所以walsender会影响停库。

测试复现
#

测试：复现walsender阻止停库
#

在fast stop停库后，walsender可能阻止停库。

测试了各自场景去复现walsender阻止停库，目前来看以下条件同时满足比较容易触发停库异常：

发布订阅一个walsender
dts一个walsender
大量子事务导致复制槽spill中

这个三合一场景不代表唯一场景，只是测试了很多场景这个好复现一点。

--复现命令（不是特别稳定的复现）
1.建表
--pg
create table lzlpg(id bigserial primary key,a char(2000),b char(2000),c char(2000));
--oracle
create table lzl.lzloracle(id number primary key ,a char(2000),b char(2000),c char(2000)) tablespace FADATA;
2.搭建2条逻辑链路（1条发布订阅，一条dts到oracle）

3.改小logical_decoding_work_mem
logical_decoding_work_mem=1MB

4.写入大量数据（推荐子事务spill）
--一次insert一行，每个insert一个子事务
echo "begin;">subtx.sql
for i in {1..500000}
do
 echo "savepoint p$i;">>subtx.sql
 echo "insert into lzlpg(column1,column2,column3) select 'a','b','c';">>subtx.sql
done

nohup psql -d lzl -f subtx.sql &

5.没写入完就停库
pg_ctl stop -D $PGDATA -m fast

此时fast停库，数据库处于一个非完整停库状态，如下:

~/lzl/slot]$ ps -axjf|grep 110402
150696 64964 64961 146782 pts/42 64961 S+ 6001 0:00 \_ grep --color=auto 110402
 1 110402 110402 110402 ? -1 Ss 6001 0:00 /myhost/postgres/base/rasesql1.5.6/bin/postgres -D /myhost/pg8094/data
110402 110599 110599 110599 ? -1 Ss 6001 0:00 \_ postgres: lzlpg: logger 
110402 117803 117803 117803 ? -1 Ss 6001 0:00 \_ postgres: lzlpg: checkpointer 
110402 117807 117807 117807 ? -1 Ss 6001 0:00 \_ postgres: lzlpg: stats collector 
110402 118563 118563 118563 ? -1 Rs 6001 3:29 \_ postgres: lzlpg: walsender lzl 127.0.0.1(62971) idle
110402 222918 222918 222918 ? -1 Rs 6001 2:59 \_ postgres: lzlpg: walsender dtssync 30.181.46.203(57218) idle

walsender、checkpointer、postmaster都在，logger、stats也没有退出。

控制文件的状态为in production：生产运行中，说明checkpoint做的本地shutdown checkpoint没有做完：

~/lzl/slot]$ pg_controldata|grep -i state
Database cluster state: in production

checkpointer堆栈：

pstack 117803
#0 0x00002b879fe0b983 in __select_nocancel () from /lib64/libc.so.6
#1 0x00000000008fd04a in pg_usleep (microsec=microsec@entry=10000) at pgsleep.c:56
#2 0x00000000007610c8 in WalSndWaitStopping () at walsender.c:3209
#3 0x000000000051fa86 in ShutdownXLOG (code=code@entry=0, arg=arg@entry=0) at xlog.c:8596
#4 0x00000000007215ff in HandleCheckpointerInterrupts () at checkpointer.c:566
#5 CheckpointerMain () at checkpointer.c:343
...

此时的checkpointer堵在WalSndWaitStopping函数，代表checkpointer在等待walsender进程进入stopping状态。

此时的walsender堆栈：

#0 0x00000000007484fb in ReorderBufferLargestTXN (rb=<optimized out>) at reorderbuffer.c:2345
#1 ReorderBufferCheckMemoryLimit (rb=0x2b8808b94118) at reorderbuffer.c:2390
#2 ReorderBufferQueueChange (rb=0x2b8808b94118, xid=<optimized out>, lsn=1676456602544, change=change@entry=0x2b87a229f408) at reorderbuffer.c:649
#3 0x000000000073ec99 in DecodeTruncate (buf=<optimized out>, buf=<optimized out>, ctx=<optimized out>) at decode.c:872
#4 DecodeHeapOp (buf=0x7ffda7d35180, ctx=0x2b87a224b118) at decode.c:455
#5 LogicalDecodingProcessRecord (ctx=0x2b87a224b118, record=<optimized out>) at decode.c:126
#6 0x000000000075f502 in XLogSendLogical () at walsender.c:2886
#7 0x0000000000761822 in WalSndLoop (send_data=send_data@entry=0x75f4c0 <XLogSendLogical>) at walsender.c:2287
...

walsender堵在事务溢出函数。（为什么堵还没有搞清楚！！！）

checkpointer进程阻塞在WalSndWaitStopping函数：

/*
 * Wait that all the WAL senders have quit or reached the stopping state. This
 * is used by the checkpointer to control when the shutdown checkpoint can
 * safely be performed.
 */
void
WalSndWaitStopping(void)
{
	for (;;)
	{
		int			i;
		bool		all_stopped = true;

		for (i = 0; i < max_wal_senders; i++)
		{
			WalSnd	 *walsnd = &WalSndCtl->walsnds[i];

			SpinLockAcquire(&walsnd->mutex);

			if (walsnd->pid == 0)
			{
				SpinLockRelease(&walsnd->mutex);
				continue;
			}

			if (walsnd->state != WALSNDSTATE_STOPPING)
			{
				all_stopped = false;
				SpinLockRelease(&walsnd->mutex);
				break;
			}
			SpinLockRelease(&walsnd->mutex);
		}

		/* safe to leave if confirmation is done for all WAL senders */
		if (all_stopped)
			return;

		pg_usleep(10000L);		/* wait for 10 msec */
	}
}

从代码和堆栈来看肯定是进入了条件walsnd->state != WALSNDSTATE_STOPPIN才会出现跳不出死循环。

测试：停库中间态的处理方案
#

以上是个尴尬的停库停一半的状态，除了kill -9 外，实际上还有其他好办法可以一致性停库。

方案1：关闭下游进程
方案2：发送SIGTERM给walsender

方案1测试：

由于下游退出后，walsender也会跟随退出：

static void
ProcessRepliesIfAny(void)
{...
				/*
				 * 'X' means that the standby is closing down the socket.
				 */
			case 'X':
				proc_exit(0);

如果是发布订阅，在订阅端执行以下命令即可，即使是上游处于停库中间态也会将walsender退出。

\c lzldb
alter SUBSCRIPTION sub_lzl disable;

不过这依赖下游自身的处理，我们也不能快速地关闭dts等同步工具的下游接收进程。

方案2测试：

由于walsender注册了SIGTERM信号，库运行时跑的select pg_terminate_backend($walsender_pid)命令也是发送SIGTERM给walsender，所以理论上只要发送SIGTERM给walsender应该可以处理这个问题，而不必发送kill -9。

命令如下：

kill -SIGTERM 62834
#同 kill -15 62834
#同 kill 62834

正常kill后pm等进程全部退出。

查看控制文件和wal日志信息以确认是否是一致性停库：

1.pg_controldata的数据库state从in production转换为shut down一致性停库：

$ pg_controldata|grep -i state
Database cluster state: shut down

2.wal日志的最后一个record是CHECKPOINT_SHUTDOWN：

pg_waldump 000000010000018600000012|tail -1
pg_waldump: fatal: error in WAL record at 186/915D7920: invalid record length at 186/915D7998: wanted 24, got 0
rmgr: XLOG len (rec/tot): 114/ 114, tx: 0, lsn: 186/915D7920, prev 186/915D78A8, desc: CHECKPOINT_SHUTDOWN redo 186/915D7920; tli 1; prev tli 1; fpw true; xid 0:13431045; oid 3808147; multi 3; offset 6; oldest xid 485 in DB 1; oldest multi 1 in DB 1; oldest/newest commit timestamp xid: 494/13431044; oldest running xid 0; shutdown

测试：复现只有主库有CHECKPOINT_SHUTDOWN
#

生产现场有个现象是，本地wal有shutdown checkpoint但是从库没有。生产是在半停库状态时做的immediate stop，随后启动库没有启动起来。

当时主从的wal日志最后2条record类似如下：

#主库wal：
CHECKPOINT_ONLINE
CHECKPOINT_SHUTDOWN
#从库wal：
CHECKPOINT_ONLINE

复现命令：

## 1. 先复现walsender阻止停库
略
## 2. 查看最后一条wal record
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 188/307ABE00, prev 188/307ABDC8, desc: RUNNING_XACTS nextXid 13432445 latestCompletedXid 13432444 oldestRunningXid 13432445
## 3. pg_ctl stop -D $PGDATA -m i
## 4. 查看最后一条wal record
不变，同2
## 5. pg_ctl start -D $PGDATA
## 6. 查看最后两条wal record
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 188/307ABE00, prev 188/307ABDC8, desc: RUNNING_XACTS nextXid 13432445 latestCompletedXid 13432444 oldestRunningXid 13432445 #同2
rmgr: XLOG len (rec/tot): 114/ 114, tx: 0, lsn: 188/307ABE38, prev 188/307ABE00, desc: CHECKPOINT_SHUTDOWN redo 188/307ABE38; tli 1; prev tli 1; fpw true; xid 0:13432445; oid 3832732; multi 3; offset 6; oldest xid 485 in DB 1; oldest multi 1 in DB 1; oldest/newest commit timestamp xid: 494/13432444; oldest running xid 0; shutdown #出现CHECKPOINT_SHUTDOWN

从该复现来看，CHECKPOINT_SHUTDOWN其实是起库的时候做！

这与现场的动作一致：1.fast停库没停下来 2.immediate停库 3.起库没启起来。

疑问1：起库什么时候做的CHECKPOINT_SHUTDOWN？

疑问2：CHECKPOINT_ONLINE的触发时机？复现表象来看，偶现fast shutdown出现最后一个wal record为CHECKPOINT_ONLINE

疑问1分析：

起库做shutdown checkpoint，这很容易联想到是startup进程做的。由于之前分析过startup进程的起库流程，我们可以直接定位到函数StartupXLOG：

/*
 * This must be called ONCE during postmaster or standalone-backend startup
 */
void
StartupXLOG(void)
{...
	if (InRecovery) //因为是shutdown停库所以会做实例恢复
	{
		/*
		 * Perform a checkpoint to update all our recovery activity to disk.
		 *
		 * Note that we write a shutdown checkpoint rather than an on-line
		 * one. This is not particularly critical, but since we may be
		 * assigning a new TLI, using a shutdown checkpoint allows us to have
		 * the rule that TLI only changes in shutdown checkpoints, which
		 * allows some extra error checking in xlog_redo.
		 *
		 * In fast promotion, only create a lightweight end-of-recovery record
		 * instead of a full checkpoint. A checkpoint is requested later,
		 * after we're fully out of recovery mode and already accepting
		 * queries.
		 */
		if (bgwriterLaunched) //这个if明显是从库流复制用的逻辑
		{...
		}
		else //主库的startup会走到这里
			CreateCheckPoint(CHECKPOINT_END_OF_RECOVERY | CHECKPOINT_IMMEDIATE);
	}

做shutdown checkpoint是故意的，主要是为了TLI逻辑的代码健壮性
只要是非一致性停库，起库的时候就会做shutdown checkpoint

所以，直接-m i暴力停库再起库，也会出现CHECKPOINT_SHUTDOWN，自测。

疑问2分析：

多次测试，偶现，推测是刚好停库前满足checkpoint条件触发了一次online checkpoint，纯属巧合。

联想数据库停库失败后，无论是脚本、HA还是人工介入都有可能做暴力停库，所以停库前推荐至少做一次checkpoint。

测试：归档对停库的影响
#

在分析停库代码的时候，还发现checkpointer进程退出后，reaper checkpointer会发送SIGUSR2给pgarch让其最后一次归档并退出：

static void
reaper(SIGNAL_ARGS)
{...
		if (pid == CheckpointerPID)
		{
			CheckpointerPID = 0;
			if (EXIT_STATUS_0(exitstatus) && pmState == PM_SHUTDOWN)
			{...

				/* Waken archiver for the last time */
				if (PgArchPID != 0)
					signal_child(PgArchPID, SIGUSR2);
 ...
			}
...

而pm的退出依赖除syslogger外所有进程的退出：

	if (pmState == PM_WAIT_DEAD_END)
	{
		if (dlist_is_empty(&BackendList) &&
			PgArchPID == 0 && PgStatPID == 0)
		{
			/* These other guys should be dead already */
			Assert(StartupPID == 0);
			Assert(WalReceiverPID == 0);
			Assert(BgWriterPID == 0);
			Assert(CheckpointerPID == 0);
			Assert(WalWriterPID == 0);
			Assert(AutoVacPID == 0);
			/* syslogger is not considered here */
			pmState = PM_NO_CHILDREN;
		}
	}

所以在生产环境中还发现了归档慢对停库有影响。

复现命令：

#配置归档
archive_mode = on
archive_command = '/bin/false ;sleep 1000'#配置归档永远为false且设置sleep以绕过NUM_ARCHIVE_RETRIES逻辑

#停库
pg_ctl stop -D $PGDATA -m fast

停库后进程如下：

$ ps -axjf|grep 61470
88406 88405 68705 pts/48 88405 S+ 6001 0:00 \_ grep --color=auto 61470
61470 61470 61470 ? -1 Ss 6001 0:00 /myhost/postgres/base/rasesql1.5.6/bin/postgres -D /myhost/pg8094/data
61772 61772 61772 ? -1 Ss 6001 0:00 \_ postgres: lzlpg: logger 
63880 63880 63880 ? -1 Ss 6001 0:00 \_ postgres: lzlpg: archiver archiving 000000010000018800000007

因为这里的checkpointer已经完整停下来了，数据库是一致状态，所以archiver直接kill -9也没有关系

一句话总结
#

问题1.为什么停库没有停下来？

walsender阻止了停库。checkpointer给walsender发送SIGUSR1，并无限等待所有walsender进程stopping状态，checkpointer卡在这一步。

后面停库停下来是因为-m i暴力停库

问题2.walsender阻止停库中间态是否有其他方案优雅停库？

有。给所有walsender发送SIGTERM信号，既kill（or kill -15、kill -SIGTERM)。随后checkpointer、postmaster会完整停库。

walsender启动时注册过SIGTERM信号，测试来看没有处理不了的情况。

SIGTERM也是pg_terminate_backend(pid)所发送的信号，也是标准停库时应该执行的命令以停止walsender。

问题3.为什么主从库只差一条shutdown checkpoint？

3.1主从库都有CHECKPOINT_ONLINE 的解释：

主库触发CHECKPOINT_ONLINE纯属巧合
由于物理walsender还在，这条wal record传输到了从库

3.2只有主库有CHECKPOINT_SHUTDOWN的解释：

这条CHECKPOINT_SHUTDOWN是主库起库的时候做的
由于主库没有起完，这条wal record没有传到从库

问题4.archiver为什么会阻止停库？

在reaper checkpointer进程时，pm会让archiver做最后一次归档，而pm依赖除syslogger之外的所有进程退出，所以最后一次归档如果够慢或者其他问题，会阻止停库。归档失败不会，归档进程会很快退出。

问题5.哪些进程会阻止停库？

references
#

https://www.postgresql.org/docs/current/server-shutdown.html https://wiki.postgresql.org/wiki/Signals postgres.c postmaster.c walsender.c xlog.c checkpointer.c startup.c pgarch.c

PostgreSQL案例：planning time超长问题分析

Wed, 21 Aug 2024 00:00:00 +0000

问题分析概述
#

库总是OOM，分析到是执行计划生成有问题，planning time 1秒，planning shared hit 100w。一通分析，定位到是统计信息基表pg_statistic膨胀，由于会话首次SQL执行时的CatCacheMiss，导致backend访问并缓存了pg_statistic过多的死元组数据。应用连接总会启用新会话，多个backend的总内存过大从而导致OOM。

下面是详细分析过程。

问题现象
#

某库反复OOM和重启。经过一通问题排查，发现会话连接数不多，但是每个会话的内存占用比较高，总内存超过内存cg限制导致OOM。初步可以排除以下原因：

不是元数据过多的问题导致。对象过多（一般是分区数太多）会导致会话缓存过多的元数据。这个库的对象不算多
不是sql执行计划问题。排序/hash可能使用过多内存。这个库不是这个场景，sql可以是一个顺序扫描。

在问题分析过程中发现，库里面执行任意一个简单sql执行时间很长，并且 Planning Buffers有约100w

 explain (analyze,buffers,timing) select * from lzlinfo limit 1;
 QUERY PLAN 
--------------------------------------------------------------------------------------------------------------------
 Limit (cost=0.00..1.02 rows=1 width=71) (actual time=0.011..0.012 rows=1 loops=1)
 Buffers: shared hit=1
 -> Seq Scan on lzlinfo (cost=0.00..480.73 rows=473 width=71) (actual time=0.010..0.010 rows=1 loops=1)
 Buffers: shared hit=1
 Planning:
 Buffers: shared hit=1127312 --异常planning shared hit
 Planning Time: 947.038 ms --异常planning time
 Execution Time: 0.035 ms
(8 rows)

再执行一次sql，planning time就正常了。

问题定位过程
#

打印执行计划的stat信息
#

把会话的执行计划各阶段的stat信息打到日志：

set log_parser_stats =on;
set log_planner_stats =on;
set log_executor_stats =on;

然后跑下sql，日志输出如下：

2024-08-13 10:02:33.936 CST,"postgres","lzldb",85532,"[local]",66babe8c.14e1c,13,"idle",2024-08-13 10:01:48 CST,4/713,0,LOG,00000,"PARSER STATISTICS","! system usage stats:
! 0.000046 s user, 0.000046 s system, 0.000091 s elapsed
! [0.001661 s user, 0.001661 s system total]
! 4660 kB max resident size
! 0/0 [0/8] filesystem blocks in/out
! 0/36 [0/996] page faults/reclaims, 0 [0] swaps
! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
! 0/0 [5/0] voluntary/involuntary context switches",,,,,"explain (analyze,buffers) select *,1 from lzlinfo
2024-08-13 10:02:33.938 CST,"postgres","lzldb",85532,"[local]",66babe8c.14e1c,14,"EXPLAIN",2024-08-13 10:01:48 CST,4/713,0,LOG,00000,"PARSE ANALYSIS STATISTICS","! system usage stats:
! 0.001459 s user, 0.000000 s system, 0.001464 s elapsed
! [0.003146 s user, 0.001687 s system total]
! 5972 kB max resident size
! 0/0 [0/8] filesystem blocks in/out
! 0/325 [0/1324] page faults/reclaims, 0 [0] swaps
! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
! 0/0 [5/0] voluntary/involuntary context switches",,,,,"explain (analyze,buffers) select *,1 from lzlinfo
2024-08-13 10:02:33.938 CST,"postgres","lzldb",85532,"[local]",66babe8c.14e1c,15,"EXPLAIN",2024-08-13 10:01:48 CST,4/713,0,LOG,00000,"REWRITER STATISTICS","! system usage stats:
! 0.000001 s user, 0.000000 s system, 0.000001 s elapsed
! [0.003177 s user, 0.001687 s system total]
! 5972 kB max resident size
! 0/0 [0/8] filesystem blocks in/out
! 0/0 [0/1324] page faults/reclaims, 0 [0] swaps
! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
! 0/0 [5/0] voluntary/involuntary context switches",,,,,"explain (analyze,buffers) select *,1 from lzlinfo
2024-08-13 10:02:34.644 CST,"postgres","lzldb",85532,"[local]",66babe8c.14e1c,16,"EXPLAIN",2024-08-13 10:01:48 CST,4/713,0,LOG,00000,"PLANNER STATISTICS","! system usage stats:
! 0.539964 s user, 0.164083 s system, 0.705718 s elapsed
! [0.543248 s user, 0.165770 s system total]
! 745072 kB max resident size --异常点
! 0/0 [0/8] filesystem blocks in/out
! 0/184803 [0/186157] page faults/reclaims, 0 [0] swaps
! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
! 0/1 [5/1] voluntary/involuntary context switches",,,,,"explain (analyze,buffers) select *,1 from lzlinfo
2024-08-13 10:02:34.644 CST,"postgres","lzldb",85532,"[local]",66babe8c.14e1c,17,"EXPLAIN",2024-08-13 10:01:48 CST,4/713,0,LOG,00000,"EXECUTOR STATISTICS","! system usage stats:
! 0.540248 s user, 0.164170 s system, 0.706088 s elapsed
! [0.543532 s user, 0.165857 s system total]
! 745596 kB max resident size
! 0/0 [0/8] filesystem blocks in/out
! 0/184898 [0/186252] page faults/reclaims, 0 [0] swaps
! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
! 0/1 [5/1] voluntary/involuntary context switches",,,,,"explain (analyze,buffers) select *,1 from lzlinfo
"

planner阶段内存使用率暴涨，elapsed time也暴涨。这部分信息可以定位到是整个planning阶段中的planner阶段有问题。其他可用信息不多。

strace追踪
#

strace -p 76419

strace: Process 76419 attached
epoll_wait(4, [{EPOLLIN, {u32=15422552, u64=15422552}}], 1, -1) = 1
recvfrom(9, "Q\0\0\0\262explain (analyze,buffers) s"..., 8192, 0, NULL, NULL) = 179
lseek(5, 0, SEEK_END) = 8192
brk(NULL) = 0xfed000
brk(0x100e000) = 0x100e000
brk(NULL) = 0x100e000
brk(NULL) = 0x100e000
brk(0x1007000) = 0x1007000
brk(NULL) = 0x1007000
mmap(NULL, 270336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b7806b0c000
open("base/17076/16678", O_RDWR) = 7
lseek(7, 0, SEEK_END) = 0
open("base/17076/46160", O_RDWR) = 12
lseek(12, 0, SEEK_END) = 7667712
open("base/17076/46168", O_RDWR) = 13
lseek(13, 0, SEEK_END) = 188416
open("base/17076/46170", O_RDWR) = 14
lseek(14, 0, SEEK_END) = 188416
mmap(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b78c1b36000
brk(NULL) = 0x1007000
brk(0x102c000) = 0x102c000
brk(NULL) = 0x102c000
brk(NULL) = 0x102c000
brk(0x1025000) = 0x1025000
brk(NULL) = 0x1025000
lseek(12, 0, SEEK_END) = 7667712
open("pg_stat_tmp/pgss_query_texts.stat", O_RDWR|O_CREAT, 0600) = 15
pwrite64(15, "explain (analyze,buffers) select"..., 172, 93934) = 172
pwrite64(15, "\0", 1, 94106) = 1
close(15) = 0
sendto(8, "\2\0\0\0\250\3\0\0\264B\0\0\10\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 936, 0, NULL, 0) = 936
sendto(8, "\2\0\0\0\250\3\0\0\264B\0\0\10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 936, 0, NULL, 0) = 936
sendto(8, "\2\0\0\0\250\3\0\0\264B\0\0\10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 936, 0, NULL, 0) = 936
sendto(8, "\2\0\0\0\250\3\0\0\264B\0\0\10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 936, 0, NULL, 0) = 936
sendto(8, "\2\0\0\0\250\3\0\0\264B\0\0\10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 936, 0, NULL, 0) = 936
sendto(8, "\2\0\0\0\10\1\0\0\264B\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 264, 0, NULL, 0) = 264
sendto(8, "\2\0\0\0\10\1\0\0\0\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 264, 0, NULL, 0) = 264
sendto(8, "\16\0\0\0H\0\0\0\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0"..., 72, 0, NULL, 0) = 72
sendto(9, "T\0\0\0#\0\1QUERY PLAN\0\0\0\0\0\0\0\0\0\0\31\377\377\377\377"..., 826, 0, NULL, 0) = 826
recvfrom(9, 0xd2b4e0, 8192, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
epoll_wait(4, 

虽然shared hit很多，但strace信息很少 strace显示会话只open了4个数据文件，通过fd和oid2name查到数据文件，分别是表、表的两个索引以及pathman_config：

From database "lzldb":
 Filenode Table Name
--------------------------------------
 46170 ix_name
 46168 pk_lzlinfo
 46160 lzlinfo
 16678 pathman_config

这些对象都不大，看上去不像这些表（or索引）过大导致的。

perf
#

（图不好贴自行脑补） perf火焰图有40%的时间在heap_hot_search_buffer堆栈上

gdb
#

以heap_hot_search_buffe函数为依据，经过多次gdb，打如下断点试着看看哪有问题：

b relation_open
b get_relation_info
b RelationCacheInvalidateEntry 
b get_relname_relid
b AcceptInvalidationMessages
b RelationClearRelation
b pg_hint_plan_planner
b heap_hot_search_buffer

刚开始命中断点的时候，其实有很多无用的信息，因为他们是正常逻辑。不过后面发现，执行到一定程度，只有heap_hot_search_buffer命中：

Breakpoint 15, heap_hot_search_buffer (tid=tid@entry=0x2313c60, relation=0x2b2141663910, buffer=17045, snapshot=snapshot@entry=0x228a058, heapTuple=heapTuple@entry=0x23273d0, 
 all_dead=all_dead@entry=0x7ffce272e28f, first_call=true) at heapam.c:1503
1503 in heapam.c
(gdb) 
Continuing.
...

Breakpoint 15, heap_hot_search_buffer (tid=tid@entry=0x2313c60, relation=0x2b2141663910, buffer=96708, snapshot=snapshot@entry=0x228a058, heapTuple=heapTuple@entry=0x23273d0, 
 all_dead=all_dead@entry=0x7ffce272e28f, first_call=true) at heapam.c:1503
1503 in heapam.c

heap_hot_search_buffer传入的绝大部分参数没有变，包括relation、heapTuple的地址，只有buffer参数在改变，说明应该在扫描同一个relation。
heapTuple中包含table oid信息，直接打出来看看：

(gdb) p *heapTuple
$46 = {
 t_len = 968, 
 t_self = {
 ip_blkid = {
 bi_hi = 0, 
 bi_lo = 7211
 }, 
 ip_posid = 5
 }, 
 t_tableOid = 2619, --这个比较有用
 t_data = 0x2b2155fced00

heap_hot_search_buffer传入的oid=2619，2619在pg_class中对应pg_statistic

select oid,relname from pg_class where oid in (2619)
 oid | relname 
-------+----------------------------------
 2619 | pg_statistic

找这个统计信息基表无可厚非，因为pg在生成可能的执行计划s时需要用到统计信息来估算代价。

pg_statistic的膨胀
#

定位到pg_statistic，那么看下pg_statistic表的情况

> \dt+ pg_statistic
 List of relations
 Schema | Name | Type | Owner | Persistence | Size | Description 
------------+--------------+-------+----------+-------------+---------+-------------
 pg_catalog | pg_statistic | table | postgres | permanent | 1036 MB | 


> select * from pg_class where relname='pg_statistic'\gx
-[ RECORD 1 ]-------+------------------------------------------------
oid | 2619
relname | pg_statistic
relnamespace | 11
reltype | 12016
reloftype | 0
relowner | 10
relam | 2
relfilenode | 2619
reltablespace | 0
relpages | 132481
reltuples | 4655

pg_statistic有1G，确实有些大了，有132481块却只有4655行，这明显是有表膨胀了。但是即便有表膨胀，访问统计信息需要cache整个pg_statistic吗？逻辑上来说不需要，因为只需要访问对应表的统计信息就行了，实际上pg也是通过pg_statistic的主键索引pg_statistic_relid_att_inh_index来访问的。从下面的从堆栈中能看到传入的是pg_statistic的复合主键上的字段：

bt
...
#6 0x000000000086edbc in SearchCatCacheMiss (cache=cache@entry=0x226ba80, nkeys=nkeys@entry=3, hashValue=hashValue@entry=853716409, hashIndex=hashIndex@entry=57, v1=v1@entry=18767, v2=v2@entry=1, 
 v3=v3@entry=0, v4=v4@entry=0) at catcache.c:1368
#7 0x000000000086fa82 in SearchCatCacheInternal (v4=0, v3=<optimized out>, v2=<optimized out>, v1=<optimized out>, nkeys=3, cache=0x226ba80) at catcache.c:1299
#8 SearchCatCache3 (cache=0x226ba80, v1=v1@entry=18767, v2=v2@entry=1, v3=v3@entry=0) at catcache.c:1183
#9 0x0000000000880d70 in SearchSysCache3 (cacheId=cacheId@entry=58, key1=key1@entry=18767, key2=key2@entry=1, key3=key3@entry=0) at syscache.c:1145
#10 0x0000000000874092 in get_attavgwidth (relid=relid@entry=18767, attnum=1) at lsyscache.c:2991
#11 0x00000000006a2d46 in set_rel_width (root=root@entry=0x2326600, rel=rel@entry=0x21e8418) at costsize.c:5516 
...

传入了relid=relid@entry=18767, attnum=1

 select ctid,starelid,staattnum from pg_statistic where starelid=18767;
 ctid | starelid | staattnum 
------------+----------+-----------
 (132657,6) | 18767 | 1
 (132657,7) | 18767 | 2
 (132657,8) | 18767 | 3
 (132657,9) | 18767 | 4
 (132658,1) | 18767 | 5
 (132658,2) | 18767 | 6
 (132658,3) | 18767 | 7
 (132658,4) | 18767 | 8
 (132658,5) | 18767 | 9
 (132658,6) | 18767 | 10
 --lzlinfo总共10个字段，每个字段对应一个staattnum

通过ctid可以看出，这些数据实际上只在2个块中。看下通过复合主键索引访问pg_statistic，结果发现哪怕在只有2个块，也要访问1s，shared hit高达100w（1141568）：

 explain (analyze,buffers,timing,verbose) select ctid,starelid from pg_statistic where starelid=18767;
 QUERY PLAN 
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using pg_statistic_relid_att_inh_index on pg_catalog.pg_statistic (cost=0.41..103.31 rows=23 width=10) (actual time=105.416..1035.723 rows=10 loops=1)
 Output: ctid, starelid
 Index Cond: (pg_statistic.starelid = '18767'::oid)
 Buffers: shared hit=1141568 --异常
 Planning:
 Buffers: shared hit=8
 Planning Time: 0.102 ms
 Execution Time: 1035.802 ms

通过索引访问10条pg_statistic数据，shared hit有100w，跟SQL的100w planning shared hit差不多。（注意这里的 Planning Time很少，说明我们没有在生成执行计划阶段出问题）

索引dead tuple
#

如果vacuum没有真的“跑起来”，那么索引的dead tuple还是会指向死元组参考从很慢的唯一索引扫描到索引膨胀

autovacuum未回收死元组
#

表膨胀这么大，autovacuum不应该回收吗？

select * from pg_stat_all_tables where relname='pg_statistic'\gx
-[ RECORD 1 ]-------+------------------------------
relid | 2619
schemaname | pg_catalog
relname | pg_statistic
seq_scan | 1 	 --顺序访问pg_statistic极少
seq_tup_read | 4655
idx_scan | 28715508 --索引访问pg_statistic多
idx_tup_fetch | 25150245
n_tup_ins | 46
n_tup_upd | 1292143 --update很多
n_tup_del | 14
n_tup_hot_upd | 138448
n_live_tup | 4655
n_dead_tup | 1496776
n_mod_since_analyze | 1292203
n_ins_since_vacuum | 0
last_vacuum | [null]
last_autovacuum | 2024-08-16 20:34:15.045022+08 --注意autovacuum的时间是一个最近的值
last_analyze | [null]
last_autoanalyze | [null]
vacuum_count | 0
autovacuum_count | 144170
analyze_count | 0
autoanalyze_count | 0

其实pg_statistic上是autovacuum一直在跑，只不过进程有可能看不到，因为autovacuum没有跑什么，所以跑的比较快，跑完又snap休息了

show autovacuum_naptime ;
 autovacuum_naptime 
--------------------
 1min

每间隔1分钟休息一次，日志中也是每隔1分钟打印一次autovacuum信息。

2024-08-16 21:05:15.267 CST,,,41080,,66bf4e87.a078,1,,2024-08-16 21:05:11 CST,27/166839,0,LOG,00000,"automatic vacuum of table ""lzldb.pg_catalog.pg_statistic"": index scans: 0
pages: 0 removed, 132685 remain, 1 skipped due to pins, 0 skipped frozen
tuples: 0 removed, 1501745 remain, 1497090 are dead but not yet removable, oldest xmin: 119329380
buffer usage: 265443 hits, 0 misses, 0 dirtied
avg read rate: 0.000 MB/s, avg write rate: 0.000 MB/s
system usage: CPU: user: 0.53 s, system: 0.17 s, elapsed: 3.38 s
WAL usage: 1 records, 0 full page images, 233 bytes",,,,,,,,,"","autovacuum worker"
2024-08-16 21:05:17.474 CST,,,41080,,66bf4e87.a078,2,,2024-08-16 21:05:11 CST,27/166844,136438968,LOG,00000,"automatic analyze of table ""lzldb.public.lzlinfo"" system usage: CPU: user: 2.02 s, system: 0.00 s, elapsed: 2.08 s",,,,,,,,,"","autovacuum worker"
"

1497090 are dead but not yet removable虽然触发了autovacuum但是根本没有回收到死元组，1497090条死元组没有清理。排查下库内是谁持有了oldest xmin: 119329380，很快可以定位到复制槽：

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 
-----------------+----------+-----------+--------+----------+-----------+--------+------------+--------+--------------+--------------+---------------------+------------+---------------
 slotslotlostname | pgoutput | logical | 17076 | lzldb | f | f | [null] | [null] | 119329380 | 3F9/105A4970 | 3F9/105F8778 | extended | [null]

slot的catalog_xmin=119329380，与vacuum展示的oldest xmin: 119329380一致。 active=f说明复制链路已经挂了。

修复问题
#

把复制槽删除：

select pg_drop_replication_slot('slotslotlostname');
 pg_drop_replication_slot 
--------------------------

手动vacuum或再等待1分钟autovacuum。最后再开一个全新的会话测试一下恢复没有：

## psql
psql (13.2)
Type "help" for help.

> \c lzldb
You are now connected to database "lzldb" as user "postgres".
> explain (analyze,buffers,timing) select * from lzlinfo limit 1;
 QUERY PLAN 
---------------------------------------------------------------------------------------------------------------------
 Limit (cost=0.00..8.04 rows=1 width=71) (actual time=0.023..0.025 rows=1 loops=1)
 Buffers: shared hit=1
 -> Seq Scan on lzlinfo (cost=0.00..3802.73 rows=473 width=71) (actual time=0.018..0.018 rows=1 loops=1)
 Buffers: shared hit=1
 Planning:
 Buffers: shared hit=2578
 Planning Time: 9.605 ms
 Execution Time: 0.098 ms

耗时从1s下降到10ms，Planning shared hit从100w下降到2k，问题基本解决。

案例总结
#

复制链路挂掉，复制槽未及时清理，导致pg_statistic统计信息基表膨胀，导致每个backend在首次加载统计信息时都非常缓慢且读取多余的page到本地缓存，导致每个backend的缓存都大于正常水平（2g左右），多个backend导致最后的OOM。其实问题很简单，只是过程比较曲折···简言之：基表pg_statistic膨胀导致执行计划生成阶段访问数据过大。元数据基表膨胀其实还有其他棘手的问题，有缘再见了。

ORDER BY limit 10比ORDER BY limit 100更慢

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

问题分析
#

pg数据库中执行sql时，ORDER BY limit 10比ORDER BY limit 100更慢

执行计划分析
#

 SELECT
			*,
 (select cl.ITEM_DESC from tablelzl2 cl where item_name='name' and cl.ITEM_NO='abcdefg') AS "item"
 FROM
 tablelzl1 RI
 WHERE RI.column1='AAAA'
		AND RI.column2 = 'applyno20231112'
 ORDER BY
 RI.column3 DESC limit 10

 Limit (cost=0.43..1522.66 rows=10 width=990)
 -> Index Scan Backward using idx_tablelzl1_column3 on tablelzl1 ri (cost=0.43..158007.45 rows=1038 width=990)
 Filter: (((column1)::text = 'AAAA'::text) AND ((column2)::text = 'applyno20231112'::text))
 SubPlan 1
 -> Index Scan using uk_tablelzl2_ii on tablelzl2 cl (cost=0.27..5.29 rows=1 width=18)
 Index Cond: (((item_no)::text = 'manualSign'::text) AND ((item_name)::text = (ri.manual_sign)::text))

主表没有走到column2索引，而是走column3排序字段索引的Index Scan Backward，scan index的cost非常高，而最终的cost比较低，实际执行需要9s 如果把limit 10改成limit 100，执行计划正常：

 SELECT
			*,
 (select cl.ITEM_DESC from tablelzl2 cl where cl.ITEM_NAME = RI.MANUAL_SIGN AND cl.ITEM_NO='manualSign') AS "manualSign"
 FROM
 tablelzl1 RI
 WHERE RI.column1='AAAA'
		AND RI.column2 = 'applyno20231112'
 ORDER BY
 RI.column3 DESC limit 100 

 QUERY PLAN 
-----------------------------------------------------------------------------------------------------------------------
Limit (cost=2632.28..3162.78 rows=100 width=990)
 -> Result (cost=2632.28..8138.87 rows=1038 width=990)
 -> Sort (cost=2632.28..2634.87 rows=1038 width=474)
 Sort Key: ri.column3 DESC
 -> Index Scan using idx_cri_column2 on tablelzl1 ri (cost=0.43..2592.61 rows=1038 width=474)
 Index Cond: ((column2)::text = 'applyno20231112'::text)
 Filter: ((column1)::text = 'AAAA'::text)
 SubPlan 1
 -> Index Scan using uk_tablelzl2_ii on tablelzl2 cl (cost=0.27..5.29 rows=1 width=18)
 Index Cond: (((item_no)::text = 'manualSign'::text) AND ((item_name)::text = (ri.manual_sign)::text))
(10 rows)

子查询执行计划不变，主表走到column2单列索引，回表后排序再limit，执行非常快。不仅是limit，如果原sql仅更换column2的值，执行计划也正常。也就是说这个生产的sql只有极个别的column2的值时执行计划是异常的。

执行计划分析：子查询前后没变可以不用分析，主要是索引选择上的不同。column2是过滤字段，column3是排序字段，两个执行计划分别选择了这2个字段的索引。

异常的limit 10执行计划：反向扫描排序字段索引->回表 ->limit。因为不需要额外排序，反向扫描索引时找到limit个数据就可以不用继续扫描了；扫描排序字段索引的预估代价非常高，最上层的limit最终代价预估很低。
正常的limit 100执行计划：访问过滤字段索引->回表 ->以排序字段排序 ->limit。因为要排序，需要把符合条件的所有索引条目全部找出来；本身访问过滤字段的索引代价预估低。

所以问题的关键在于部分反向扫描排序索引时，代价预估的过低

真实的执行情况
#

explain (analyze,buffers) 看下真实的执行情况

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit (cost=0.43..1521.93 rows=10 width=990) (actual time=23.311..8122.516 rows=10 loops=1)
 Buffers: shared hit=861100 read=42985 dirtied=7
 I/O Timings: read=6741.003
 -> Index Scan Backward using idx_tablelzl1_column3 on tablelzl1 ri (cost=0.43..157932.45 rows=1038 width=990) (actual time=23.309..8122.505 rows=10 loops=1)
 Filter: (((column1)::text = 'AAAA'::text) AND ((column2)::text = 'applyno20231112'::text))
 Rows Removed by Filter: 1521796
 Buffers: shared hit=861100 read=42985 dirtied=7
 I/O Timings: read=6741.003
 SubPlan 1
 -> Index Scan using uk_tablelzl2_ii on tablelzl2 cl (cost=0.27..5.29 rows=1 width=18) (actual time=0.005..0.005 rows=0 loops=10)
 Index Cond: (((item_no)::text = 'manualSign'::text) AND ((item_name)::text = (ri.manual_sign)::text))
 Buffers: shared hit=6
 Planning:
 Buffers: shared hit=121 read=28
 I/O Timings: read=1.476
 Planning Time: 2.314 ms
 Execution Time: 8122.658 ms

 Limit (cost=2632.28..3162.78 rows=100 width=990) (actual time=150.101..150.122 rows=14 loops=1)
 Buffers: shared hit=700 read=274
 I/O Timings: read=146.903
 -> Result (cost=2632.28..8138.87 rows=1038 width=990) (actual time=150.100..150.119 rows=14 loops=1)
 Buffers: shared hit=700 read=274
 I/O Timings: read=146.903
 -> Sort (cost=2632.28..2634.87 rows=1038 width=474) (actual time=150.072..150.073 rows=14 loops=1)
 Sort Key: ri.column3 DESC
 Sort Method: quicksort Memory: 30kB
 Buffers: shared hit=694 read=274
 I/O Timings: read=146.903
 -> Index Scan using idx_cri_column2 on tablelzl1 ri (cost=0.43..2592.61 rows=1038 width=474) (actual time=0.418..149.973 rows=14 loops=1)
 Index Cond: ((column2)::text = 'applyno20231112'::text)
 Filter: ((column1)::text = 'AAAA'::text)
 Rows Removed by Filter: 1218
 Buffers: shared hit=691 read=274
 I/O Timings: read=146.903
 SubPlan 1
 -> Index Scan using uk_tablelzl2_ii on tablelzl2 cl (cost=0.27..5.29 rows=1 width=18) (actual time=0.002..0.002 rows=0 loops=14)
 Index Cond: (((item_no)::text = 'manualSign'::text) AND ((item_name)::text = (ri.manual_sign)::text))
 Buffers: shared hit=6
 Planning Time: 0.334 ms
 Execution Time: 150.257 ms

limit 10的执行计划，执行8s，内存读shared hit=861100 磁盘读read=42985 ，丢弃了1521796行 limit 100的执行计划执行0.1s shared hit=694 read=274，丢弃了1218行 limit 10的执行计划明显是不正常，读了太多的数据才找到符合条件的行，这是sql执行过慢的原因

统计信息分析
#

本身预估的代价不高，但是实际上需要扫描非常多的索引行，首先想到是否是统计信息是否准确表的统计信息：

[postgres@cnsz381785:7169/(rasesql)phmamp][10-30.15:01:26]M=# select relpages,reltuples::bigint from pg_class where relname='tablelzl1';
 relpages | reltuples 
----------+-----------
 91172 | 2280874 --count出来差不多

字段的统计信息：

[phmampopr@cnsz381785:7169/(rasesql)phmamp][10-27.17:08:48]M=> select * from pg_stats where tablename='tablelzl1' and attname='column2';
-[ RECORD 1 ]----------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
schemaname | public
tablename | tablelzl1
attname | column2
inherited | f
null_frac | 0
avg_width | 18
n_distinct | -0.11990886
most_common_vals | {applyno20231112,DY20190723006650,DY20200102012899,DY20180827000557,DY20190524001304,DY20190529001885,DY20190728002359}
most_common_freqs | {0.0005,0.00026666667,0.00023333334,0.0002,0.0002,0.0002,0.0002}
histogram_bounds | {CULZF0000121605605,DSNEW0000126854232,DSNEW0000137652871,DY20160516001057,DY20161104005509,DY20170306002677,DY20170703010428,DY20170928013517,DY20180410007383,DY20180615002936,DY20180
correlation | 0.3131596
most_common_elems | [null]
most_common_elem_freqs | [null]
elem_count_histogram | [null]

这个column2 applyno20231112刚好就是排第一的most_common_vals，出现预估概率是0.0005，用预估的行2280874*0.0005=1140，与实际的行数1232差不多

[postgres@cnsz381785:7169/(rasesql)phmamp][10-30.15:05:28]M=# select count(*) from tablelzl1 where column2 = 'applyno20231112';
 count 
-------
 1232

说明统计信息是准确的，实际上运行analze收集统计信息也不会解决这个问题

数据分布不均的计算
#

用当前统计信息计算出来的符合条件的行有1140个，那么预计从排序字段的索引上找到第一条数据平均要扫描2280874/1140=2000个索引行。如果找10条便是20000个索引行，100条便是200000个索引行。

把sort禁用，让limit 100语句强行走排序字段的索引

M=# set enable_sort=off;
SET

--limit 100的执行计划
 Limit (cost=0.43..15222.69 rows=100 width=990)
 -> Index Scan Backward using idx_tablelzl1_column3 on tablelzl1 ri (cost=0.43..158007.45 rows=1038 width=990)
 Filter: (((column1)::text = 'AAAA'::text) AND ((column2)::text = 'applyno20231112'::text))
 SubPlan 1
 -> Index Scan using uk_tablelzl2_ii on tablelzl2 cl (cost=0.27..5.29 rows=1 width=18)
 Index Cond: (((item_no)::text = 'manualSign'::text) AND ((item_name)::text = (ri.manual_sign)::text))

limit 10改成limit 100后的执行计划，代价从1522.66升到了15222.69，基本上只是简单的*10。limit 100的代价15222.69大于了走过滤字段索引的执行计划cost 3162.78，所以limit 10和limit 100执行计划不同，选择了不同的索引。

以上的估算都是以数据零散的放在排序列的索引上为前提的，实际情况有可能数据在最后一条（反向扫描索引），很快就能找到；也有可能数据全部在索引叶节点前面的几个pages，此时几乎是扫描全部索引并回表，代价便非常高。那么两个字段的关联度，数据在索引上的分布情况，决定了使用排序字段的索引的效率。

再看下真实的执行扫描了多少行数据：

 -> Index Scan Backward using idx_tablelzl1_column3 on tablelzl1 ri (cost=0.43..157932.45 rows=1038 width=990) (actual time=23.309..8122.505 rows=10 loops=1)
 Filter: (((column1)::text = 'AAAA'::text) AND ((column2)::text = 'applyno20231112'::text))
 Rows Removed by Filter: 1521796

实际上差不多扫描了1521796行才找到这10条数据，本来预估的是20000，整整相差了76倍！

触发场景
#

必须有where +order by+limit语句
排序字段和过滤字段都必须有索引
一般limit不会特别大
数据分布不均

解决办法
#

改写sql语句：添加表达式，不让order by字段走索引即可

 SELECT
			*,
 (select cl.ITEM_DESC from tablelzl2 cl where cl.ITEM_NAME = RI.MANUAL_SIGN AND cl.ITEM_NO='manualSign') AS "manualSign"
 FROM
 tablelzl1 RI
 WHERE RI.column1='AAAA'
		AND RI.column2 = 'applyno20231112'
 ORDER BY
 RI.column3 +'0' DESC limit 10

oracle是怎么做的
#

执行计划cost的预估差异
#

从上面的执行计划分析，pg的执行计划cost看起来不太适应，上层的cost小于内层的cost，不像oracle这样阶梯式的累加计算这里做一个oracle和pg的实验，一张表仅存储colname=‘x’的数据，看下pg和oracle的对cost计算的区别：

[postgres@cnsz381785:7169/(rasesql)dbmgr][10-31.14:32:19]M=# explain select * from testlzl where col1='x' limit 1;
 QUERY PLAN 
-----------------------------------------------------------------------
 Limit (cost=0.00..0.02 rows=1 width=2)
 -> Seq Scan on testlzl (cost=0.00..17747.20 rows=1048576 width=2)
 Filter: ((col1)::text = 'x'::text)

[postgres@cnsz381785:7169/(rasesql)dbmgr][10-31.14:32:30]M=# explain select * from testlzl where col1='xx' limit 1;
 QUERY PLAN 
-----------------------------------------------------------------
 Limit (cost=0.00..17747.20 rows=1 width=2)
 -> Seq Scan on testlzl (cost=0.00..17747.20 rows=1 width=2)
 Filter: ((col1)::text = 'xx'::text)

col1=‘x’立马就能找到，limit的算法没有推入到全表扫描的成本中，total cost是17747.20，跟扫描完表的成本是一样的。limit的成本cost虽然没有下推到内层的cost做计算，但是rows计算了！

来看下oracle是执行计划是怎么做的：

SYS@t8icss1> select * from dbmgr.testlzl where a='x' and rownum<=1;

1 row selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 2045386539

------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 2 | 2 (0)| 00:00:01 |
|* 1 | COUNT STOPKEY | | | | | |
|* 2 | TABLE ACCESS FULL| TESTLZL | 1 | 2 | 2 (0)| 00:00:01 |
------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

 1 - filter(ROWNUM<=1)
 2 - filter("A"='x')

SYS@t8icss1> select * from dbmgr.testlzl where a='xx' and rownum<=1;

no rows selected


Execution Plan
----------------------------------------------------------
Plan hash value: 2045386539

------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 2 | 302 (2)| 00:00:01 |
|* 1 | COUNT STOPKEY | | | | | |
|* 2 | TABLE ACCESS FULL| TESTLZL | 1 | 2 | 302 (2)| 00:00:01 |
------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

 1 - filter(ROWNUM<=1)
 2 - filter("A"='xx')

对于oracle的计划，a=‘x’的数据可以立即找到的话，STOPKEY的代价算进了内层的cost中，cost只有2，实际上扫描全表的代价比较高302。

这一点是oracle与pg关于cost计算的一个重要区别：

oracle的外层cost必然>=内层cost；pg则不一定
oracle的内层cost计算包含了外层的算子（比如stopkey）；但是pg不会包含，直接给子路径的全部成本

oracle的数据分布不均问题
#

知道了数据分布不均的原理，造一条数据把他放在排序索引的开头即可

create table tlzl(a char(100) not null,b char(100) not null);
--插入批量数据
begin
for i in 1..100000 loop
insert into tlzl values('test','test');
end loop;
end;
/
--插入特殊数据
insert into tlzl values('aaaa','aaaa');
insert into tlzl values('zzzz','zzzz');
--创建索引
create index idx_a on tlzl(a);
create index idx_b on tlzl(b);
--收集统计信息
EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>'SYS',TABNAME=>'TLZL',estimate_percent => 10, degree=>1,METHOD_OPT=>'FOR ALL COLUMNS SIZE AUTO',cascade=>true);

select * from (select /*+ index(tlzl idx_a)*/* from tlzl where b='aaaa' order by a) where rownum<=1; 
select * from (select /*+ index(tlzl idx_a)*/* from tlzl where b='zzzz' order by a) where rownum<=1; 

SYS@t8icss1> select * from (select /*+ index(tlzl idx_a)*/* from tlzl where b='aaaa' order by a) where rownum<=1; 

Execution Plan
----------------------------------------------------------
Plan hash value: 3674066029

---------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 204 | 2210 (1)| 00:00:01 |
|* 1 | COUNT STOPKEY | | | | | |
| 2 | VIEW | | 1 | 204 | 2210 (1)| 00:00:01 |
|* 3 | TABLE ACCESS BY INDEX ROWID| TLZL | 1 | 202 | 2210 (1)| 00:00:01 |
| 4 | INDEX FULL SCAN | IDX_A | 98830 | | 779 (1)| 00:00:01 |
---------------------------------------------------------------------------------------

SYS@t8icss1> select * from (select /*+ index(tlzl idx_a)*/* from tlzl where b='zzzz' order by a) where rownum<=1; 

Execution Plan
----------------------------------------------------------
Plan hash value: 3674066029

---------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 204 | 2210 (1)| 00:00:01 |
|* 1 | COUNT STOPKEY | | | | | |
| 2 | VIEW | | 1 | 204 | 2210 (1)| 00:00:01 |
|* 3 | TABLE ACCESS BY INDEX ROWID| TLZL | 1 | 202 | 2210 (1)| 00:00:01 |
| 4 | INDEX FULL SCAN | IDX_A | 98830 | | 779 (1)| 00:00:01 |
---------------------------------------------------------------------------------------

oracle的优化器也是一样的，优化器并不知道数据到底放在索引的哪个地方，没有办法，放在索引的第一条和最后一条都是估算的同一代价。不过oracle有很多方法可以解决这个问题，如extended statistic、Automatic Column Group Detection、固化执行计划等。

参考
#

http://www.postgres.cn/v2/news/viewone/1/717 https://oracle-base.com/articles/12c/automatic-column-group-detection-extended-statistics-12cr1

pg报错attempted to delete invisible tuple

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

问题描述
#

postgresql数据库执行delete报错：attempted to delete invisible tuple，执行同样条件的select不报错

delete from lzltab1;
select count(*) from lzltab1;

执行全表删除和全表查询的结果：

M=# delete from lzltab1;
ERROR: 55000: attempted to delete invisible tuple
LOCATION: heap_delete, heapam.c:2500
Time: 511.050 ms

M=# select count(*) from lzltab1;
 count 
--------
 231187

delete找到了不可见的元组，select却是正常的。当时觉得很奇怪。pg的可见性通过元组的xmin,xmax,cid和快照的xmin，xmax，xip_list判断的，虽然delete元组的事务状态和时间会对可见性产生影响，但是表数据如果稳定（当前没有任何dml操作的话），随后的任何快照进去拍摄，都应该是一个稳定的可见集，它并不存在当前事务可见性判断，dml事务元组可见性判断也应该一致。也就是说这种场景下，select快照和delete快照不应该有这种差异。

问题分析
#

找到源码
#

注意报错信息heapam.c:2500 找到源码位置src/backend/access/heap/heapam.c 2500的行是空的，附近的代码如下

	/*
	 * Before locking the buffer, pin the visibility map page if it appears to
	 * be necessary. Since we haven't got the lock yet, someone else might be
	 * in the middle of changing this, so we'll need to recheck after we have
	 * the lock.
	 */

	if (PageIsAllVisible(page))
		visibilitymap_pin(relation, block, &vmbuffer);

	LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);

从源码看，它在尝试获得vm上的锁，看来问题跟vm文件相关。

vm文件
#

什么是vm文件？ vm文件是为了减少vacuum扫描page时间的，如果一个page不需要vacuum那么它应该可以被vacuum跳过，这样可以大大减少vacuum寻找需要清理的page的时间，这是vm文件最初的目的。（有时候也会被index-only scan使用，不过我们这里不会涉及，我们用的是全表扫描） vm文件包含两个信息：

page中的元组是不是都是可见的。说明page中没有需要被vacuum的死元组
page中的元组是不是都是冻结的。说明vacuum freeze不需要访问这个page

vm会帮助vacuum寻找死元组，减少扫描的页的数量。比如上面这个图（interdb yyds！），第一个页面1st不包含死元组，那么vacuum就可以跳过这个页面。

找到vm文件 每个表都有Visibility Map (VM)（索引没有vm文件），单独存放在表文件的旁边，如果一个表的filenode为12345，那么vm文件应该是12345_vm 首先cd到data目录

M=# show data_directory;
 data_directory 
----------------------
 /pg/pg6666/data

通过database oid，表的oid可以找到文件存储的位置

=# select oid,datname from pg_database where datname='sdp';
-------+----------------------
 oid | datname
 17075 | sdp
=# select oid,relname from pg_class where relname='lzltab1'; 
-------+----------------------
 17362 | lzltab1

# select pg_relation_filepath('lzltab1');
pg_relation_filepath 
----------------------
base/17075/17362

找到数据文件和vm

$ cd /pg/pg6666/data/base/17075
$ ll 17362*
-rw------- 1 postgres postgres 86761472 Jun 15 17:43 17362
-rw------- 1 postgres postgres 40960 Jun 9 21:09 17362_fsm
-rw------- 1 postgres postgres 8192 Nov 14 2022 17362_vm

pg_visibility插件
#

pg_visibility提供通过检查vm文件输出页级别的可见性信息，而且可以检测vm是否损坏。因为vm存储了“page中的元组是不是都是可见的；page中的元组是不是都是冻结的”这些信息，pg_visibility可以检查出哪些页是all-frozen的，哪些是all-visible的。 pg_visibility插件使用参考：https://www.postgresql.org/docs/current/pgvisibility.html

会用到的pg_visibility中的function
#

pg_visibility_map_summary()：显示vm中的all-visible页和all-frozen页 pg_check_frozen()：有元组不是frozen的，但在它所在的页在vm中被标记为了all-frozen，如果该函数有返回，表示vm文件损坏。 pg_check_visible()：有元组不是visible的，但在它所在的页在vm中被标记为了all-visible，如果该函数有返回，表示vm文件损坏。 pg_truncate_visibility_map()：清理vm文件。清理vm后，当表首次执行vacuum时，会扫描表上的所有页并重建vm。

修复vm文件
#

检查vm是否损坏

M=# select pg_visibility_map_summary('lzltab1');
 pg_visibility_map_summary 
---------------------------
 (472,0)

all-visible 472页，all-frozen 0页

M=# select pg_check_frozen('lzltab1');
 pg_check_frozen 
-----------------
(0 rows)
M=# select pg_check_visible('lzltab1');
 pg_check_visible 
------------------
 (6839,1)
 (6839,2)
 ...
 (7296,15)
(1423 rows)

pg_check_visible()有结果说明vm已经损坏了 然后用pg_truncate_visibility_map()执行清空vm

M=# select pg_truncate_visibility_map('lzltab1');
 pg_truncate_visibility_map 
----------------------------

从磁盘上也能看出来vm被清空了

 ll 17362*
-rw------- 1 postgres postgres 86761472 Jun 27 10:39 17362
-rw------- 1 postgres postgres 40960 Jun 9 21:09 17362_fsm
-rw------- 1 postgres postgres 0 Jun 27 18:18 17362_vm

然后我们验证一下，vacuum表看下是否会生产vm文件，并检验vm文件是否没有损坏

M=# vacuum lzltab1;
VACUUM
Time: 3692.402 ms (00:03.692)
M=# \q
$ ll 17362*
-rw------- 1 postgres postgres 86761472 Jun 28 03:37 17362
-rw------- 1 postgres postgres 40960 Jun 9 21:09 17362_fsm
-rw------- 1 postgres postgres 8192 Jun 28 10:21 17362_vm

可以看到手动vacuum后vm正常生成

M=# select pg_check_visible('lzltab1');
 pg_check_visible 
------------------
(0 rows)

M=# select pg_check_frozen('lzltab1');
 pg_check_frozen 
-----------------
(0 rows)

check检查后没有输出，vm文件正常，修复完成。

最后再来跑下sql

## delete from lzltab1;
DELETE 229766

delete执行正常，问题解决

检查全库是否有vm损坏
#

虽然我们解决了一个vm文件损坏的问题，但是仍然需要全库检查是否有其他的vm损坏（前提是安装了extension pg_visibility)

SELECT oid::regclass AS relname
FROM pg_class
WHERE relkind IN ('r', 'm', 't') AND (
 EXISTS (SELECT * FROM pg_check_visible(oid))
 OR EXISTS (SELECT * FROM pg_check_frozen(oid)));

如果返回非空结果，说明有vm损坏了。就像上面的方法，用pg_truncate_visibility_map()清理vm，然后vacuum生成一个vm。如果是9.6前的版本，因为没有pg_visibility插件，需要停库然后手动删除vm文件，再启动数据库，然后再vacuum生成一个vm。

为什么vm会损坏？
#

我们通过一步步分析，检查到是vm文件损坏了，但是vm为什么会损坏呢？

pg数据库的bug。pg确实有些bug会导致vm损坏（参考wiki Visibility Map Problems），不过这些都是pg9.6.1以前的
操作系统和硬件问题

我们版本是pg13的，问题基本只能笼统地归于操作系统或者硬件问题。

为什么select没有问题，delete报错？
#

select全表正常，delete全表报错，看上去就很奇怪。问题的根因是vm文件的损坏。就像前面说的，vm文件是为了加快vacuum效率的，我们虽然没有做vacuum，而vm文件总要更新的吧？dml每次都会去更新vm（至少要检查），而select不会改变vm状态的。所以本案例中select正常执行，delete在执行到vm的处理时报错。我们的案例中，delete扫描了vm找到了all-visible的页，但是vm标记错了，这些页上仍然有不可见的元组，这里就对应了开头的报错attempted to delete invisible tuple。不可见的元组可能已经被delete了，再次跑delete当然会报错，这也违背了事务的可见性规则。另外，如果是index-only-scan也会用到vm文件，所以也会影响select语句，不过这个案例是全表扫描的，所以select没有问题。

vm损坏导致index-only-scan出现错误的数据结果
#

前面在介绍vm的时候提到处理vacuum外，index-only-scan也会用到vm文件，虽然我们这个案例没有涉及index-only-scan，但本着研究透彻的原则，把问题搞清楚。

什么是index-only-scan
#

index-only-scan顾名思义就是仅索引扫描。在访问数据的时候不需要访问表，而只访问索引结构就能得到想要的结果。几乎所有的关系型数据库都有仅索引扫描，因为B+树索引结构保存了键值，如果查询只查了键值，那么仅索引扫描就是可能的。但是，postgresql因为其事务实现跟其他数据库（Oracle、mysql）有很大的不同，它的仅索引扫描index-only-scan有一些特殊性。 postgresql通过元组头部的xmin、xmax等信息，校验元组和事务的可见性，而索引上没有这些信息，所以就导致pg的仅索引扫描必须访问数据块来检查可见性。这个时候vm的作用就体现了出来，因为vm文件中保存了all-visible，all-frozen的信息，这些被标记的页其实不需要校验元组可见性，因为他们已经被vm标记为可见了。再来一个interdb的图（interdb yyds！）。当一个sql查询在访问key是18和19两个元组时，key=18元组所在的页已经被vm标记为all-visible了，所以访问key=18的元组只需要访问索引页和vm文件；而key=19的元组所在的页没有被标记为all-visible，仅索引扫描还是要访问所在数据页获取元组可见信息。

index-only-scan查询出错误的结果
#

因为index-only-scan要访问vm，而vm损坏而保存了错误的信息，比如页中的元组本来不是所有都可见的（比如几个元组被delete了），但是页还是在vm中被标记为all-visible，导致index-only-scan没有进数据页检测元组可见性，直接返回了索引页上的本来是不可见的键值。可以设置enable_indexonlyscan=off来关闭index-only-scan特性，保证数据的正确性；当然也可以像上面那样去修复vm文件，也许是更好的选择。

总结
#

虽然刚开始有些曲折，一看报错以为是事务可见性规则出现了问题，这个有问题的话问题就有点大了，但是实际上要简单的多。我们从报错attempted to delete invisible tuple分析到源码，并定位到了是vm问题，再通过pg_visibility插件检测出vm corrupt并修复了vm文件，从而解决了delete报错，最后扩展了一下index-only-scan和vm。总结一下文章的知识点：

pg_visibility插件可以读取、检测、清理vm文件
如果没有vm信息的话，vacuum会生成新的vm
dml会读取/更新vm文件，select不会（非index-only-scan）
vm文件是为了提升vacuum的效率，有时候也会提升index-only-scan的效率
attempted to delete invisible tuple报错应该检查vm文件是否损坏
vm文件损坏会造成dml失败，也会造成index-only-scan查询出错误的结果

参考
#

https://www.postgresql.org/docs/13/pgvisibility.html https://wiki.postgresql.org/wiki/Visibility_Map_Problems https://www.interdb.jp/pg/pgsql06.html https://www.interdb.jp/pg/pgsql07.html

案例-insert value偶发慢分析

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

业务insert value偶发变慢，当我去查看活动会话的时候写入慢问题已经缓解了。后来发现写入慢问题持续不到半分钟，insert value写入时间1-2s，写个抓活动会话的脚本还是能拿到会话信息：

 wait_event | count
---------------------+-------
 [null] | 11
 WALRead | 1
 DataFileRead | 2
 BgWriterMain | 1
 WALWrite | 40
 AutoVacuumMain | 1
 ClientRead | 385
 LogicalLauncherMain | 1

等待事件最异常的就是WALWrite 40个会话。其中2个WALWrite等待的会话如下：

 pid | usename | xact_start | state_change | wait_event | wait_event_type | state | partofquery
-------+----------+-------------------------------+-------------------------------+---------------+-----------------+--------+--------------------------------------------------------------
 144955 | lzluser11 | 2024-05-23 07:58:27.516574+08 | 2024-05-23 07:58:27.516588+08 | WALWrite | LWLock | active | insert into table1( 
 179869 | lzluser11 | 2024-05-23 07:58:28.116371+08 | 2024-05-23 07:58:28.116386+08 | WALWrite | IO | active | insert into table1( 

直接搜源码关于WALWrite的相关内容

 * WALWriteLock: must be held to write WAL buffers to disk (XLogWrite or
 * XLogFlush).

/*
* LWLockAcquireOrWait - Acquire lock, or wait until it's free
*
* The semantics of this function are a bit funky. If the lock is currently
* free, it is acquired in the given mode, and the function returns true. If
* the lock isn't immediately free, the function waits until it is released
* and returns false, but does not acquire the lock.
*
* This is currently used for WALWriteLock: when a backend flushes the WAL,
* holding WALWriteLock, it can flush the commit records of many other
* backends as a side-effect. Those other backends need to wait until the
* flush finishes, but don't need to acquire the lock anymore. They can just
* wake up, observe that their records have already been flushed, and return.
*/ 

wal从wal buffer写入磁盘时，必须持有WALWriteLock。当backend刷wal时，持有WALWriteLock，它也能刷其他backends提交记录。其他backends需要等这个flush完成，但不需要再去持有锁了。如果他们的wal被刷了，他们能直接返回（而不是再去刷一次wal）。

XLogFlush极其重要， XLogFlush的关键代码在for循环里：

/*
 * Ensure that all XLOG data through the given position is flushed to disk.
 *
 * NOTE: this differs from XLogWrite mainly in that the WALWriteLock is not
 * already held, and we try to avoid acquiring it if possible.
 */
void
XLogFlush(XLogRecPtr record)
{
...

	/*
	 * Now wait until we get the write lock, or someone else does the flush
	 * for us.
	 */
	for (;;)
	{
		XLogRecPtr	insertpos;

		/* read LogwrtResult and update local state */
		SpinLockAcquire(&XLogCtl->info_lck);
		if (WriteRqstPtr < XLogCtl->LogwrtRqst.Write)
			WriteRqstPtr = XLogCtl->LogwrtRqst.Write;
		LogwrtResult = XLogCtl->LogwrtResult;
		SpinLockRelease(&XLogCtl->info_lck);

		/* done already? */
		if (record <= LogwrtResult.Flush)
			break;

		/*
		 * Before actually performing the write, wait for all in-flight
		 * insertions to the pages we're about to write to finish.
		 */
		insertpos = WaitXLogInsertionsToFinish(WriteRqstPtr);

		/*
		 * Try to get the write lock. If we can't get it immediately, wait
		 * until it's released, and recheck if we still need to do the flush
		 * or if the backend that held the lock did it for us already. This
		 * helps to maintain a good rate of group committing when the system
		 * is bottlenecked by the speed of fsyncing.
		 */
		if (!LWLockAcquireOrWait(WALWriteLock, LW_EXCLUSIVE))
		{
			/*
			 * The lock is now free, but we didn't acquire it yet. Before we
			 * do, loop back to check if someone else flushed the record for
			 * us already.
			 */
			continue;
		}

		/* Got the lock; recheck whether request is satisfied */
		LogwrtResult = XLogCtl->LogwrtResult;
		if (record <= LogwrtResult.Flush)
		{
			LWLockRelease(WALWriteLock);
			break;
		}

		/*
		 * Sleep before flush! By adding a delay here, we may give further
		 * backends the opportunity to join the backlog of group commit
		 * followers; this can significantly improve transaction throughput,
		 * at the risk of increasing transaction latency.
		 *
		 * We do not sleep if enableFsync is not turned on, nor if there are
		 * fewer than CommitSiblings other backends with active transactions.
		 */
		if (CommitDelay > 0 && enableFsync &&
			MinimumActiveBackends(CommitSiblings))
		{
			pg_usleep(CommitDelay);

			/*
			 * Re-check how far we can now flush the WAL. It's generally not
			 * safe to call WaitXLogInsertionsToFinish while holding
			 * WALWriteLock, because an in-progress insertion might need to
			 * also grab WALWriteLock to make progress. But we know that all
			 * the insertions up to insertpos have already finished, because
			 * that's what the earlier WaitXLogInsertionsToFinish() returned.
			 * We're only calling it again to allow insertpos to be moved
			 * further forward, not to actually wait for anyone.
			 */
			insertpos = WaitXLogInsertionsToFinish(insertpos);
		}

		/* try to write/flush later additions to XLOG as well */
		WriteRqst.Write = insertpos;
		WriteRqst.Flush = insertpos;

		XLogWrite(WriteRqst, false);

		LWLockRelease(WALWriteLock);
		/* done */
		break;
	}
...
} 

XLogFlush函数是刷脏WAL的主要函数：

判断需要flush的脏WAL是否已经被其他人flush了，如是，则直接返回
尝试以排他模式获得锁WALWriteLock，不断尝试，直到获得锁为止
拿到锁了，再次检查需要flush的脏WAL是否已经被其他人flush了，如是，则释放WALWriteLock，然后返回（申请锁期间也有可能脏WAL被其他人flush，如果是当然什么也不用做）
等待commit_delay毫秒且并发提交事务数大于commit_siblings，更新wal的写入点，形成组提交。这一步目前走不到，因为CommitDelay默认为0，相当于没有打开组提交
调用XLogWrite写日志，写完释放WALWriteLock

XLogFlush刷脏wal需要判断当前请求的脏wal是不是已经写了，如果没写，会持有WALWriteLock直到XLogWrite函数日志写入完成。XLogWrite是写wal的具体函数，如写如到哪个page的哪个位置。

回到之前活动会话的等待事件上。IO:WALWrite等待IO比较好理解，LWLOCK:WALWrite怎么去确认是不是问题呢？从XLogFlush函数逻辑可知，WALWriteLock是pg在写脏wal时申请的排他LWlock（这很好理解，wal的提交信息是顺序写的，只能给排他模式写，不能谁写的快就谁写，不然数据容易出错），是串行的写wal提交信息。了解这部分逻辑再回去看pg_stat_activity，会发现IO:WALWrite只有1个，而LWLOCK:WALWrite有几十个。虽然不能直接看到LWLOCK的blocking chain，但是我们可以从源码中得知，LWLOCK:WALWrite在等待IO:WALWrite。

官方文档有一段关于XLogFlush和调整wal buffer的描述：

Normally, WAL buffers should be written and flushed by an XLogFlush request, which is made, for the most part, at transaction commit time to ensure that transaction records are flushed to permanent storage. On systems with high WAL output, XLogFlush requests might not occur often enough to prevent XLogInsertRecord from having to do writes. On such systems one should increase the number of WAL buffers by modifying the wal_buffers parameter. When full_page_writes is set and the system is very busy, setting wal_buffers higher will help smooth response times during the period immediately following each checkpoint.

正常情况下，wal buffer会被XLogFlush flush，例如事务提交写wal日志到磁盘上。如果wal日志量很大，但是XLogFlush触发不频繁（也就是全是大事务），就需要XLogInsertRecord写没有提交的wal record，也就是说wal_buffer不够用了，此时增大wal_buffer会稍微对系统的响应时间有帮助。

There are two commonly used internal WAL functions: XLogInsertRecord and XLogFlush. XLogInsertRecord is used to place a new record into the WAL buffers in shared memory. If there is no space for the new record, XLogInsertRecord will have to write (move to kernel cache) a few filled WAL buffers

结合XLogInsertRecord函数的一段描述:

	 * We have now done all the preparatory work we can without holding a
	 * lock or modifying shared state. From here on, inserting the new WAL
	 * record to the shared WAL buffer cache is a two-step process:
	 *
	 * 1. Reserve the right amount of space from the WAL. The current head of
	 *	 reserved space is kept in Insert->CurrBytePos, and is protected by
	 *	 insertpos_lck.
	 *
	 * 2. Copy the record to the reserved WAL space. This involves finding the
	 *	 correct WAL buffer containing the reserved space, and copying the
	 *	 record in place. This can be done concurrently in multiple processes.

XLogInsertRecord函数是用来将新的wal record到WAL buffer中的。

写入需要保留一定量的空间
拷贝wal record到保留的wal空间（应指的是wal buffer中的保留空间）。多个进程可并行执行

wal record拷贝到wal buffer是可以并行执行的。这很难称为瓶颈，因为是内存拷贝还有并行。而XLogFlush函数就不是了，XLogFlush写入的时候会一直持有一个排他LWlock。所以，在这种并发高的小事务场景中，提高wal buffer理论上效果不会太理想。

至此，可以排除wal_buffers内存调整，把关注点放在IO上。再看pg_stat_activity的IO类相关等待个数：

DataFileRead	4
DataFileExtend	1
WALWrite		1
WALRead			1

insert value慢只持续了不到1分钟时间，平时没有异常。但是从平时的会话信息上看IO类的WALWrite等待基本都在

 pid | usename | xact_start | state_change | wait_event | wait_event_type | state | partofquery
-------+----------+-------------------------------+-------------------------------+---------------+-----------------+--------+--------------------------------------------------------------
 72668 | lzluser11 | 2024-05-23 09:32:20.828394+08 | 2024-05-23 09:32:20.82841+08 | WALWrite | IO | active | insert into table1( +
 77215 | lzluser11 | 2024-05-23 09:33:01.342541+08 | 2024-05-23 09:33:01.342552+08 | WALWrite | IO | active | insert into table1 +
 94904 | lzluser11 | 2024-05-23 09:34:32.442309+08 | 2024-05-23 09:34:32.442323+08 | WALWrite | IO | active | insert into table1 +
 88024 | lzluser11 | 2024-05-23 09:36:28.779086+08 | 2024-05-23 09:36:28.779311+08 | WALWrite | IO | active | UPDATE table2 SET +
 103236 | lzluser11 | 2024-05-23 09:37:04.144283+08 | 2024-05-23 09:37:04.144302+08 | WALWrite | IO | active | insert into table1 +
 47342 | lzluser11 | 2024-05-23 09:37:09.192683+08 | 2024-05-23 09:37:09.192699+08 | WALWrite | IO | active | insert into table1 +
 75399 | lzluser11 | 2024-05-23 09:45:30.743023+08 | 2024-05-23 09:45:30.743024+08 | WALWrite | IO | active | update table1 +
 221993 | lzluser11 | 2024-05-23 09:46:16.184532+08 | 2024-05-23 09:46:16.184541+08 | WALWrite | IO | active | insert into table1 

然而检查当时IO性能，写入15M/s并不高，与其他时间段相比甚至比较低，w_await同样很低

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
dm-322 0.00 0.00 187.00 1515.00 3572.00 15344.00 22.23 2.05 1.20 9.39 0.18 0.15 25.70

没有强有力的证据显示是存储性能问题。

目前来看应是瞬时并发insert value小事务，对flush wal时的锁争用。可以排除以下选项:

并发小事务，不需要调整wal buffer
wal日志量不大，不需要开启日志压缩
FPI不多，不需要调整checkpoint
IO压力不大，不需要提升IO性能

至少可以有如下优化:

开启数据库组提交（怕背锅可不调整，需要再测试）
业务单个语句insert value语句合并提交，减少WALWriteLock锁争用

案例-pg中的谓词越界和prepare statement问题

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

现象
#

案例：执行计划发生变化，plan选择了错误的索引，sql由毫秒级变成秒级。后面收集统计信息后，业务sql还是慢，最后通过删除DAILY_DATE时间索引建立(DAILY_DATE,A_ID)组合索引才解决。疑问：

优化器为什么选择DAILY_DATE索引，而不是选择率更好的A_ID索引？
收集统计信息后为什么没有效果？

统计信息过旧
#

--简化后的sql
select
 *
 from tablzl
 where A_ID = $1
 AND IS_DELETE = 'N'
 AND DAILY_DATE = to_date($2, 'yyyyMMdd')
 and PARTITION_KEY >= $3 
 and PARTITION_KEY <= $4

优化器选择DAILY_DATE索引而不是过滤性比较好的A_ID

Append (cost=0.44..8.83 rows=2 width=204)
 -> Index Scan using tablzl_p202401_DAILY_DATE_idx on tablzl_p202401 tablzl_1 (cost=0.44..5.47 rows=1 width=203)
 Index Cond: (DAILY_DATE = to_date('20240223'::text, 'yyyyMMdd'::text))
 Filter: ((partition_key >= 202401) AND (partition_key <= 202402) AND ((A_ID)::text = 'ID1234567890987654321'::text) AND ((is_delete)::text = 'N'::text))
 -> Index Scan using tablzl_p202402_DAILY_DATE_idx on tablzl_p202402 tablzl_2 (cost=0.44..3.35 rows=1 width=204)
 Index Cond: (DAILY_DATE = to_date('20240223'::text, 'yyyyMMdd'::text))
 Filter: ((partition_key >= 202401) AND (partition_key <= 202402) AND ((A_ID)::text = 'ID1234567890987654321'::text) AND ((is_delete)::text = 'N'::text))

对于p202401分区，走DAILY_DATE还是A_ID索引，差别不大，因为1月分区没有2月23日的数据
对于p202402分区，走DAILY_DATE还是A_ID索引，差别很大。走DAILY_DATE索引，它的预估cost=3.35，rows=1，实际上有上百万的数据，跑了2秒

p202402的统计信息中有MCV：

= select * from pg_stats where tablename='tablzl_p202402' and attname='DAILY_DATE' \gx
most_common_vals | {2024-02-21,2024-02-20,2024-02-22,2024-02-10,2024-02-15,2024-02-19,2024-02-16,2024-02-18,2024-02-17,2024-02-14,2024-02-11,2024-02-07,2024-02-12,2024-02-06,2024-02-08,2024-.
 |.02-09,2024-02-03,2024-02-05,2024-02-01,2024-02-02,2024-01-31,2024-02-13,2024-02-04}
most_common_freqs | {0.0481,0.047766667,0.0466,0.0449,0.0441,0.043833334,0.043733332,0.043466665,0.043133333,0.043066666,0.042366665,0.041866668,0.041366667,0.041366667,0.039766666,0.0394,0.039333332,0..
 |.038766667,0.03863333,0.0381,0.038066667,0.037966665,0.037566666,0.036733333}

计算MCV的总频率sum(most_common_freqs)

= select 0.0481+0.047766667+0.0466+0.0449+0.0441+0.043833334+0.043733332+0.043466665+0.043133333+0.043066666+0.042366665+0.041866668+0.041366667+0.041366667+0.039766666+0.0394+0.039333332+0.038766667+0.03863333+0.0381+0.038066667+0.037966665+0.037566666+0.036733333;
 ?column? 
-------------
 0.999999990

刚好是1，代表1-22日就是这个分区的所有数据（预估），23日的数据应该是0条，所以planner在预估23日的数据时rows=1，所以选择了DAILY_DATE索引。实际上23日的数据有百万条。本质上这是一个统计信息过久造成的问题。为什么前22天没有问题而且23日没有触发自动收集呢？

= select relname,reloptions from pg_class where relname='tablzl';
 relname | reloptions 
----------------------------+------------
 tablzl | [null]

= show autovacuum_analyze_scale_factor;
 autovacuum_analyze_scale_factor 
---------------------------------
 0.1

触发阈值默认是0.1，数据变化达到1/10的时候才会触发自动analyze。这是一个月分区，数据是每天插入和更新的，月初时1天写入200w数据，因为数据存量少，会触发多次analyze（threshold默认50可以忽略不记），而在月末时，比如23日，1天写入200w数据，不会触发analyze，因为只写了1/23。这个场景中插入后还会更新，插入200w更新200w，所以23日的数据变化是1/11左右，刚好不会触发analyze，这也能解释前20天运行稳定。另外，因为数据量的变化阈值是一个比例，每天的数据量的变化只要是比较均匀的，都会有这个月末统计信息不准的问题！

执行计划缓存
#

因为是统计信息过旧问题，手动收集统计信息理应解决这个问题，实际上收集了以后业务sql还是慢。 analyze了以后，手动explain analyze 执行计划却是正确的。说明analyze应该是有用的，但是没有影响到业务会话。由于sql执行用的是长会话，怀疑jdbc中使用prepare statement缓存执行计划（jdbc prepare statement）。而prepare statement在pg13（rasesql 1.3）中，收集统计信息不会失效，只能通过重连会话的方式重写解析。 prepare statement会生产一个通用执行计划（generic plan），由于统计信息不准确，通用执行计划跟传参执行计划一样，可以选择错误的索引

prepare statement的特性
#

psql支持prepare statement，由plan_cache_mode参数控制

auto：默认，五次机制处理
force_custom_plan：永远进行硬解析，生成custom plan
force_generic_plan：永远使用generic plan，绑定变量

使用语法：

PREPARE plan1(text,integer) AS select * from tlzl1 where id=$1 and month=$2;
EXECUTE plan1('256ac66bb53d31bc6124294238d6410c','11');

deallocate plan1|all; --使prepare失效，断开会话也可以

视图：（基本没用，因为是本地的，生产可看不到东西）

select * from pg_prepared_statements;

generic plan是怎么生成的
#

正常来说prepare语句跑5次是可以生成generic plan的。网上很多演示，这里就不演示正常情况了，以下是我测试出的“神奇”现象

--准备数据
create table tlzl1(id varchar(50),month int);
INSERT INTO tlzl1 SELECT md5(g::text),EXTRACT(month FROM g)
FROM generate_series('2023-01-01'::date, '2023-11-30'::date, '1 minute') as g;
create index idx_id on tlzl1(id);
create index idx_month on tlzl1(month);
analyze tlzl;

--执行prepare语句
PREPARE plan1(text,integer) AS 
select * from tlzl1 where id=$1 and month=$2;
EXECUTE plan1('256ac66bb53d31bc6124294238d6410c','11');
explain analyze EXECUTE plan1('256ac66bb53d31bc6124294238d6410c','11');

注意这里只插入11月前的数据，12月是没有数据的。此时查12月数据可以走到month索引

=# explain analyze EXECUTE plan1('256ac66bb53d31bc6124294238d6410c','12');
 QUERY PLAN 
------------------------------------------------------------------------------------------------------------------
 Index Scan using idx_month on tlzl1 (cost=0.42..2.94 rows=1 width=37) (actual time=0.035..0.036 rows=0 loops=1)
 Index Cond: (month = 12)
 Filter: ((id)::text = '256ac66bb53d31bc6124294238d6410c'::text)
 Planning Time: 0.170 ms
 Execution Time: 0.058 ms
(5 rows)

Time: 0.551 ms
=# explain analyze EXECUTE plan1('256ac66bb53d31bc6124294238d6410c','12');
 QUERY PLAN 
------------------------------------------------------------------------------------------------------------------
 Index Scan using idx_month on tlzl1 (cost=0.42..2.94 rows=1 width=37) (actual time=0.021..0.021 rows=0 loops=1)
 Index Cond: (month = 12)
 Filter: ((id)::text = '256ac66bb53d31bc6124294238d6410c'::text)
 Planning Time: 0.168 ms
 Execution Time: 0.046 ms
(5 rows)

Time: 0.488 ms
=# explain analyze EXECUTE plan1('256ac66bb53d31bc6124294238d6410c','12');
 QUERY PLAN 
------------------------------------------------------------------------------------------------------------------
 Index Scan using idx_month on tlzl1 (cost=0.42..2.94 rows=1 width=37) (actual time=0.017..0.018 rows=0 loops=1)
 Index Cond: (month = 12)
 Filter: ((id)::text = '256ac66bb53d31bc6124294238d6410c'::text)
 Planning Time: 0.157 ms
 Execution Time: 0.040 ms
(5 rows)

Time: 0.419 ms
=# explain analyze EXECUTE plan1('256ac66bb53d31bc6124294238d6410c','12');
 QUERY PLAN 
------------------------------------------------------------------------------------------------------------------
 Index Scan using idx_month on tlzl1 (cost=0.42..2.94 rows=1 width=37) (actual time=0.019..0.020 rows=0 loops=1)
 Index Cond: (month = 12)
 Filter: ((id)::text = '256ac66bb53d31bc6124294238d6410c'::text)
 Planning Time: 0.160 ms
 Execution Time: 0.044 ms
(5 rows)

Time: 0.479 ms
=# explain analyze EXECUTE plan1('256ac66bb53d31bc6124294238d6410c','12');
 QUERY PLAN 
------------------------------------------------------------------------------------------------------------------
 Index Scan using idx_month on tlzl1 (cost=0.42..2.94 rows=1 width=37) (actual time=0.018..0.018 rows=0 loops=1)
 Index Cond: (month = 12)
 Filter: ((id)::text = '256ac66bb53d31bc6124294238d6410c'::text)
 Planning Time: 0.155 ms
 Execution Time: 0.041 ms
(5 rows)

Time: 0.426 ms
--第六次
=# explain analyze EXECUTE plan1('256ac66bb53d31bc6124294238d6410c','12');
 QUERY PLAN 
---------------------------------------------------------------------------------------------------------------
 Index Scan using idx_id on tlzl1 (cost=0.42..5.44 rows=1 width=37) (actual time=0.044..0.045 rows=0 loops=1)
 Index Cond: ((id)::text = $1)
 Filter: (month = $2)
 Rows Removed by Filter: 1
 Planning Time: 0.023 ms
 Execution Time: 0.079 ms
(6 rows)

第六次绑定了generic plan，但是并不是前五次的plan，走的是id索引。如果id的重复度再高点的话，也可以测出来绑不上generic plan的场景（未展示）。这里就要看下源码了 choose_custom_plan

static bool

choose_custom_plan(CachedPlanSource *plansource, ParamListInfo boundParams)

{
...
	/* Generate custom plans until we have done at least 5 (arbitrary) */
	if (plansource->num_custom_plans < 5)
		return true;

	avg_custom_cost = plansource->total_custom_cost / plansource->num_custom_plans;

	/*
	 * Prefer generic plan if it's less expensive than the average custom
	 * plan. (Because we include a charge for cost of planning in the
	 * custom-plan costs, this means the generic plan only has to be less
	 * expensive than the execution cost plus replan cost of the custom
	 * plans.)
	 *
	 * Note that if generic_cost is -1 (indicating we've not yet determined
	 * the generic plan cost), we'll always prefer generic at this point.
	 */
	if (plansource->generic_cost < avg_custom_cost)
		return false;

	return true;
}		

只要generic plan的cost 小于前5次的custom_cost平均值，那么就使用generic plan。虽然5次机制众所周知，但是需要注意generic plan是怎么生成的。第5次时还没有generic plan（刚开始的时候），generic_cost=-1，会直接返回GetCachedPlan中的!customplan逻辑

CachedPlan *
GetCachedPlan(CachedPlanSource *plansource, ParamListInfo boundParams,
			 bool useResOwner, QueryEnvironment *queryEnv)
{
...
	customplan = choose_custom_plan(plansource, boundParams);

	if (!customplan)
	{
		if (CheckCachedPlan(plansource))
		{
			/* We want a generic plan, and we already have a valid one */
			plan = plansource->gplan;
			Assert(plan->magic == CACHEDPLAN_MAGIC);
		}
		else
		{
			/* Build a new generic plan */
			plan = BuildCachedPlan(plansource, qlist, NULL, queryEnv);
			/* Just make real sure plansource->gplan is clear */
			ReleaseGenericPlan(plansource);
			/* Link the new generic plan into the plansource */
			plansource->gplan = plan;
			plan->refcount++;
			/* Immediately reparent into appropriate context */
			if (plansource->is_saved)
			{
				/* saved plans all live under CacheMemoryContext */
				MemoryContextSetParent(plan->context, CacheMemoryContext);
				plan->is_saved = true;
			}
			else
			{
				/* otherwise, it should be a sibling of the plansource */
				MemoryContextSetParent(plan->context,
									 MemoryContextGetParent(plansource->context));
			}
			/* Update generic_cost whenever we make a new generic plan */
			plansource->generic_cost = cached_plan_cost(plan, false);

			/*
			 * If, based on the now-known value of generic_cost, we'd not have
			 * chosen to use a generic plan, then forget it and make a custom
			 * plan. This is a bit of a wart but is necessary to avoid a
			 * glitch in behavior when the custom plans are consistently big
			 * winners; at some point we'll experiment with a generic plan and
			 * find it's a loser, but we don't want to actually execute that
			 * plan.
			 */
			customplan = choose_custom_plan(plansource, boundParams);

			/*
			 * If we choose to plan again, we need to re-copy the query_list,
			 * since the planner probably scribbled on it. We can force
			 * BuildCachedPlan to do that by passing NIL.
			 */
			qlist = NIL;
		}
	}
	...
	return plan;
}	

!customplan逻辑中，如果有generic plan直接使用，没有的话通过BuildCachedPlan生成一个plan，BuildCachedPlan就是生成plan的主体逻辑，通过query tree生成plan tree。没有参数怎么办？注释已经说明，没有参数就传NULL进去，到生成plan的逻辑

To build a generic, parameter-value-independent plan, pass NULL for
 * boundParams. To build a custom plan, pass the actual parameter values via
 * boundParams

传NULL优化器更prefer什么执行计划？这部分代码逻辑有些复杂。从优化器的角度考虑，可能是有多个plan可以选择的，但总得选一个作为generic plan 而选出来那个generic plan，才可以对比前5次的plan cost。为什么用更低cost的执行计划反复执行，没有生成想要的generic plan？ generic plan长什么样跟前五次的执行计划没有关系，前五次只是决定了是否绑定这个generic plan。

从优化器设计的角度来考虑，generic plan是为了减少解析时间提高sql执行效率，适合多而小的查询。问题在于generic plan本身很粗糙，postgres引进五次机制就是为了来减少generic plan本身是稀烂的可能性。即使有五次机制，还是导致绑定的烂generic plan的原因：

generic plan也是plan，本身就可能烂
统计信息不准确，generic plan的cost预估很低
前五次的传参选择率低（或其他影响）导致custom plan cost高

prepare statement的失效
#

除了DDL、deallocate、断开会话，收集统计信息也会让prepared statement，不过这是pg14的特性。 pg13:

PostgreSQL will force re-analysis and re-planning of the statement before using it whenever database objects used in the statement have undergone definitional (DDL) changes since the previous use of the prepared statement

pg14:

PostgreSQL will force re-analysis and re-planning of the statement before using it whenever database objects used in the statement have undergone definitional (DDL) changes or their planner statistics have been updated since the previous use of the prepared statement

pg13 收集统计信息不会让prepare statement失效的测试：

= explain analyze EXECUTE plan1('256ac66bb53d31bc6124294238d6410c','11');
 QUERY PLAN 
---------------------------------------------------------------------------------------------------------------
 Index Scan using idx_id on tlzl1 (cost=0.42..5.44 rows=1 width=37) (actual time=0.033..0.033 rows=0 loops=1)
 Index Cond: ((id)::text = $1)
 Filter: (month = $2)
 Rows Removed by Filter: 1
 Planning Time: 0.098 ms
 Execution Time: 0.050 ms
(6 rows)

= select * from pg_prepared_statements;
 name | statement | prepare_time | parameter_types | from_sql 
-------+-----------------------------------------------+-------------------------------+-----------------+----------
 plan1 | PREPARE plan1(text,integer) AS +| 2024-02-29 14:27:59.966733+08 | {text,integer} | t
 | select * from tlzl1 where id=$1 and month=$2; | | | 
(1 row)

= analyze tlzl1;
ANALYZE
= select * from pg_prepared_statements;
 name | statement | prepare_time | parameter_types | from_sql 
-------+-----------------------------------------------+-------------------------------+-----------------+----------
 plan1 | PREPARE plan1(text,integer) AS +| 2024-02-29 14:27:59.966733+08 | {text,integer} | t
 | select * from tlzl1 where id=$1 and month=$2; | | | 
(1 row)

= explain analyze EXECUTE plan1('256ac66bb53d31bc6124294238d6410c','11');
 QUERY PLAN 
---------------------------------------------------------------------------------------------------------------
 Index Scan using idx_id on tlzl1 (cost=0.42..5.44 rows=1 width=37) (actual time=0.051..0.052 rows=0 loops=1)
 Index Cond: ((id)::text = $1)
 Filter: (month = $2)
 Rows Removed by Filter: 1
 Planning Time: 0.022 ms
 Execution Time: 0.098 ms
(6 rows)

jdbc的prepare statement
#

prepare statement不是PG的独有功能，一些数据库也有相关的预解析特性，比如oracle也可以实现类似的功能。 jdbc自身也可以调用数据库的预解析接口，直接显示使用 prepare statement。 jdbc参考配置：

String sql = "select * from people where id=?";

PreparedStatement preparedStatement =
 connection.prepareStatement(sql);

建议
#

调小表级的autovacuum_analyze_scale_factor=0.02（why 0.02？0.02<1/31)。因为是边写边查，手动收集不太好定时间，调小autovacuum_analyze_scale_factor只能减缓这个问题。
考虑去掉jdbc中的prepare设置，或者设置force_custom_plan
调整sql逻辑
调整索引。4.1删除不必要的时间索引；4.2将越界后走的索引重建为包含id字段的组合索引（一个不错的建议）。
应急流程：统计信息收集后业务未恢复的情况，确认手动explain执行计划改变的情况下，可以考虑杀会话(13以前)。

最后，谓词越界问题基本上在所有数据库中都有，特别是在时间字段上。现有手段其实没有一个比较简单又能完美解决的办法，oracle的SPM好感度又+1…

案例：逻辑复制把checkpoint、walsender、backup全部卡死

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

问题现象
#

备份进程命令pg_start_backup()被checkpoint进程阻塞，checkpoint被逻辑复制walsender进程阻塞。业务虽然还在继续运行，但是备份、checkpoint、逻辑复制全部hang死。

pg_stat_activity 中有两个明显异常的等待事件：replication_slot_io 。

[postgres@hostlzl:6666/postgres][04-08.16:50:28]=> select * from pg_stat_activity where pid=173038 \gx
-[ RECORD 1 ]----+------------------------------
datid | 17630
datname | lzldb
pid | 173038
usesysid | 35157
usename | repuser
application_name | PostgreSQL JDBC Driver
client_addr | 30.88.75.58
client_hostname | [null]
client_port | 37623
backend_start | 2024-04-02 11:40:07.75022+08
xact_start | [null]
query_start | [null]
state_change | 2024-04-02 11:40:07.764475+08
wait_event_type | LWLock
wait_event | replication_slot_io
state | active
backend_xid | [null]
backend_xmin | [null]
query | 
backend_type | walsender

Time: 6.658 ms
[postgres@hostlzl:6666/postgres][04-08.16:50:34]=> select * from pg_stat_activity where pid=12729\gx
-[ RECORD 1 ]----+------------------------------
datid | [null]
datname | [null]
pid | 12729
usesysid | [null]
usename | [null]
application_name | 
client_addr | [null]
client_hostname | [null]
client_port | [null]
backend_start | 2024-04-02 11:23:03.343116+08
xact_start | [null]
query_start | [null]
state_change | [null]
wait_event_type | LWLock
wait_event | replication_slot_io
state | [null]
backend_xid | [null]
backend_xmin | [null]
query | 
backend_type | checkpointer

一个是walsender进程，一个是checkpointer进程。都是4月2日启动的进程，直接查看4月2日walsender 173038的日志：

--repuser log
2024-04-02 11:40:07.750 CST,,,173038,"30.88.75.58:37623",660b7e17.2a3ee,1,"",2024-04-02 11:40:07 CST,,0,LOG,00000,"connection received: host=30.88.75.58 port=37623",,,,,,,,,""
2024-04-02 11:40:07.756 CST,"repuser","lzldb",173038,"30.88.75.58:37623",660b7e17.2a3ee,2,"authentication",2024-04-02 11:40:07 CST,32/30,0,LOG,00000,"replication connection authorized: user=repuser",,,,,,,,,""
2024-04-02 11:40:07.765 CST,"repuser","lzldb",173038,"30.88.75.58:37623",660b7e17.2a3ee,3,"idle",2024-04-02 11:40:07 CST,32/0,0,LOG,00000,"starting logical decoding for slot ""pg_lzldb_lzldb_ora_pgdb_pgdb""","Streaming transactions committing after 4263/42E6EF88, reading WAL from 4263/41DAEBD0.",,,,,,,,"PostgreSQL JDBC Driver"
2024-04-02 11:40:07.765 CST,"repuser","lzldb",173038,"30.88.75.58:37623",660b7e17.2a3ee,4,"idle",2024-04-02 11:40:07 CST,32/0,0,LOG,00000,"logical decoding found consistent point at 4263/41DAEBD0","There are no running transactions.",,,,,,,,"PostgreSQL JDBC Driver"

173038这个walsender进程只能看到start启动链路信息，后面这个walsender再也没有输出过日志，很有可能从那个时候起开始hang了。不过再往前翻一点，还可以看到相同复制链路的walsender信息（walsender进程号不同，slot name相同）：

--84918 之前的启动日志
2024-04-02 11:30:07.498 CST,,,84918,"30.88.75.58:54898",660b7bbf.14bb6,1,"",2024-04-02 11:30:07 CST,,0,LOG,00000,"connection received: host=30.88.75.58 port=54898",,,,,,,,,""
2024-04-02 11:30:07.504 CST,"repuser","lzldb",84918,"30.88.75.58:54898",660b7bbf.14bb6,2,"authentication",2024-04-02 11:30:07 CST,30/3,0,LOG,00000,"replication connection authorized: user=repuser",,,,,,,,,""
2024-04-02 11:30:07.514 CST,"repuser","lzldb",84918,"30.88.75.58:54898",660b7bbf.14bb6,3,"idle",2024-04-02 11:30:07 CST,30/0,0,LOG,00000,"starting logical decoding for slot ""pg_lzldb_lzldb_ora_pgdb_pgdb""","Streaming transactions committing after 4263/41DADE38, reading WAL from 4263/358F1340.",,,,,,,,"PostgreSQL JDBC Driver"
2024-04-02 11:30:07.516 CST,"repuser","lzldb",84918,"30.88.75.58:54898",660b7bbf.14bb6,4,"idle",2024-04-02 11:30:07 CST,30/0,0,LOG,00000,"logical decoding found consistent point at 4263/358F1340","There are no running transactions.",,,,,,,,"PostgreSQL JDBC Driver"

2024-04-02 11:36:07.061 CST,"repuser","lzldb",86630,"30.88.75.58:45227",660b7bca.15266,5,"idle",2024-04-02 11:30:18 CST,30/0,0,ERROR,XX000,"could not write to file ""pg_replslot/pg_lzldb_lzldb_ora_pgdb_pgdb/state.tmp"": Cannot allocate memory",,,,,,,,,"PostgreSQL JDBC Driver"
2024-04-02 11:36:40.151 CST,"repuser","lzldb",86630,"30.88.75.58:45227",660b7bca.15266,6,"idle",2024-04-02 11:30:18 CST,,0,LOG,00000,"disconnection: session time: 0:06:21.760 user=repuser database=lzldb host=30.88.75.58 port=45227",,,,,,,,,"PostgreSQL JDBC Driver"

这个复制槽在11:30:07也启动过一次，并且过了6分钟后，因为内存打满导致写入state.tmp失败。同样的，上面查出来的checkpoint进程12729，也报了相同的state.tmp文件错误pg_replslot/pg_lzldb_lzldb_ora_pgdb_pgdb/state.tmp"": File exists"，该报错在复制槽报错后的半分钟出现：

--checkpoint log
2024-04-02 11:36:39.925 CST,,,12729,,660b7a17.31b9,4,,2024-04-02 11:23:03 CST,,0,LOG,58P02,"could not create file ""pg_replslot/pg_lzldb_lzldb_ora_pgdb_pgdb/state.tmp"": File exists",,,,,,,,,""
2024-04-02 11:36:40.151 CST,,,12729,,660b7a17.31b9,5,,2024-04-02 11:23:03 CST,,0,LOG,00000,"checkpoint complete: wrote 334 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.108 s, sync=0.082 s, total=217.083 s; sync files=139, longest=0.004 s, average=0.000 s; distance=2295 kB, estimate=2295 kB",,,,,,,,,""
2024-04-02 11:48:03.414 CST,,,12729,,660b7a17.31b9,6,,2024-04-02 11:23:03 CST,,0,LOG,00000,"checkpoint starting: time",,,,,,,,,""

checkpoint此后再也没有出现过日志输出，看起来跟walsender一样，hang住了。

通过搜索pg_replslot/pg_lzldb_lzldb_ora_pgdb_pgdb/state.tmp"": File exists"可以快速又简单的找到社区邮件：https://www.postgresql.org/message-id/14b3454f-2d68-c637-68e4-2b42ff976168%40postgrespro.ru 它真正的修复版本是PG12.3：

Ensure that a replication slot’s io_in_progress_lock is released in failure code paths (Pavan Deolasee) This could result in a walsender later becoming stuck waiting for the lock.

深入分析
#

虽然找到了bug，但其实很多问题没有搞清楚：

walsender和checkpoints为什么hang住了？
walsender和checkpoints是谁阻塞了谁？
怎么触发的？
有什么解决方案？

源码分析
#

当前版本为11.5。

walsender和checkpointer两个进程的的pstack：

[postgres@hostlzl:lzldb:6666: /pg/pg6666/data/pg_log]$ pstack 173038 ##walsender
#0 0x00002b9eec171a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0
#1 0x00002b9eec171a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0
#2 0x00002b9eec171b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0
#3 0x00000000006b2512 in PGSemaphoreLock (sema=0x2b9ef5fdb0b8) at pg_sema.c:316
#4 0x000000000071e94c in LWLockAcquire (lock=lock@entry=0x2babd8cee5b8, mode=mode@entry=LW_EXCLUSIVE) at lwlock.c:1243
#5 0x00000000006ef7cb in SaveSlotToPath (slot=0x2babd8cee500, dir=dir@entry=0x7ffcaffd79f0 "pg_replslot/pg_lzldb_lzldb_ora_pgdb_pgdb", elevel=elevel@entry=20) at slot.c:1249
#6 0x00000000006f0515 in ReplicationSlotSave () at slot.c:653
#7 0x00000000006d75d8 in LogicalConfirmReceivedLocation (lsn=<optimized out>) at logical.c:1049
#8 0x00000000006d774d in LogicalIncreaseXminForSlot (current_lsn=current_lsn@entry=72994075200640, xmin=xmin@entry=1241611955) at logical.c:914
#9 0x00000000006e0fb3 in SnapBuildProcessRunningXacts (builder=builder@entry=0x23146c0, lsn=72994075200640, running=running@entry=0x22e8978) at snapbuild.c:1146
#10 0x00000000006d484c in DecodeStandbyOp (buf=0x7ffcaffd7eb0, buf=0x7ffcaffd7eb0, ctx=0x2209820) at decode.c:318
#11 LogicalDecodingProcessRecord (ctx=0x2209820, record=<optimized out>) at decode.c:121
#12 0x00000000006e50e0 in XLogSendLogical () at walsender.c:2799
#13 0x00000000006e7122 in WalSndLoop (send_data=send_data@entry=0x6e5080 <XLogSendLogical>) at walsender.c:2162
#14 0x00000000006e7d91 in StartLogicalReplication (cmd=0x22eedd8) at walsender.c:1109
#15 exec_replication_command (cmd_string=cmd_string@entry=0x2210c48 "START_REPLICATION SLOT pg_lzldb_lzldb_ora_pgdb_pgdb LOGICAL 4263/42E6EF88 (\"add-tables\" 'public.acr_finance_coa_partition_17_01,public.acr_finance_coa_partition_17_02,public.acr_finance_coa_part"...) at walsender.c:1541
#16 0x000000000072c899 in PostgresMain (argc=<optimized out>, argv=argv@entry=0x2216f78, dbname=0x2216c98 "lzldb", username=<optimized out>) at postgres.c:4178
#17 0x000000000047e481 in BackendRun (port=0x220eda0) at postmaster.c:4358
#18 BackendStartup (port=0x220eda0) at postmaster.c:4030
#19 ServerLoop () at postmaster.c:1707
#20 0x00000000006c4359 in PostmasterMain (argc=argc@entry=3, argv=argv@entry=0x21dbe90) at postmaster.c:1380
#21 0x000000000047eefb in main (argc=3, argv=0x21dbe90) at main.c:228


[postgres@hostlzl:lzldb:6666: /pg/pg6666/data/pg_wal]$ pstack 12729 ##checkpointer
#0 0x00002b9eec171a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0
#1 0x00002b9eec171a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0
#2 0x00002b9eec171b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0
#3 0x00000000006b2512 in PGSemaphoreLock (sema=0x2b9ef5fdcd38) at pg_sema.c:316
#4 0x000000000071e94c in LWLockAcquire (lock=lock@entry=0x2babd8cee5b8, mode=mode@entry=LW_EXCLUSIVE) at lwlock.c:1243
#5 0x00000000006ef7cb in SaveSlotToPath (slot=slot@entry=0x2babd8cee500, dir=dir@entry=0x7ffcaffd6ee0 "pg_replslot/pg_lzldb_lzldb_ora_pgdb_pgdb", elevel=elevel@entry=15) at slot.c:1249
#6 0x00000000006f11a7 in CheckPointReplicationSlots () at slot.c:1100
#7 0x00000000004f674f in CheckPointGuts (checkPointRedo=72994093982360, flags=flags@entry=128) at xlog.c:9146
#8 0x00000000004fcc77 in CreateCheckPoint (flags=flags@entry=128) at xlog.c:8937
#9 0x00000000006b8312 in CheckpointerMain () at checkpointer.c:491
#10 0x000000000050ba15 in AuxiliaryProcessMain (argc=argc@entry=2, argv=argv@entry=0x7ffcaffd7540) at bootstrap.c:451
#11 0x00000000006c1cb9 in StartChildProcess (type=CheckpointerProcess) at postmaster.c:5337
#12 0x00000000006c2f5a in reaper (postgres_signal_arg=<optimized out>) at postmaster.c:2867
#13 <signal handler called>
#14 0x00002b9eed5ba783 in __select_nocancel () from /lib64/libc.so.6
#15 0x000000000047db38 in ServerLoop () at postmaster.c:1671
#16 0x00000000006c4359 in PostmasterMain (argc=argc@entry=3, argv=argv@entry=0x21dbe90) at postmaster.c:1380
#17 0x000000000047eefb in main (argc=3, argv=0x21dbe90) at main.c:228

最值得注意的是LWLockAcquire这行的堆栈，walsender和checkpointer都有这样的进栈，并且他们俩都以排他模式申请了同一个LWLOCK地址：lock=lock@entry=0x2babd8cee5b8, mode=mode@entry=LW_EXCLUSIVE，进入无限期的等待··· LWLockAcquire的上一个堆栈函数便是SaveSlotToPath。

在src/backend/replication/slot.c中找到关键问题函数源码SaveSlotToPath：

//SaveSlotToPath用于存储slot的状态
static void
SaveSlotToPath(ReplicationSlot *slot, const char *dir, int elevel)
{	//11.5代码
	char		tmppath[MAXPGPATH];
	char		path[MAXPGPATH];
	int			fd;
	ReplicationSlotOnDisk cp;
	bool		was_dirty;
...
	/* and don't do anything if there's nothing to write */
	if (!was_dirty)
		return;
	//函数开头获得LWLock，排他模式
	LWLockAcquire(&slot->io_in_progress_lock, LW_EXCLUSIVE);

...
	//注意fd的逻辑，报错与第二次walsender报错一致
	fd = OpenTransientFile(tmppath, O_CREAT | O_EXCL | O_WRONLY | PG_BINARY);
	if (fd < 0)
	{
		ereport(elevel,
				(errcode_for_file_access(),
				 errmsg("could not create file \"%s\": %m",
						tmppath)));
		return;
...
	//写入fd文件的逻辑，报错与首次walsender报错一致
	if ((write(fd, &cp, sizeof(cp))) != sizeof(cp))
	{
		int			save_errno = errno;

		pgstat_report_wait_end();
		CloseTransientFile(fd);

		/* if write didn't set errno, assume problem is no disk space */
		errno = save_errno ? save_errno : ENOSPC;
		ereport(elevel,
				(errcode_for_file_access(),
				 errmsg("could not write to file \"%s\": %m",
						tmppath)));
		return;
	}
...
	LWLockRelease(&slot->io_in_progress_lock);	//函数最后释放LWLock
	}

SaveSlotToPath函数上来就获取LWLockAcquire，传入slot地址，命名跟等待事件非常类似：io_in_progress_lock<-> replication_slot_io，以LW_EXCLUSIVE模式申请LWLOCK。在SaveSlotToPath函数最后有LWLockRelease释放LWLOCK。 但是，在所有if判断中，没有任何LWLockRelease，直接return！！！

而pg日志中的输出就是“could not create file” tmppath，说明代码就是走到了以上两个if逻辑里，也就是写入state.tmp失败和创建state.tmp失败的if逻辑中。

联系pglog中的报错顺序：

11:36:07：逻辑复制首次报错"could not write to file ““pg_replslot/pg_lzldb_lzldb_ora_pgdb_pgdb/state.tmp”，复制链路挂掉
11:36:39：checkpointer进程报错"could not create file ““pg_replslot/pg_lzldb_lzldb_ora_pgdb_pgdb/state.tmp”，并于1秒后“complete”，写入0个脏块，0条wal
11:40:07：逻辑复制再次启动，启动后再无输出
11:48:03：checkpointer进程再次触发start，后续再无输出，后续再无输出

上面有两个逻辑复制和两个checkpointer的日志输出，这里要注意一个很重要的信息：第一次逻辑复制和第二次逻辑复制归属于不同的walsender进程；第一次checkpoint和第二次checkpoint信息归属于相同的checkpointer进程。

从以上信息总结出故障原理：

逻辑复制因内存问题，写入state.tmp失败，留下一个残存的state.tmp文件
checkpointer进程因残存的state.tmp文件，在SaveSlotToPath函数中，以排他模式获得LWLock后进入if (fd < 0)判断，不释放LWLock直接return
逻辑复制再次启动，walsender进程在SaveSlotToPath函数开头申请LWLock，开始无限期等待
checkpointer进程触发start checkpoint，checkpointer进程在SaveSlotToPath函数开头申请LWLock，开始无限期等待

故障原理理清后答案自然就很清楚：

walsender和checkpointer为什么hang住了？如上故障原理分析。残存的state.tmp，checkpointer持有LWLock未释放，walsender和checkpointer无限等待。
walsender和checkpointer是谁阻塞了谁？checkpointer阻塞walsender
怎么触发的？前一个walsender进程因为内存打满写了state.tmp未清理
有什么解决方案？强制重启数据库

复现
#

pg逻辑复制知识可参考pg内功修炼：逻辑复制，主要使用以下命令：

select pg_create_logical_replication_slot('logical_test','test_decoding');
pg_recvlogical -h 127.0.0.1 -p 5558 -d lzldb -U lzl --slot=logical_test --start -f recv.sql &

复制槽和逻辑复制链路就OK了：

postgres=# select pid,usename,xact_start,state_change,wait_event,state,query from pg_stat_activity where state<>'idle' order by xact_start ;
 pid | usename | xact_start | state_change | wait_event | state | query 
 
-------+----------+-------------------------------+-------------------------------+---------------------+--------+----------------------------------------------------------------------------------------------
--------------------------------------
 59916 | postgres | 2024-04-08 21:14:32.015534+08 | 2024-04-08 21:14:32.015545+08 | | active | select pid,usename,xact_start,state_change,wait_event,state,query from pg_stat_activity wher
e state<>'idle' order by xact_start ;
 59791 | lzl | | 2024-04-08 21:14:19.566112+08 | WalSenderWaitForWAL | active | SELECT pg_catalog.set_config('search_path', '', false)

postgres=# select pid,usename,application_name,backend_start,state,pg_walfile_name_offset(sent_lsn) sentoffset,pg_walfile_name_offset(write_lsn) writeoffset,pg_walfile_name_offset(flush_lsn) flushoffset from pg_stat_replication;
 pid | usename | application_name | backend_start | state | sentoffset | writeoffset | flushoffset 
-------+---------+------------------+------------------------------+-----------+------------------------------------+------------------------------------+------------------------------------
 59791 | lzl | pg_recvlogical | 2024-04-08 21:14:19.56364+08 | streaming | (000000010000000000000001,6612032) | (000000010000000000000001,6612032) | (000000010000000000000001,6612032)

因为是state.tmp文件引起的，直接在pg_replslot下面touch

[postgres@testhost logical_test]$ pwd
/pgdata/lzl/data11/pg_replslot/logical_test

pg_recvlogical立马报错：

 pg_recvlogical: unexpected termination of replication stream: ERROR: could not create file "pg_replslot/logical_test/state.tmp": File exists

手动执行checkpoint也会hang住

lzldb=# checkpoint;

--hang

在看下walsender和会话的状态：

postgres=> select * from pg_stat_activity ;
 datid | datname | pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | xact_start | query_start 
 | state_change | wait_event_type | wait_event | state | backend_xid | backend_xmin | query | backend_type 
-------+----------+-------+----------+----------+------------------+-------------+-----------------+-------------+-------------------------------+-------------------------------+------------------------------
-+-------------------------------+-----------------+---------------------+--------+-------------+--------------+--------------------------------------------------------+------------------------------
... 
 | | Activity | LogicalLauncherMain | | | | | logical replication launcher
 | 2024-04-08 21:25:55.058523+08 | | | active | | | checkpoint; | client backend
 16384 | lzldb | 77638 | 16385 | lzl | pg_recvlogical | 127.0.0.1 | | 56928 | 2024-04-08 21:25:17.495833+08 | | 2024-04-08 21:25:17.497754+08
 | 2024-04-08 21:25:17.498329+08 | LWLock | replication_slot_io | active | | | SELECT pg_catalog.set_config('search_path', '', false) | walsender
 | | LWLock | replication_slot_io | | | | | checkpointer

完美复现2个replication_slot_io 等待事件

PG12.3的代码已优化
#

//这里贴的是15.3，比12.3多一段save_errno
static void
SaveSlotToPath(ReplicationSlot *slot, const char *dir, int elevel)
{	
	fd = OpenTransientFile(tmppath, O_CREAT | O_EXCL | O_WRONLY | PG_BINARY);
	if (fd < 0)
	{
		/*
		 * If not an ERROR, then release the lock before returning. In case
		 * of an ERROR, the error recovery path automatically releases the
		 * lock, but no harm in explicitly releasing even in that case. Note
		 * that LWLockRelease() could affect errno.
		 */
		int			save_errno = errno;

		LWLockRelease(&slot->io_in_progress_lock);
		errno = save_errno;
		ereport(elevel,
				(errcode_for_file_access(),
				 errmsg("could not create file \"%s\": %m",
						tmppath)));
		return;
	}
...
LWLockRelease(&slot->io_in_progress_lock);

}	

在每一个 if中，在都会先运行LWLockRelease，然后再return。这样就不会某些场景下LWLock不释放的逻辑漏洞了，代码明显更为健壮。

解决办法分析
#

因为state.tmp文件只是诱因，LWLOCK已经持有了，删除state.tmp不会解决这个问题。因为真正持有LW_LOCK的人是checkpointer，所以重启复制链路或者kill下游都是也是没有用的。因为是checkpointer进程不能直接kill，目前这个状态除了重启没有好的解决办法，而且只有强制重启进行实例恢复，正常关库因为checkpoint阻塞是关不了的··· 最后，终极解决办法当然是升级到PG12.3以上。

（另外，我也试了下gdb调用LWLockRelease（LWLock的地址pstack已经输出了），直接把测试环境库搞挂了，所以就不推荐gdb了）

总结
#

PG在近期的版本中最为重要的特性提升之一就是逻辑复制，早期的PG的逻辑复制确实是存在很多问题，坑多。PG这种大包大揽的逻辑复制思路很有技术创新的精神，而且也能看到社区孜孜不倦地对逻辑复制的完善和加强，几乎每个小版本都能搜到逻辑复制的许多更新。这个案例就是一个现实的例子，逻辑复制的代码明显越来越健壮。逻辑复制的知识点其实挺多的，最后推荐一波之前的文章：pg内功修炼：逻辑复制

分区权限问题导致执行计划不正确

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

问题现象
#

业务昨晚对sql进行了更新，之前没有DATE_CREATED字段（是分区键），跑的很快。发版后加了分区字段，本身是为了减少分区数量的访问，但是加了以后UPDATE执行却变慢了。 before：

 update TABLE_RECORD
 set IS_DELETED = '1', DATE_UPDATED = LOCALTIMESTAMP(0)
 WHERE APPL_NO = $1
 AND IS_DELETED = '0'

after：

 update TABLE_RECORD
 set IS_DELETED = '1', DATE_UPDATED = LOCALTIMESTAMP(0)
 WHERE APPL_NO = $1
 AND IS_DELETED = '0'
 AND DATE_CREATED > now() - interval '31' day
 AND DATE_CREATED < now()

发版前访问时间是毫秒级，发版后访问时间是10s，sql运行频繁，业务不可接受。

问题分析
#

执行计划看上去是正确的
#

表结构如下

## \d+ TABLE_RECORD
 Partitioned table "public.TABLE_RECORD"
 Column | Type | Collation | Nullable | Default | Storage | Stats target | Description 
--------------------------------+-----------------------------+-----------+----------+---------------------------------------------------+----------+--------------+--------------------------
 id_TABLE_RECORD | character varying(32) | | not null | nextval('seq_TABLE_RECORD'::regclass) | extended | | 
 appl_no | character varying(100) | | | | extended | | 
 r_appl_no | character varying(100) | | | | extended | | 
...
 created_by | character varying(100) | | not null | 'sys'::character varying | extended | | 
 date_created | timestamp without time zone | | not null | now() | plain | | 
 updated_by | character varying(100) | | not null | 'sys'::character varying | extended | | 
 date_updated | timestamp without time zone | | not null | now() | plain | | 
Partition key: RANGE (date_created)
Indexes:
 "date_TABLE_RECORD" btree (date_created)
 "idx_dateupdated" btree (date_updated)
 "idx_applnodeleted" btree (appl_no, is_deleted)
 "nk_TABLE_RECORD" btree (appl_no)
Partitions: TABLE_RECORD_202211 FOR VALUES FROM ('2022-11-01 00:00:00') TO ('2022-12-01 00:00:00'),
...
 TABLE_RECORD_202303 FOR VALUES FROM ('2023-03-01 00:00:00') TO ('2023-04-01 00:00:00'),
 TABLE_RECORD_202304 FOR VALUES FROM ('2023-04-01 00:00:00') TO ('2023-05-01 00:00:00'),
 TABLE_RECORD_202305 FOR VALUES FROM ('2023-05-01 00:00:00') TO ('2023-06-01 00:00:00'),
 TABLE_RECORD_202306 FOR VALUES FROM ('2023-06-01 00:00:00') TO ('2023-07-01 00:00:00'),
 ...
 TABLE_RECORD_202512 FOR VALUES FROM ('2025-12-01 00:00:00') TO ('2026-01-01 00:00:00'),
 TABLE_RECORD_other DEFAULT

这个sql会访问近2个月的分区，这2个分区都是有数据的，上面的update只会更新一条数据。刚开始分析问题非常困惑，因为我们explain的时候，执行计划是没有问题的 explain分区扫描信息：

 -> Index Scan using TABLE_RECORD_202302_date_created_idx on TABLE_RECORD_202302 TABLE_RECORD_4 (cost=0.44..5.47 rows=1 width=485)
 Index Cond: ((date_created > (now() - '31 days'::interval day)) AND (date_created < now()))
 Filter: (((appl_no)::text = 'LZLMATH20230132302302'::text) AND ((is_deleted)::text = '0'::text))
 -> Index Scan using TABLE_RECORD_202303_date_created_idx on TABLE_RECORD_202303 TABLE_RECORD_5 (cost=0.44..5.47 rows=1 width=482)
 Index Cond: ((date_created > (now() - '31 days'::interval day)) AND (date_created < now()))
 Filter: (((appl_no)::text = 'LZLMATH20230132302302'::text) AND ((is_deleted)::text = '0'::text))
 -> Index Scan using TABLE_RECORD_202304_date_created_idx on TABLE_RECORD_202304 TABLE_RECORD_6 (cost=0.44..5.47 rows=1 width=481)
 Index Cond: ((date_created > (now() - '31 days'::interval day)) AND (date_created < now()))
 Filter: (((appl_no)::text = 'LZLMATH20230132302302'::text) AND ((is_deleted)::text = '0'::text))
 -> Index Scan using idx_applnodeleted_25 on TABLE_RECORD_202305 TABLE_RECORD_7 (cost=0.43..30.49 rows=1 width=483)
 Index Cond: (((appl_no)::text = 'LZLMATH20230132302302'::text) AND ((is_deleted)::text = '0'::text))
 Filter: ((date_created < now()) AND (date_created > (now() - '31 days'::interval day)))
 -> Index Scan using idx_applnodeleted_14 on TABLE_RECORD_202306 TABLE_RECORD_8 (cost=0.56..45.11 rows=18 width=485)
 Index Cond: (((appl_no)::text = 'LZLMATH20230132302302'::text) AND ((is_deleted)::text = '0'::text))
 Filter: ((date_created < now()) AND (date_created > (now() - '31 days'::interval day)))
 -> Index Scan using idx_applnodeleted_38 on TABLE_RECORD_202307 TABLE_RECORD_9 (cost=0.14..5.17 rows=1 width=3502)
 Index Cond: (((appl_no)::text = 'LZLMATH20230132302302'::text) AND ((is_deleted)::text = '0'::text))
 Filter: ((date_created < now()) AND (date_created > (now() - '31 days'::interval day)))
 -> Index Scan using idx_applnodeleted_1 on TABLE_RECORD_202308 TABLE_RECORD_10 (cost=0.14..5.17 rows=1 width=3502)

分区数据分布：

 select count(*),tableoid::regclass from TABLE_RECORD group by 2;
 count | tableoid 
-------+---------------------------------
| TABLE_RECORD_202303
| TABLE_RECORD_202211
| TABLE_RECORD_202306
| TABLE_RECORD_202305
| TABLE_RECORD_202304
| TABLE_RECORD_202212
| TABLE_RECORD_202301
| TABLE_RECORD_202302

执行计划看上去对不同的分区访问了不同的索引 date_TABLE_RECORD：分区键上的索引 idx_applnodeleted：appl_no, is_deleted组合索引实际上sql可以通过DATE_CREATED近31天数据字段裁剪分区。但是如果在用这个字段的索引，那就没有任何过滤性了。而appl_no, is_deleted在分区中过滤性较好，真正的执行计划应该选择 idx_applnodeleted组合索引。上面的explain执行计划虽然不是真正的执行计划，但是能看到5、6月份的走的索引是没有问题的，走的是appl_no, is_deleted组合索引。查看真实的执行计划会执行sql，所以把update改成select，查看真实的执行计划

# explain (analyze,buffers,timing,verbose) select count(*) from TABLE_RECORD WHERE APPL_NO = 'LZLMATH20230132302302' AND IS_DELETED = '0' AND DATE_CREATED > now() - interval '31' day AND DATE_CREATED < now() ;
 QUERY PLAN 
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=266.09..266.10 rows=1 width=8) (actual time=0.565..0.566 rows=1 loops=1)
 Output: count(*)
 Buffers: shared hit=48
 -> Append (cost=0.14..265.95 rows=56 width=0) (actual time=0.388..0.558 rows=1 loops=1)
 Buffers: shared hit=48
 Subplans Removed: 37
 -> Index Scan using idx_applnodeleted_25 on public.TABLE_RECORD_202305 TABLE_RECORD_1 (cost=0.43..30.39 rows=2 width=0) (actual time=0.059..0.059 rows=0 loops=1)
 Index Cond: (((TABLE_RECORD_1.appl_no)::text = 'LZLMATH20230132302302'::text) AND ((TABLE_RECORD_1.is_deleted)::text = '0'::text))
 Filter: ((TABLE_RECORD_1.date_created < now()) AND (TABLE_RECORD_1.date_created > (now() - '31 days'::interval day)))
 Buffers: shared hit=3
 -> Index Scan using idx_applnodeleted_14 on public.TABLE_RECORD_202306 TABLE_RECORD_2 (cost=0.56..42.52 rows=17 width=0) (actual time=0.328..0.498 rows=1 loops=1)
 Index Cond: (((TABLE_RECORD_2.appl_no)::text = 'LZLMATH20230132302302'::text) AND ((TABLE_RECORD_2.is_deleted)::text = '0'::text))
 Filter: ((TABLE_RECORD_2.date_created < now()) AND (TABLE_RECORD_2.date_created > (now() - '31 days'::interval day)))
 Buffers: shared hit=45
Planning:
 Buffers: shared hit=5867
Planning Time: 17.195 ms
Execution Time: 0.654 ms
(18 rows)

select只访问了5月和6月两个分区，说明分区裁剪没问题；两个分区都是idx_applnodeleted索引，所以索引选择也没问题。直接执行select语句，执行时间是ms级。

## select count(*) from TABLE_RECORD WHERE APPL_NO = 'LZLMATH20230132302302' AND IS_DELETED = '0' AND DATE_CREATED > now() - interval '31' day AND DATE_CREATED < now() ;
 count 
-------
 1
(1 row)

Time: 4.946 ms

分析到这里，看上去执行计划正常，执行时间正常

业务sql仍然缓慢
#

但是，postgresql日志中仍然能抓到慢sql，update执行了10s

2023-06-29 11:06:45.077 CST,"lzldbopr","lzldb",116286,"30.88.78.90:51871",649cdebf.1c63e,7,"UPDATE",2023-06-29 09:30:39 CST,759/12440291,4002354803,LOG,00000,"duration: 10287.105 ms " plan:
Query Text: update TABLE_RECORD
 set IS_DELETED = '1', DATE_UPDATED = LOCALTIMESTAMP(0)
 WHERE APPL_NO = $1
 AND IS_DELETED = '0'
 AND DATE_CREATED > now() - interval '31' day
 AND DATE_CREATED < now()
Update on TABLE_RECORD (cost=0.14..203.79 rows=39 width=2960)
 Update on TABLE_RECORD_202211 TABLE_RECORD_1
...
 -> Index Scan using TABLE_RECORD_202304_date_created_idx on TABLE_RECORD_202304 TABLE_RECORD_6 (cost=0.44..5.47 rows=1 width=481)
 Index Cond: ((date_created > (now() - '31 days'::interval day)) AND (date_created < now()))
 Filter: (((appl_no)::text = 'LZLMATH20230132302302'::text) AND ((is_deleted)::text = '0'::text))
 -> Index Scan using TABLE_RECORD_202305_date_created_idx on TABLE_RECORD_202305 TABLE_RECORD_7 (cost=0.44..5.47 rows=1 width=483)
 Index Cond: ((date_created > (now() - '31 days'::interval day)) AND (date_created < now()))
 Filter: (((appl_no)::text = 'LZLMATH20230132302302'::text) AND ((is_deleted)::text = '0'::text))
 -> Index Scan using TABLE_RECORD_202306_date_created_idx on TABLE_RECORD_202306 TABLE_RECORD_8 (cost=0.44..5.47 rows=1 width=485)
 Index Cond: ((date_created > (now() - '31 days'::interval day)) AND (date_created < now()))
 Filter: (((appl_no)::text = 'LZLMATH20230132302302'::text) AND ((is_deleted)::text = '0'::text))
 -> Index Scan using idx_applnodeleted_38 on TABLE_RECORD_202307 TABLE_RECORD_9 (cost=0.14..5.17 rows=1 width=3502)
 Index Cond: (((appl_no)::text = 'LZLMATH20230132302302'::text) AND ((is_deleted)::text = '0'::text))
 Filter: ((date_created < now()) AND (date_created > (now() - '31 days'::interval day)))
...

5、6月分区还是用的date_created分区键上的索引，执行计划只估算了1行，实际上这2个分区实际上都有百万行数据。分析到这里就非常困惑，优化器本身可以走到更好的索引，explain也看到走到了那个索引，但是业务sql就是没有走正确的索引。

更新统计信息
#

因为是pgsql执行计划的问题，首先都会想到收集统计信息问题发生后，收集了分区表父表和子表的统计信息，并且担心会话缓存了执行计划（plan_cache_mode=auto），将统计信息收集时间之前的会话全部kill。日志仍然显示sql执行10s，说明不是统计信息的问题。做到这里问题仍然没有解决，似乎已经黔驴技穷了。

问题根因
#

前面分析执行计划的时候，dba explain的执行计划与应用的执行计划不一致，不过我们都是用postgres超级用户执行的。切换为应用用户再次explain执行，执行计划结果与日志中的执行计划一致！因为之前出现过原生分区表权限问题，导致执行计划异常的情况。所以立即检查分区表分区的权限父表权限

## \dp+ TABLE_RECORD
 Access privileges
 Schema | Name | Type | Access privileges | Column privileges | Policies 
--------+--------------------------+-------------------+-------------------------------------+-------------------+----------
 public | TABLE_RECORD | partitioned table | lzldbdata=arwdDxt/lzldbdata +| | 
 | | | r_lzldbdata_qry=r/lzldbdata +| | 
 | | | r_lzldbdata_dml=arwd/lzldbdata +| | 
(1 row)

子表权限

## \dp+ TABLE_RECORD_202505
 Access privileges
 Schema | Name | Type | Access privileges | Column privileges | Policies 
--------+---------------------------------+-------+------------------------------------+-------------------+----------
 public | TABLE_RECORD_202505 | table | lzldbdata=arwdDxt/lzldbdata +| | 

分区权限少了r_lzldbdata_dml这个角色的,这个角色是授权给业务用户的。立即执行授权，问题解决

grant select,update,delete,insert on TABLE_RECORD_202305 to r_lzldbdata_dml;
grant select,update,delete,insert on TABLE_RECORD_202306 to r_lzldbdata_dml;

再次用opr用户explain，执行计划正确，5、6月走了正常的索引 \c - lzldbopr

 -> Index Scan using TABLE_RECORD_202303_date_created_idx on TABLE_RECORD_202303 TABLE_RECORD_5 (cost=0.44..5.47 rows=1 width=482)
 Index Cond: ((date_created > (now() - '31 days'::interval day)) AND (date_created < now()))
 Filter: (((appl_no)::text = 'LZLMATH20230132302302'::text) AND ((is_deleted)::text = '0'::text))
 -> Index Scan using TABLE_RECORD_202304_date_created_idx on TABLE_RECORD_202304 TABLE_RECORD_6 (cost=0.44..5.47 rows=1 width=481)
 Index Cond: ((date_created > (now() - '31 days'::interval day)) AND (date_created < now()))
 Filter: (((appl_no)::text = 'LZLMATH20230132302302'::text) AND ((is_deleted)::text = '0'::text))
 -> Index Scan using idx_applnodeleted_25 on TABLE_RECORD_202305 TABLE_RECORD_7 (cost=0.43..30.39 rows=1 width=483)
 Index Cond: (((appl_no)::text = 'LZLMATH20230132302302'::text) AND ((is_deleted)::text = '0'::text))
 Filter: ((date_created < now()) AND (date_created > (now() - '31 days'::interval day)))
 -> Index Scan using idx_applnodeleted_14 on TABLE_RECORD_202306 TABLE_RECORD_8 (cost=0.56..42.57 rows=17 width=485)
 Index Cond: (((appl_no)::text = 'LZLMATH20230132302302'::text) AND ((is_deleted)::text = '0'::text))
 Filter: ((date_created < now()) AND (date_created > (now() - '31 days'::interval day)))
 -> Index Scan using idx_applnodeleted_38 on TABLE_RECORD_202307 TABLE_RECORD_9 (cost=0.14..5.17 rows=1 width=3502)
 Index Cond: (((appl_no)::text = 'LZLMATH20230132302302'::text) AND ((is_deleted)::text = '0'::text))
 Filter: ((date_created < now()) AND (date_created > (now() - '31 days'::interval day)))
 -> Index Scan using idx_applnodeleted_1 on TABLE_RECORD_202308 TABLE_RECORD_10 (cost=0.14..5.17 rows=1 width=3502)
 Index Cond: (((appl_no)::text = 'LZLMATH20230132302302'::text) AND ((is_deleted)::text = '0'::text))
 Filter: ((date_created < now()) AND (date_created > (now() - '31 days'::interval day)))

pg日志上也未再观察到慢update语句。

测试（没复现）
#

初始化建表脚本

--切换非超级用户
\c - lzldbdata
--create table
CREATE TABLE PUBLIC.LZLPARTITION
(
 APPL_NO varchar(100) NULL,
	IS_DELETED varchar(8) NULL, 
 DATE_CREATED timestamp NOT NULL DEFAULT now(),
 DATE_UPDATED timestamp NOT NULL DEFAULT now()
) PARTITION BY RANGE(DATE_CREATED);

--indexes
create index DATE_LZLPARTITION on PUBLIC.LZLPARTITION (DATE_CREATED);
create index NK_LZLPARTITION on PUBLIC.LZLPARTITION (APPL_NO);


--privs
GRANT SELECT ON TABLE public.LZLPARTITION TO r_lzldbdata_qry;
GRANT SELECT,INSERT,UPDATE,DELETE ON TABLE public.LZLPARTITION TO r_lzldbdata_dml;

--partition
create table LZLPARTITION_202301 partition of LZLPARTITION for values from ('2023-01-01 00:00:00') to ('2023-02-01 00:00:00');
create table LZLPARTITION_202302 partition of LZLPARTITION for values from ('2023-02-01 00:00:00') to ('2023-03-01 00:00:00');
create table LZLPARTITION_202303 partition of LZLPARTITION for values from ('2023-03-01 00:00:00') to ('2023-04-01 00:00:00');
create table LZLPARTITION_202304 partition of LZLPARTITION for values from ('2023-04-01 00:00:00') to ('2023-05-01 00:00:00');
create table LZLPARTITION_202305 partition of LZLPARTITION for values from ('2023-05-01 00:00:00') to ('2023-06-01 00:00:00');
create table LZLPARTITION_202306 partition of LZLPARTITION for values from ('2023-06-01 00:00:00') to ('2023-07-01 00:00:00');

生成数据：

insert
 into
 public.LZLPARTITION
select
 n + 10,
 'N',
 to_char(to_date('2023-01-01', 'YYYY-MM-DD') + ('' || n || ' minute') ::interval, 'YYYY-MM-DD')::"date",
 now()
from
 generate_series(0, 300000) n

数据分布：

select count(*),tableoid::regclass from lzlpartition group by 2;
 count | tableoid 
-------+---------------------
| lzlpartition_202301
| lzlpartition_202302
| lzlpartition_202303
| lzlpartition_202304
| lzlpartition_202305
| lzlpartition_202306
| lzlpartition_202307

权限未继承：

## \dp+ lzlpartition
 Access privileges
 Schema | Name | Type | Access privileges | Column privileges | Policies 
--------+--------------+-------------------+-------------------------------------+-------------------+----------
 public | lzlpartition | partitioned table | lzldbdata=arwdDxt/lzldbdata +| | 
 | | | r_lzldbdata_qry=r/lzldbdata +| | 
 | | | r_lzldbdata_dml=arwd/lzldbdata | | 


## \dp+ lzlpartition_202306
 Access privileges
 Schema | Name | Type | Access privileges | Column privileges | Policies 
--------+---------------------+-------+-------------------+-------------------+----------
 public | lzlpartition_202306 | table | | | 

执行计划（正确）：

explain select count(*) from lzlpartition WHERE APPL_NO = '217450' AND IS_DELETED = 'N' AND DATE_CREATED > now() - interval '31' day AND DATE_CREATED < now();
 QUERY PLAN 
--------------------------------------------------------------------------------------------------------------------------------------------
 Aggregate (cost=36.76..36.77 rows=1 width=8)
 -> Append (cost=0.29..36.74 rows=7 width=0)
 Subplans Removed: 5
 -> Index Scan using lzlpartition_202305_appl_no_idx on lzlpartition_202305 lzlpartition_1 (cost=0.15..5.19 rows=1 width=0)
 Index Cond: ((appl_no)::text = '217450'::text)
 Filter: (((is_deleted)::text = '0'::text) AND (date_created < now()) AND (date_created > (now() - '31 days'::interval day)))
 -> Index Scan using lzlpartition_202306_appl_no_idx on lzlpartition_202306 lzlpartition_2 (cost=0.15..5.19 rows=1 width=0)
 Index Cond: ((appl_no)::text = '217450'::text)
 Filter: (((is_deleted)::text = '0'::text) AND (date_created < now()) AND (date_created > (now() - '31 days'::interval day)))

权限仍然没有继承，其实测了其他pg版本也是这样的，看上去是一个通用行为。但是就算这样也没有复现出来，测试结果走了正确的索引，没有像生产环境那样走错误的索引。

问题总结
#

因为我们收集了统计信息并kill了会话，不应该是缓存执行计划的问题。执行了grant后，分区执行计划立即正确（甚至grant一个分区，对一个分区），所以比较确认是分区权限导致分区执行计划异常的。分析和处理问题的过程总结如下

切换应用用户查看执行计划。直接用超级用户登陆查看执行计划是通用做法，但是查看到的执行计划还是不对的。
分区表子表的权限问题。根因是postgresql分区表子表上的权限与父表不一致，导致执行计划异常，也就是说权限问题影响了pg的执行计划。
该问题不好复现，非常非常偶发。
权限导致执行计划异常这个问题非常隐蔽，不好定位。

想深入讨论2个问题

权限问题不应该影响执行计划。为什么权限会影响执行计划？
子表权限与父表不一致。为什么子表没有全部继承父表权限？已提交BUG看看官方咋说

花式分析一个5M的SQL占用70GB内存

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

进程内存分析
#

"WAL writer process (PID 66902) was terminated by signal 6: Aborted",,,,,,,,,"","postmaster"

从日志中找到被kill的postmaster进程66902

到osw中找进程消耗的内存。由于top没有PPID，PS没有USS信息，所以要两个一起看

USER PID PPID PRI %CPU %MEM VSZ RSS WCHAN S STARTED TIME COMMAND
postgres 211276 66478 19 8.7 10.6 57488380 56389972 - R 17:13:03 00:02:47 postgres: BIND
postgres 211277 66478 19 7.8 9.6 52294700 51127480 - R 17:13:03 00:02:31 postgres: BIND
postgres 222749 66478 19 22.7 9.3 51320000 49073368 - R 17:35:33 00:02:09 postgres: BIND
postgres 39513 66478 19 2.9 6.8 38651084 36354736 ep_poll S 16:13:03 00:02:43 postgres: idle

通过PPID找个backend消耗较高的进程，比如211276进程进行进一步分析

[postgres@lzl]$ zcat /osw/oswtop/toposw.dat.gz |grep 211276

 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
211276 postgres 20 0 3271756 1.1g 1.1g S 7.3 0.2 0:03.93 postgres
211276 postgres 20 0 3291784 1.3g 1.2g R 96.4 0.2 0:11.87 postgres
211276 postgres 20 0 7369628 6.0g 2.1g R 100.0 1.2 0:46.58 postgres
211276 postgres 20 0 17.0g 15.9g 2.1g R 100.0 3.2 1:16.70 postgres
211276 postgres 20 0 28.8g 27.7g 2.1g R 100.0 5.5 1:46.82 postgres
211276 postgres 20 0 41.4g 40.4g 2.1g R 100.0 8.0 2:16.99 postgres
211276 postgres 20 0 54.7g 53.7g 2.1g R 88.8 10.7 2:47.60 postgres
211276 postgres 20 0 66.5g 64.9g 2.1g R 34.7 12.9 3:22.76 postgres
211276 postgres 20 0 71.0g 68.2g 2.1g R 99.1 13.6 3:52.94 postgres
211276 postgres 20 0 74.9g 71.2g 2.1g R 100.0 14.2 4:23.05 postgres
211276 postgres 20 0 0 0 0 R 100.0 0.0 4:45.65 postgres

top可以通过RES-SHR=USS来判断进程私有内存的消耗。211276进程的内存几分钟内暴涨到70g挂掉，并且都是进程私有内存消耗

sql分析
#

PG日志中一个5M的SQL，包含5000+个union all，3万个变量执行计划长达7W行

Append (cost=218196.51..218216.28 rows=1318 width=1628)
 InitPlan 1 (returns $0)
 -> Index Scan using table1 on table1nfo (cost=0.29..5.31 rows=1 width=40)
 Index Cond: ((col1)::text = 'xxx'::text)
 Filter: ((colcolcol)::text = 'xxx'::text)
 InitPlan 2 (returns $1)
 -> Index Scan using table1 on table1nfo table1nfo_1 (cost=0.29..5.31 rows=1 width=40)
 Index Cond: ((col1)::text = 'xxx'::text)
 Filter: ((colcolcol)::text = 'xxx'::text)
 ...
 InitPlan 10544 (returns $10543)
 -> Aggregate (cost=5.58..5.59 rows=1 width=32)
 -> Index Scan using table2 on table2col t_1317 (cost=0.56..5.58 rows=1 width=19)
 Index Cond: ((ididid)::text = 'xxx'::text)
 Filter: ((idididid)::text = '1'::text)

执行计划结构非常简单，1w个子计划查数据，最后append结果。

就是这么个拼接怪SQL把backend进程打到70GB。其实不用深入分析也知道，这个sql是有问题的，把union all减少，问题应该是可以修复的（事实上就是这样）。但是如果仔细想想，这里有很多问题可以深入分析：

为什么5M的SQL可以把内存打到70GB？
数据本身跟内存有关系吗？是因为返回数据过多导致的吗？
是解析数据缓存大，还是因为执行计划缓存数据大？
work_mem明明不大，为什么没有起到限制operation内存的效果？

初步分析
#

如果一个5M的sql缓存在backend中，里面至少应该包含所要的元数据、SQL解析数据、执行计划缓存信息我们之前碰到过几十万个表/分区表的元数据缓存导致relcache过大，从而导致backend内存很大。而这个库的表不多，初步可以排除relcache问题（后续查看dump内存可以确认排除）。 SQL解析数据理应不会太多，5M的sql解析出来至少不应该是70G。

work_mem的内存限制and more： work_mem只限制每个operation的sort（可以用到sort的操作）、hash（可以用到hash的操作）的内存。这里就存在multiple sort/hash的问题，一个sql有多个sort的话可使用多个work_mem，所以pg13新增hash_mem_multiplier以限制一个语句中的hash使用次数。但是sort呢？sort目前没有multiplier参数，但是现实场景中问题较少，因为一个语句中大量的plan node存在sort操作的情况是比较少的，想想代价就很高，优化器源码中也有把排序操作放在执行计划最后的逻辑，以减少反复排序。

这里实例的work_mem为128M，并且这个库是pg13+的，hash_mem_multiplier为1，基本可以排除执行计划使用大量hash操作导致内存暴涨的问题。另外从上面的执行计划看，完全没有sort和hash操作，所以可以排除sort/hash操作过多导致的问题。

所以之前的提问，“work_mem明明不大，为什么没有起到限制operation内存的效果？”

因为sql语句只有union all，没有任何排序和hash操作，所以work_mem不会限制这里的内存

其他plan node: 无论怎样，work_mem只（？）限制sort/hash。plan operation有这么多类型的操作，是不是没有限制？

复现问题并深入分析
#

空表复现内存飙升
#

--建空表
 create table lzl1(col1 varchar(1));
--非常多union all的查询
select col1 from lzl1 union all
select col1 from lzl1 union all 
...(5000个union all，sql大小150KB)
select col1 from lzl1

（UNION ALL过多可能超过max_stack_depth限制）一个空表，多个union all，直接就容复现出来内存飙升问题。不仅如此，还可以发现sql运行完后，backend的内存回收了。

因为是一个空表，数据文件0kb，所以可以排除数据问题导致内存飙高。所以“数据本身跟内存有关系吗？是因为返回数据过多导致的吗？”——跟数据本身关系不大。

strace操作系统调用分析
#

执行语句的同时通过strace -p抓操作系统调用信息：

 strace -p 198337 > strace.198337 2>&1

在看strace信息前先了解一点点linux调用函数：

epoll_wait:等待event，什么都不做的进程就是这个状态
recvfrom:receive a message from a socket，从socket接收消息
getrusage:get resource usage，获取资源使用情况
brk: program break.Increasing the program break has the effect of allocating memory to the process; decreasing the break deallocates memory.操作系统底层管理内存的函数，malloc本质上也是在调用brk。
lseek:repositions the file offset of the open file description associated with the file descriptor fd to the argument offset，定位文件偏移量用的
write:write to a file descriptor，write不保证写入磁盘
sendto:send a message on a socket，从socket发送消息

其中，lseek、write、sendto等系统函数中包含fd文件描述符信息

lseek(37, 0, SEEK_END) = 0

在/proc/[pid]/pd目录中缓存了进程持有的文件描述符，从文件描述符反查relation，可以找到SQL执行打开的表lzl1

[postgres@lzl]$ cd /proc/198337/fd
[postgres@lzl]$ ll 37
lrwx------ 1 postgres postgres 64 Jan 26 22:59 37 -> /pgdata/lzl/data13/base/16385/16386
[postgres@lzl]$ oid2name -d lzldb -f 16386
From database "lzldb":
 Filenode Table Name
----------------------
 16386 lzl1

strace信息非常多，但是结构简单：

strace: Process 198337 attached
epoll_wait(4, [{EPOLLIN, {u32=44314568, u64=44314568}}], 1, -1) = 1
## step1
recvfrom(9, "Q\0\2p\372select col1 from lzl1 union"..., 8192, 0, NULL, NULL) = 8192
recvfrom(9, " all\nselect col1 from lzl1 union"..., 8192, 0, NULL, NULL) = 8192
recvfrom(9, " all\nselect col1 from lzl1 union"..., 8192, 0, NULL, NULL) = 8192
...
recvfrom(9, " all\nselect col1 from lzl1 union"..., 8192, 0, NULL, NULL) = 8192
recvfrom(9, " all\nselect col1 from lzl1 union"..., 8192, 0, NULL, NULL) = 4347
## step2
brk(NULL) = 0x34d5000
brk(0x3cd5000) = 0x3cd5000
brk(NULL) = 0x3cd5000
...
brk(NULL) = 0x88cd6000
brk(0x894d6000) = 0x894d6000
## step3
lseek(37, 0, SEEK_END) = 0
lseek(37, 0, SEEK_END) = 0
...
lseek(37, 0, SEEK_END) = 0
## step4
brk(NULL) = 0x89cd6000
brk(0x8a4d6000) = 0x8a4d6000
brk(NULL) = 0x8a4d6000
...
brk(NULL) = 0x8a516000
brk(0x8a556000) = 0x8a556000
## step5
write(2, "2024-01-26 23:08:01.800 CST [198"..., 165521) = 165521
brk(NULL) = 0x8a556000
brk(0x8a57d000) = 0x8a57d000
brk(NULL) = 0x8a57d000
brk(0x8a59f000) = 0x8a59f000
...
brk(NULL) = 0x8d449000
brk(0x8d46b000) = 0x8d46b000
brk(NULL) = 0x8d46b000
brk(0x8d48d000) = 0x8d48d000
#step6
lseek(37, 0, SEEK_END) = 0
lseek(37, 0, SEEK_END) = 0
...
lseek(37, 0, SEEK_END) = 0
#step7
brk(NULL) = 0x8dcb1000
brk(NULL) = 0x8dcb1000
brk(0x8c179000) = 0x8c179000
brk(NULL) = 0x8c179000
brk(NULL) = 0x8c179000
brk(NULL) = 0x8c179000
brk(0x8a526000) = 0x8a526000
...
brk(0x34d5000) = 0x34d5000
brk(NULL) = 0x34d5000
#step8
sendto(8, "\2\0\0\0\230\0\0\0\1@\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 152, 0, NULL, 0) = 152
sendto(9, "T\0\0\0\35\0\1col1\0\0\0\0\0\0\0\0\0\4\23\377\377\0\0\0\5\0\0C\0"..., 50, 0, NULL, 0) = 50
#step9
recvfrom(9, 0xddcf60, 8192, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
epoll_wait(4, strace: Process 198337 detached
 <detached ...> 

从fd=9的socket接收到message，也就是我们发送的union all语句
brk分配内存，进程的内存从0x34d5000（54MB）涨到0x894d6000（2.1GB）
lseek表lzl1
内存上涨4MB
write到fd=2的文件，就是日志文件；内存上涨48MB
lseek表lzl1
内存到达峰值0x8dcb1000（2.1GB），开始通过brk释放内存，直到0x34d5000（54MB），跟开始时分毫不差
从socket返回消息，也就是返回查询结果
从fd=9的socket接收到空消息

strace分析到的东西不多，不过可以看到操作系统为进程分配和释放内存的具体过程。

dump内存分析
#

内存飙高后的pmap信息：

[postgres@lzl pg_log]$ pmap -x 76207
76207: postgres: postgres lzldb [local] SELECT 
Address Kbytes RSS Dirty Mode Mapping
0000000000400000 7984 2192 0 r-x-- postgres
0000000000dcc000 4 4 4 r---- postgres
0000000000dcd000 60 60 60 rw--- postgres
0000000000ddc000 200 60 60 rw--- [ anon ]
0000000001e49000 264 224 224 rw--- [ anon ]
0000000001e8b000 1812380 1804400 1804400 rw--- [ anon ]
...
ffffffffff600000 4 0 0 r-x-- [ anon ]
---------------- ------- ------- ------- 
total kB 2089384 1810232 1807384

pmap这里没有展示具体段是什么，但是可以确认内存起始地址为1e49000的内存段占用最多。此时需要smap来看是什么段，smap的段信息更为准确：

[postgres@lzl 76207]$ cat smaps |grep 1e49000 -A 30
01e49000-01e8b000 rw-p 00000000 00:00 0 [heap]
Size: 264 kB
...
01e8b000-70872000 rw-p 00000000 00:00 0 [heap]
Size: 1812380 kB
Rss: 1804400 kB
Pss: 1804400 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 1804400 kB
Referenced: 1804400 kB
Anonymous: 1804400 kB
AnonHugePages: 0 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB

heap段，PSS进程私有内存达到1.8GB！ （这里本来应该dump 01e8b000-70872000内存段，但是gdb dump memory会报错，不太明白具体原因，大佬可以指点一下，谢谢！） 这里粗糙一点用gcore dump内存，比较难看，什么东西都有，没有发现占用特别多的内容。不过strings后发现内存数据实际上很少：

[postgres@lzl lzl]$ gcore -o /pgdata/lzl/gcore.dump 76207
[postgres@lzl lzl]$ strings gcore.dump.76207> text.dump.76207
[postgres@lzl lzl]$ ll -h
-rw-r----- 1 postgres postgres 2.0G Jan 26 17:29 gcore.dump.76207
-rw-r----- 1 postgres postgres 5.2M Jan 26 17:30 text.dump.76207

申请了2G的虚拟内存，占用1.8G的物理内存，实际上只存储了5.2M的数据！用hexdump极粗略地看一下，可以发现很多内存空洞

[postgres@lzl lzl]$ hexdump -C gcore.dump.76207 |head -10000 |grep "00 00 00 00 00 00 00 00"|wc -l
3690

log_planner_stats等信息
#

为了验证是否缓存执行计划的问题把复现环境的相关log参数先后打开以观察parse、planner、executor阶段的资源消耗

 log_parser_stats = on
 log_planner_stats = on
 log_executor_stats = on

从日志上看parse阶段的消耗内存较少，而planner的内存消耗较多 log planner stat的信息：

2024-01-26 18:01:41.592 CST [208503] LOG: PLANNER STATISTICS
2024-01-26 18:01:41.592 CST [208503] DETAIL: ! system usage stats:
 ! 0.048955 s user, 0.004996 s system, 0.054077 s elapsed
 ! [11.208034 s user, 1.313838 s system total]
 ! 2255352 kB max resident size
 ! 0/0 [0/352] filesystem blocks in/out
 ! 0/1315 [0/563859] page faults/reclaims, 0 [0] swaps
 ! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
 ! 0/0 [1/16] voluntary/involuntary context switches

2GB的max resident size大小跟进程观察的res差不多，所以上面的信息可以回答刚才的问题：“是解析数据缓存大，还是因为执行计划缓存数据大？”——planner阶段消耗的内存。

查看TopMemoryContext
#

pg通过memorycontext管理backend进程的私有内存，可通过gdb输出TopMemoryContext信息：

TopMemoryContext: 101488 total in 6 blocks; 48464 free (28 chunks); 53024 used
 pgstat TabStatusArray lookup hash table: 8192 total in 1 blocks; 1408 free (0 chunks); 6784 used
 TopTransactionContext: 8192 total in 1 blocks; 7720 free (0 chunks); 472 used
 TableSpace cache: 8192 total in 1 blocks; 2048 free (0 chunks); 6144 used
 RowDescriptionContext: 8192 total in 1 blocks; 6880 free (0 chunks); 1312 used
 MessageContext: 1854981336 total in 235 blocks; 7911304 free (9 chunks); 1847070032 used
...
Grand total: 1856104056 bytes in 431 blocks; 8226712 free (179 chunks); 1847877344 used

内存消耗最多的是MessageContext 1.8G src/backend/utils/mmgr/README对MessageContext 的解释：

MessageContext — this context holds the current command message from the frontend, as well as any derived storage that need only live as long as the current message (for example, in simple-Query mode the parse and plan trees can live here). This context will be reset, and any children deleted, at the top of each cycle of the outer loop of PostgresMain. This is kept separate from per-transaction and per-portal contexts because a query string might need to live either a longer or shorter time than any single transaction or portal.

When creating a prepared statement, the parse and plan trees will be built in a temporary context that’s a child of MessageContext

MessageContext缓存frontend发来传递的消息，包含派生的parse、plan tree信息
parse and plan trees 是MessageContext的child，也就是说MessageContext回收，parse and plan trees 就回收

这里就的messagecontext还可以解释私有内存回收问题，planner阶段产生的plan tree内存数据是MessageContext的child，数据结果返回后MessageContext被回收，child内容也被回收，同样也可以解释从strace中观察的内存释放后跟释放前的大小是完全一致的。

总结
#

回答最后一个问题：“为什么5M的SQL可以把内存打到70GB？”

绝大部分内存是在生产执行计划期间消耗的，planner申请了大量的内存，并且work_mem，hash_mem_multiplier只能限制到排序操作和hash操作，对于planner过程中的其他内存操作还无法限制，planner本身产生的plan tree并不大，但是申请内存时存在大量的内存空洞，导致本身M级的数据（元数据、parse tree、plan tree等等）存储在G级的内存中。

这些SQL、parse tree、plan tree都缓存在MessageContext及其child中，消息发送完毕后，此部分产生的内存全部回收。

较少的分区也报错too many range table entries

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

问题现象
#

postgresql中update执行语句报错too many range table entries 源sql

with t as (select id from LZLTAB where id=8723 limit 100 )
update	LZLTAB set
	STATUS = '00',
	FILE_ID = null,
	DATE_UPDATED = localtimestamp(0)
where id in (select	id from t)

如果把update改写成select，可以执行成功

with t as (select	id from	LZLTAB where	id=8723 limit 100 )
select * from 	LZLTAB where	id in (select id	from t)
 id | date_created 
------+----------------------------+...
 8723 | 2023-06-21 18:02:21.161687 
(1 row)	

主键和分区是这样，分区总共有400个

Partition key: RANGE (partition_key)
Indexes:
 "pk_lzl" PRIMARY KEY, btree (id, partition_key)
...
Partitions: lzl_p20230601 FOR VALUES FROM ('20230601') TO ('20230602'),
 lzl_p20230602 FOR VALUES FROM ('20230602') TO ('20230603'),
 lzl_p20230603 FOR VALUES FROM ('20230603') TO ('20230604')

sql逻辑有很多优化点，但是这里不讨论优化。重点是分析为什么update会报错，和为什么select和update会有区别。执行explain update报错如下：

explain with t as (selec tid from LZLTAB where id=8723 limit 100 )
update LZLTAB set
STATUS = '00',
FILE_ID = null,
DATE_UPDATED = localtimestamp(0)
where id in (select id from t);

ERROR: 54000: too many range table entries
LOCATION: add_rte_to_flat_rtable, setrefs.c:451
Time: 18341.171 ms (00:18.341)

explain卡了18秒，然后报错

源码分析
#

报错直接抛出了源码的位置LOCATION: add_rte_to_flat_rtable, setrefs.c:451 ，直接找到该源码

src/backend/optimizer/plan/setrefs.c 其注释是说setrefs.c是完成计划树后的相关工作的

/*
 *Post-processing of a completed plan tree: fix references to subplan
 *	 vars, compute regproc values for operators, etc
 */

找到第451行的函数：

/*
 * Add (a copy of) the given RTE to the final rangetable
 *
 * In the flat rangetable, we zero out substructure pointers that are not
 * needed by the executor; this reduces the storage space and copying cost
 * for cached plans. We keep only the ctename, alias and eref Alias fields,
 * which are needed by EXPLAIN, and the selectedCols, insertedCols,
 * updatedCols, and extraUpdatedCols bitmaps, which are needed for
 * executor-startup permissions checking and for trigger event checking.
 */
static void
add_rte_to_flat_rtable(PlannerGlobal *glob, RangeTblEntry *rte)
{
...
	/*
	 * Check for RT index overflow; it's very unlikely, but if it did happen,
	 * the executor would get confused by varnos that match the special varno
	 * values.
	 */
	if (IS_SPECIAL_VARNO(list_length(glob->finalrtable)))
		ereport(ERROR,
				(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
				 errmsg("too many range table entries")));
...
}

errmsg()就是第451行。add_rte_to_flat_rtable()看注释跟RTE有关，什么RTE呢？下面再分析。报错的判断是IS_SPECIAL_VARNO()，直接搜索该函数，在src/include/nodes/primnodes.h中找到宏定义

/*
 * Var - expression node representing a variable (ie, a table column)
 *
 * In the parser and planner, varno and varattno identify the semantic
 * referent, which is a base-relation column unless the reference is to a join
 * USING column that isn't semantically equivalent to either join input column
 * (because it is a FULL join or the input column requires a type coercion).
 * In those cases varno and varattno refer to the JOIN RTE. (Early in the
 * planner, we replace such join references by the implied expression; but up
 * till then we want join reference Vars to keep their original identity for
 * query-printing purposes.)
 ...
 */
#define INNER_VAR		65000	/* reference to inner subplan */
#define OUTER_VAR		65001	/* reference to outer subplan */
#define INDEX_VAR		65002	/* reference to index column */

#define IS_SPECIAL_VARNO(varno)		((varno) >= INNER_VAR)

上面一段注释有点难懂，但是有段话很重要：In those cases varno and varattno refer to the JOIN RTE。varno与RTE有关系。然后varno>=65000时，会抛出报错。（这里不扩展INNER_VAR,OUTER_VAR,INDEX_VAR的区别，因为他们的值差别不大，不影响我们继续分析）

什么是RTE？ 在执行计划源码中的各个位置都能找到RTE（rangetable或RangeTblEntry）的描述，并且报错也很明显ERROR: 54000: too many range table entries也是说的RTE。那么什么是RTE？在src/include/nodes/parsenodes.h中有一段对RTE的描述

/*--------------------
 * RangeTblEntry -
 *	 A range table is a List of RangeTblEntry nodes.
 *
 *	 A range table entry may represent a plain relation, a sub-select in
 *	 FROM, or the result of a JOIN clause. (Only explicit JOIN syntax
 *	 produces an RTE, not the implicit join resulting from multiple FROM
 *	 items. This is because we only need the RTE to deal with SQL features
 *	 like outer joins and join-output-column aliasing.) Other special
 *	 RTE types also exist, as indicated by RTEKind.
 *
 *	 Note that we consider RTE_RELATION to cover anything that has a pg_class
 *	 entry. relkind distinguishes the sub-cases.
 */

简单的说，RTE是执行计划中的“表”，可以是具体的表也可以是生成类的“表”，比如子查询、join结果等等。RTE超出限制65000，也就是说执行计划中生成了太多的RTE。

查看update的执行计划
#

由于我们知道了RTE的啥，所以查看sql的执行计划可能会有所帮助。但是由于源sql（400个分区）没有生成执行计划，我们创建一个30个分区的表，期待它能explain出来，然后观察它的执行计划。 30个分区的表执行相同的update语句

explain with t as (select id from lzl where id=8723 limit 100 )
update lzl set
STATUS = '00',
FILE_ID = null,
DATE_UPDATED = localtimestamp(0)
where id in ( select id from t);

生成的执行计划如下

 QUERY PLAN 
-----------------------------------------------------------------------------------------------------------------------------------------
 Update on lzl (cost=155.48..4980.00 rows=600 width=3042)
 Update on lzl_p20230601 lzl_1
 Update on lzl_p20230602 lzl_2
	...
 Update on lzl_p20230630 lzl_30
 -> Hash Semi Join (cost=155.48..166.00 rows=20 width=3042)
 Hash Cond: (lzl_1.id = t.id)
 -> Seq Scan on lzl_p20230601 lzl_1 (cost=0.00..10.20 rows=20 width=2912)
 -> Hash (cost=155.10..155.10 rows=30 width=40)
 -> Subquery Scan on t (cost=0.14..155.10 rows=30 width=40)
 -> Limit (cost=0.14..154.80 rows=30 width=8)
 -> Append (cost=0.14..154.80 rows=30 width=8)
 -> Index Only Scan using lzl_p20230601_pkey on lzl_p20230601 lzl_32 (cost=0.14..5.16 rows=1 width=8)
 Index Cond: (id = 8723)
 -> Index Only Scan using lzl_p20230602_pkey on lzl_p20230602 lzl_33 (cost=0.14..5.16 rows=1 width=8)
 Index Cond: (id = 8723)
 ...
 -> Index Only Scan using lzl_p20230630_pkey on lzl_p20230630 lzl_61 (cost=0.14..5.16 rows=1 width=8)
 Index Cond: (id = 8723)
		...
 -> Hash Semi Join (cost=155.48..166.00 rows=20 width=3042)
 Hash Cond: (lzl_30.id = t_29.id)
 -> Seq Scan on lzl_p20230630 lzl_30 (cost=0.00..10.20 rows=20 width=2912)
 -> Hash (cost=155.10..155.10 rows=30 width=40)
 -> Subquery Scan on t_29 (cost=0.14..155.10 rows=30 width=40)
 -> Limit (cost=0.14..154.80 rows=30 width=8)
 -> Append (cost=0.14..154.80 rows=30 width=8)
 -> Index Only Scan using lzl_p20230601_pkey on lzl_p20230601 lzl_931 (cost=0.14..5.16 rows=1 width=8)
 Index Cond: (id = 8723)
 -> Index Only Scan using lzl_p20230602_pkey on lzl_p20230602 lzl_932 (cost=0.14..5.16 rows=1 width=8)
 Index Cond: (id = 8723)
								...
 -> Index Only Scan using lzl_p20230630_pkey on lzl_p20230630 lzl_960 (cost=0.14..5.16 rows=1 width=8)
 Index Cond: (id = 8723)
(2041 rows)

执行计划非常长，总共有2041行。这个执行计划非常笨，每个分区在更新的时候，都把谓词条件在分区表中运行了一次，由于sql没有分区键，每次运行又扫描了所有分区。本身30个分区的分区表，每个分区扫描了30次，总共扫描900次分区。从执行计划也能看到RTE表刚开始有30个，分配给update直到lzl_30；后面每次hash匹配时每个分区扫描也分配了30个RTE，比如lzl_1对应的hash下的分区扫描从lzl_32到lzl_61。这里为什么是32而不是31？因为整个分区扫描是一个子查询也是一个RTE，为t(所有的为t,t1-t_29)，也是总共30个。所以执行计划中生成的RTE表总共有30+30+30*30=960个。

如果用select来看执行计划，发现跟update的执行计划有很大的不同

explain with t as (select id from lzl where id=8723 limit 100 )
select STATUS ,FILE_ID ,DATE_UPDATED from lzl where id in ( select id from t);

 Hash Semi Join (cost=155.48..467.05 rows=90 width=98)
 Hash Cond: (lzl.id = lzl_31.id)
 -> Append (cost=0.00..309.00 rows=600 width=106)
 -> Seq Scan on lzl_p20230601 lzl_1 (cost=0.00..10.20 rows=20 width=106)
 -> Seq Scan on lzl_p20230602 lzl_2 (cost=0.00..10.20 rows=20 width=106)
...
 -> Seq Scan on lzl_p20230630 lzl_30 (cost=0.00..10.20 rows=20 width=106)
 -> Hash (cost=155.10..155.10 rows=30 width=8)
 -> Limit (cost=0.14..154.80 rows=30 width=8)
 -> Append (cost=0.14..154.80 rows=30 width=8)
 -> Index Only Scan using lzl_p20230601_pkey on lzl_p20230601 lzl_32 (cost=0.14..5.16 rows=1 width=8)
 Index Cond: (id = 8723)
 -> Index Only Scan using lzl_p20230602_pkey on lzl_p20230602 lzl_33 (cost=0.14..5.16 rows=1 width=8)
 Index Cond: (id = 8723)
...
 -> Index Only Scan using lzl_p20230630_pkey on lzl_p20230630 lzl_61 (cost=0.14..5.16 rows=1 width=8)
 Index Cond: (id = 8723)
(96 rows)

没有反复（笛卡尔集式地）访问表，RTE只到了61个。这也是为什么400个分区的select可以查询出来的原因，因为400*400次访问实在太多了。所以关于之前的sql，update执行报错，而select正常的情况，可以得出结论：

400个分区的select，它的执行计划中的RTE有801个，没超过INNER_VAR的值65000，它可以生成执行计划并且执行
400个分区的update，它的执行计划中的RTE有160160400个，远远超过INNER_VAR的值65000，不能成功生成执行计划，抛出RTE超限的报错。

原因分析的差不多了，但是select和update的执行计划差别很大，仍然感到疑惑。下面横向对比oracle和mysql的执行计划，看看有什么差别。

ORACLE的行为
#

oracle库创建分区表，并使用本地索引

CREATE TABLE lzl (
 id number NOT NULL,
 partition_key number DEFAULT 0 NOT NULL,
...
)
PARTITION BY RANGE (partition_key)
(
PARTITION lzl_p20230601 VALUES LESS THAN ('20230602'),
PARTITION lzl_p20230602 VALUES LESS THAN ('20230603'),
...
PARTITION lzl_p20230630 VALUES LESS THAN ('20230631'));

create index PKLZL on lzl(id, partition_key) local;
alter table lzl add constraint pklzl primary key (id, partition_key) using index pklzl;

执行计划：

with t as (select id from lzl where id=8723 and rownum<= 100 )
select STATUS ,FILE_ID ,DATE_UPDATED from lzl where id in ( select id from t)

update lzl set
STATUS = '00',
FILE_ID = null,
DATE_UPDATED = sysdate
where id in (select id from lzl where id=8723 and rownum<= 100)

oracle里，select和update都使用了nest loop，访问所有分区partition range all，所以oracle无论是select和update，t表为驱动表，因为是in所以结果进行了排序去重，所以oracle的执行计划不是30*30次访问，而是跟驱动表里的结果集有关，如果是n条数据，那么访问n*30次分区。因为驱动表t没有什么数据，所以这个执行计划没什么问题。

mysql的行为
#

因为mysql只支持本地索引，所以直接建主键就行了

CREATE TABLE test (
 id bigint NOT NULL,
 date_created timestamp ,
...
)
PARTITION BY RANGE (partition_key) 
(
PARTITION lzl_p20230601 VALUES LESS THAN (20230602),
PARTITION lzl_p20230602 VALUES LESS THAN (20230603),
...
PARTITION lzl_p20230630 VALUES LESS THAN (20230631));

alter table lzl add primary key pklzl(id,partition_key);

mysql从5.7开始执行计划会显示扫描了哪些分区，这里的版本是8.0的。 select的执行计划：

> explain with t as (select id from lzl where id=8723 limit 100 )
 -> select STATUS ,FILE_ID ,DATE_UPDATED from lzl where id in ( select id from t);
+----+-------------+------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------+---------------+---------+---------+-------+------+----------+-----------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------+---------------+---------+---------+-------+------+----------+-----------------+
| 1 | PRIMARY | <derived3> | NULL | ALL | NULL | NULL | NULL | NULL | 2 | 100.00 | Start temporary |
| 1 | PRIMARY | lzl | lzl_p20230601,lzl_p20230602,lzl_p20230603,lzl_p20230604,lzl_p20230605,lzl_p20230606,lzl_p20230607,lzl_p20230608,lzl_p20230609,lzl_p20230610,lzl_p20230611,lzl_p20230612,lzl_p20230613,lzl_p20230614,lzl_p20230615,lzl_p20230616,lzl_p20230617,lzl_p20230618,lzl_p20230619,lzl_p20230620,lzl_p20230621,lzl_p20230622,lzl_p20230623,lzl_p20230624,lzl_p20230625,lzl_p20230626,lzl_p20230627,lzl_p20230628,lzl_p20230629,lzl_p20230630 | ref | PRIMARY | PRIMARY | 8 | t.id | 1 | 100.00 | End temporary |
| 3 | DERIVED | lzl | lzl_p20230601,lzl_p20230602,lzl_p20230603,lzl_p20230604,lzl_p20230605,lzl_p20230606,lzl_p20230607,lzl_p20230608,lzl_p20230609,lzl_p20230610,lzl_p20230611,lzl_p20230612,lzl_p20230613,lzl_p20230614,lzl_p20230615,lzl_p20230616,lzl_p20230617,lzl_p20230618,lzl_p20230619,lzl_p20230620,lzl_p20230621,lzl_p20230622,lzl_p20230623,lzl_p20230624,lzl_p20230625,lzl_p20230626,lzl_p20230627,lzl_p20230628,lzl_p20230629,lzl_p20230630 | ref | PRIMARY | PRIMARY | 8 | const | 1 | 100.00 | Using index |

update的执行计划：

> explain with t as (select id from lzl where id=8723 limit 100 )
 -> update lzl set
 -> STATUS = '00',
 -> FILE_ID = null,
 -> DATE_UPDATED = localtimestamp(0) where id in ( select id from t);
+----+-------------+------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------+---------------+---------+---------+-------+------+----------+-----------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------+---------------+---------+---------+-------+------+----------+-----------------+
| 1 | PRIMARY | <derived3> | NULL | ALL | NULL | NULL | NULL | NULL | 2 | 100.00 | Start temporary |
| 1 | UPDATE | lzl | lzl_p20230601,lzl_p20230602,lzl_p20230603,lzl_p20230604,lzl_p20230605,lzl_p20230606,lzl_p20230607,lzl_p20230608,lzl_p20230609,lzl_p20230610,lzl_p20230611,lzl_p20230612,lzl_p20230613,lzl_p20230614,lzl_p20230615,lzl_p20230616,lzl_p20230617,lzl_p20230618,lzl_p20230619,lzl_p20230620,lzl_p20230621,lzl_p20230622,lzl_p20230623,lzl_p20230624,lzl_p20230625,lzl_p20230626,lzl_p20230627,lzl_p20230628,lzl_p20230629,lzl_p20230630 | ref | PRIMARY | PRIMARY | 8 | t.id | 1 | 100.00 | End temporary |
| 3 | DERIVED | lzl | lzl_p20230601,lzl_p20230602,lzl_p20230603,lzl_p20230604,lzl_p20230605,lzl_p20230606,lzl_p20230607,lzl_p20230608,lzl_p20230609,lzl_p20230610,lzl_p20230611,lzl_p20230612,lzl_p20230613,lzl_p20230614,lzl_p20230615,lzl_p20230616,lzl_p20230617,lzl_p20230618,lzl_p20230619,lzl_p20230620,lzl_p20230621,lzl_p20230622,lzl_p20230623,lzl_p20230624,lzl_p20230625,lzl_p20230626,lzl_p20230627,lzl_p20230628,lzl_p20230629,lzl_p20230630 | ref | PRIMARY | PRIMARY | 8 | const | 1 | 100.00 | Using index |

mysql的2个执行计划都一致。但是执行计划驱动表选择有问题，const的应该为驱动表扫描次数会更少。

BUG?
#

bug描述
#

https://postgrespro.com/list/thread-id/2482006 通过报错很容易就能搜到这个bug。这个bug还是德哥在2020年提交的，后面是两个源码大佬对这个bug的讨论，讨论内容比较长，总结一下：pg并不支持无限制的分区表，这在真实世界中也是能理解的，如果分区过多性能可能会急速下降。但是社区还是认为需要调整这个限制，并对源码中的INNER_VAR、Var.varno等进行了讨论。

误导性
#

这个bug标题有一定的误导性，BUG #16302: too many range table entries - when count partition table(65538 childs) bug看上去说分区表的分区不能超过65538个，在讨论中也有PG can handle up to 64K relations in a query，一个查询不能有超过64K的relation。这个就很奇怪，因为我这里的表是400个分区，然后就抛出报错了。实际上上面两个描述不太准确。因为64K的限制指的是执行计划中“表”，不全等于真实的表。当然如果表或者分区已经超过这个数，那么当然会有问题。但是如果没有超过64K，也可能是有问题的，就像我这里的案例一样，它只有400个分区。

修复
#

bug提交的是12.2版本，我的环境是13.2版本的。这个bug在pg15中修复，src/include/nodes/primnodes.h源码跟之前不一样了

#define INNER_VAR		(-1)	/* reference to inner subplan */
#define OUTER_VAR		(-2)	/* reference to outer subplan */
#define INDEX_VAR		(-3)	/* reference to index column */
#define ROWID_VAR		(-4)	/* row identity column during planning */

#define IS_SPECIAL_VARNO(varno)		((int) (varno) < 0)

跟社区讨论的一样，15中不仅把几个VAR都改成了负数，还把varno转换成了32位(40亿），之前是16位的（也就是65536）。而在抛出报错的函数中，src/backend/optimizer/plan/setrefs.c中的add_rte_to_flat_rtable()函数中的报错代码已经被删除了！整个15的源码都没有too many range table entries！

总结
#

pg对于分区表的优化还有提升空间。pg对于分区表的分区，跟oracle、mysql不一样，它仍然子分区当成普通表来处理，而oracle只是把子分区当成一个段来处理，跟表是有差别的。这也导致pg在生产分区表执行计划时把每一个分区的访问方式都写了出来（在不会裁剪的情况下），分区特别多时执行计划会非常的长；而oracle只需要写partition range all就行了；mysql也会打印所有分区，但是不会像pg那样把每个分区的访问当成一个子查询，从而降低了执行计划的复杂度。
即使分区没有达到64K，也可能报错too many range table entries。这个限制其实是执行计划RTE个数，而不是分区个数（当然分区达到这个数，RTE也到达了，就像上面说的，pg打印了所有分区的访问方式）
too many range table entries报错在pg15解决
如果是15以下的版本，确实不要建太多的分区！当然也可以利用分区裁剪来减少分区的访问，就像这个案例，把where逻辑中加上分区键条件就可以了。

没有阻塞为什么partition of创建子分区很慢？

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

create table.. partition of语句慢分析
#

2024-05-16 22:02:59.063 CST,"user1","dblzl",125889,"30.88.79.3:37423",66461213.1ebc1,2,"authentication",2024-05-16 22:02:59 CST,34/41364668,0,LOG,00000,"connection authorized: user=user1 database=dblzl",,,,,,,,,"","client backend"
2024-05-16 22:02:59.079 CST,"user1","dblzl",125889,"30.88.79.3:37423",66461213.1ebc1,3,"idle",2024-05-16 22:02:59 CST,34/41364669,0,LOG,00000,"statement: -- a86fae372f73414bbe1af18213a47beb
/*a86fae372f73414bbe1af18213a47beb */
create table if not exists table1_partition_p2406 partition of table1 for values from ('2024-06-01 00:00:00') to ('2024-07-01 00:00:00'); ",,,,,,,,,"","client backend"
...
2024-05-16 22:38:28.555 CST,"user1","dblzl",125889,"30.88.79.3:37423",66461213.1ebc1,4,"CREATE TABLE",2024-05-16 22:02:59 CST,34/0,0,LOG,00000,"duration: 2129483.549 ms",,,,,,,,,"","client backend"

user1这个用户在22:02:59连接进入数据库后，立即就执行了一个create table.. partition of..的语句，直到22:38:28才跑完。中间的日志忽略了，一大堆会话阻塞信息，阻塞源均是125889这个会话。被阻塞的会话类似如下：

process 33569 still waiting for RowExclusiveLock on relation 53733 of database 17073 after 1000.048 ms","Process holding the lock: 125889. Wait queue: 33569.

partition of添加分区时，会在主表上加8级锁，然后阻塞分区表上的所有操作。正常来说partition of添加分区是非常快的，锁也会立即释放。不过如果分区表上有长事务，那么这个主表上的8级锁得等着，然后就造成后续的阻塞。盗自己的图：

然而这个案例表上没有长事务，partition of添加分区却执行了35分钟。从历史的进程信息可以看出这个进程是D状态，是有问题的。刚开始以为是内存、磁盘这些问题，排查了一圈都正常。

然而这个问题很好复现，直接在仿真环境上跑一个create table parttion of执行会非常慢。pg_stat_activity会话信息显示，该语句等待在IO上：

wait_event_type | IO
wait_event	 | DataFileRead
state		| active
query		| create table xxx partition of xx for values from ('2025-05-01 00:00:00') to ('2025-06-01 00:00:00');

strace追踪进程信息发现，该进程大量的读取一个文件

pread64(53, "\22\2\0\0\220w\321>\0\0\5\0\24\0018\1\0 \4 \0\0\0\0\200\237\0\1\310\236p\1"..., 8192, 863485952) = 8192

通过文件描述符53找到该文件

[/proc/356174/fd] ll |grep 53
lrwx------ 1 postgres postgres 64 May 17 15:34 53 -> /lzl/pglzl/data/base/17076/25883

oid2name -d lzldb -f 25883
From database "lzldb":
 Filenode				 Table Name
-----------------------------------------------
 25883 table_partition_default

最后定位这个表table_partition_default

=> \d+ table_partition_default
...
Partition of: table_partition_default DEFAULT
Partition constraint: (NOT ((date_created IS NOT NULL) AND ((date_created < '2022-05-01 00:00:00'::timestamp without time zone) OR ((date_created >= '2022-05-01 00:00:00'::timestamp without time zone) AND (da


=> \dt+ table_partition_default
 List of relations
 Schema | Name | Type | Owner | Persistence | Size | Description 
--------+------------------------------------+-------+------------+-------------+-------+-------------
 public | table_partition_default | table | user1 | permanent | 50 GB | 
(1 row)

原来是default分区表，分区数据有几十GB。oracle dba可能很陌生···pg的default分区会接收不在分区范围中的数据，default分区可以保证即使没有定义到数据范围，也可以接收数据。如果有数据存在default分区中，新分区又需要包含这部分数据，那这个游戏咋玩呢···直接报错：

=> create table if not exists table_partition_pxxxx partition of table_partition for values from ('2023-01-12 00:00:00') to ('2023-01-13 00:00:00');
ERROR: 23514: updated partition constraint for default partition "table_partition_default" would be violated by some row
SCHEMA NAME: public
TABLE NAME: table_partition_default
LOCATION: check_default_partition_contents, partbounds.c:3227

可以看到，添加子分区时，会自动修改default分区的分区约束（Partition constraint）,default分区约束检查即是在做添加普通子分区时的default分区数据校验。

到这原因已经很明显：分区表新增子分区时，由于建分区的语句需要校验default分区中的数据，保证新分区数据范围与default分区的现有数据不冲突，导致create table partition of读取了大量的default分区数据，新建分区一直未完成。随后阻塞扩大，业务数据无法查询和写入。

小结和建议
#

postgresql分区表使用的越来越多了，维护分区还有很多需要注意的知识点，推荐看下PostgreSQL分区表，几乎面面俱到。

在这个案例中，改造关键在于default分区的数据。在default改造前，不要使用partition of方式创建子分区。 default分区改造方案：

detach default子分区，然后合理创建子分区，再将default表数据回插到分区表中。
如有必要，可在detach且创建合理子分区后，创建一个空的default分区，以保持业务数据的连续性。
注意detach跟attach不同，detach需要主表的8级锁。PG14支持detach concurrently。

如不改造default分区，应检查当前default分区的数据范围。再用attach添加子分区，会很慢，但不会阻塞读写。

最后在复习下分区表新增分区最佳实践： partition of添加子分区要申请主表的8级锁，风险还是有的。推荐attach方式为表新增子分区（分区索引也可以这么做），不会阻塞读写，完全不影响业务，可在线执行。 分区表添加新分区的正确姿势：

CREATE TABLE lzlpartition1_202303
 (LIKE lzlpartition1 INCLUDING DEFAULTS INCLUDING CONSTRAINTS);
alter table LZLPARTITION1 attach partition LZLPARTITION1_202303 for values from ('2023-03-01 00:00:00') to ('2023-04-01 00:00:00');

如果新分区还有数据的话，attach还可能比较慢，可提前创建约束来优化 分区表添加有数据分区的正确姿势：

--减少繁琐的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;

我要查的表没有在执行计划中

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

问题：查的表没有在执行计划中
#

sql：

SELECT
 *
FROM
 (
 SELECT
 A.column1 as "column1",
 --中间省略很多A字段
 A.column99 as "column99"
 from
 table_a A
 left join (
 SELECT
 lzl_id
 from
 table_a AA
 inner join table_b BB ON AA.lzl_key = BB.lzl_id
 where
 AA.column_code = '1'
 GROUP BY
 lzl_id
 ) B ON B.lzl_id = A.lzl_key
 where
 A.flagflagflag = '1'
 AND A.typetypetype = '2'
 ) TEMP
limit
 100
offset
 1000

执行计划：

 QUERY PLAN 
----------------------------------------------------------------------------------------------------------------------------------
 Limit (cost=2.84..5.68 rows=1 width=1105) (actual time=0.038..0.039 rows=0 loops=1)
 Buffers: shared hit=2
 -> Seq Scan on table_a a (cost=0.00..2.84 rows=1 width=1105) (actual time=0.036..0.037 rows=0 loops=1)
 Filter: (((flagflagflag)::text = '1'::text) AND ((typetypetype)::text = '2'::text))
 Rows Removed by Filter: 38
 Buffers: shared hit=2
 Planning Time: 0.184 ms
 Execution Time: 0.066 ms

可以看到，sql本身是比较复杂的，SQL的逻辑查了3次表，总共查了2张表。table_a 在执行计划中我可以理解，但是需要查的table_b根本没在执行计划里面！这个执行计划只不过是简单的全表扫描了table_a。

分析的心路历程
#

中间其实想过很多可能，不过最有可能的是逻辑优化了，也就是说pg优化器认为table_b不需要查。观察sql发现sql最终只查询了table_a的字段，没有查table_b。此时任意增加一个中间表B的字段，sql执行计划看上去就“正常”了，访问了table_b

explain SELECT
 *
FROM
 (
 SELECT
 A.column1 as "column1",
 --中间省略很多A字段
 A.column99 as "column99",
 B.lzl_id --新增一个B中间表的字段
 from
 table_a A
 left join (
 SELECT
 lzl_id
 from
 table_a AA
 inner join table_b BB ON AA.lzl_key = BB.lzl_id
 where
 AA.column_code = '1'
 GROUP BY
 lzl_id
 ) B ON B.lzl_id = A.lzl_key
 where
 A.flagflagflag = '1'
 AND A.typetypetype = '2'
 ) TEMP
limit
 100
offset
 1000

---------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit (cost=14.69..17.67 rows=1 width=1113)
 -> Nested Loop Left Join (cost=11.72..14.69 rows=1 width=1113)
 Join Filter: (bb.lzl_id = a.lzl_key)
 -> Seq Scan on table_a a (cost=0.00..2.84 rows=1 width=1113)
 Filter: (((flagflagflag)::text = '1'::text) AND ((typetypetype)::text = '2'::text))
 -> Group (cost=11.72..11.74 rows=5 width=8)
 Group Key: bb.lzl_id
 -> Sort (cost=11.72..11.73 rows=5 width=8)
 Sort Key: bb.lzl_id
 -> Nested Loop (cost=0.15..11.66 rows=5 width=8)
 -> Seq Scan on table_a aa (cost=0.00..2.70 rows=1 width=8)
 Filter: ((company_code)::text = '1'::text)
 -> Index Only Scan using idx_table_b_lzl_id on table_b bb (cost=0.15..8.83 rows=13 width=8)
 Index Cond: (lzl_id = aa.lzl_key)

这看上去跟left join有关系，但是简单想想又不对，因为右表的结果是会影响查询的最终结果的，不应该不去查右表。随便来个简单的left join，右表会被扫描

explain select lzlleft.a from lzlleft left join lzlright on lzlleft.a=lzlright.a;
 QUERY PLAN 
--------------------------------------------------------------------
 Hash Left Join (cost=1.04..15.47 rows=320 width=4)
 Hash Cond: (lzlleft.a = lzlright.a)
 -> Seq Scan on lzlleft (cost=0.00..13.20 rows=320 width=4)
 -> Hash (cost=1.02..1.02 rows=2 width=4)
 -> Seq Scan on lzlright (cost=0.00..1.02 rows=2 width=4)

但是，在中间表B中，有个关键字GROUP BY。如果把GROUP BY去掉，那么无论有没有查询B的字段，都会访问table_b。我们再在测试表中加个group by看看结果

> select * from lzlleft;
 a | b 
---+-----
 1 | zzz
(1 row)

Time: 0.259 ms
> select * from lzlright;
 a | b 
---+-------
 1 | qwer
 1 | poiuy 
 
> select lzlright.b from lzlleft full join lzlright on lzlleft.b=lzlright.b group by lzlright.b;
 b 
--------
 [null]
 poiuy
 qwer
(3 rows)

这里就意识到了group by出来的结果集一定有一个特性——唯一性。我们再在测表里加group by

explain select lzlleft.a from lzlleft left join (select a from lzlright group by a) c on lzlleft.a=c.a;
 QUERY PLAN 
----------------------------------------------------------
Seq Scan on lzlleft (cost=0.00..13.20 rows=320 width=4)

右表不查了！根据右表唯一性的原则，下面还可以有一些骚操作：

--distinct确保右表唯一
> explain select lzlleft.a from lzlleft left join (select distinct a from lzlright) c on lzlleft.a=c.a;
 QUERY PLAN 
----------------------------------------------------------
Seq Scan on lzlleft (cost=0.00..13.20 rows=320 width=4) 

--唯一索引确保右表唯一，哪怕是select a from lzlright
> explain select lzlleft.a from lzlleft left join (select a from lzlright) c on lzlleft.a=c.a;
 QUERY PLAN 
-----------------------------------------------------------------------
Hash Left Join (cost=17.20..49.12 rows=512 width=4)
 Hash Cond: (lzlleft.a = lzlright.a)
 -> Seq Scan on lzlleft (cost=0.00..13.20 rows=320 width=4)
 -> Hash (cost=13.20..13.20 rows=320 width=4)
 -> Seq Scan on lzlright (cost=0.00..13.20 rows=320 width=4)
(5 rows)

Time: 0.510 ms
> create unique index idx_right on lzlright(a);
CREATE INDEX
Time: 3.576 ms
> explain select lzlleft.a from lzlleft left join (select a from lzlright) c on lzlleft.a=c.a;
 QUERY PLAN 
----------------------------------------------------------
Seq Scan on lzlleft (cost=0.00..13.20 rows=320 width=4)
(1 row)

到这里来个分析小结：只要右表的数据是唯一的且只查询左表数据时，不需要真的去访问右表。所以这不是一个bug，而是PG优化器的特性，是符合逻辑的。

源码分析
#

本期没有源码分析~ 优化器源码实在太难了，这里就找了下优化器源码的注释看了下。可以搜索关键字unique-ify，有这么一句话：

 * Also, this routine and others in this module accept the special JoinTypes
 * JOIN_UNIQUE_OUTER and JOIN_UNIQUE_INNER to indicate that we should
 * unique-ify the outer or inner relation and then apply a regular inner
 * join. These values are not allowed to propagate outside this module,
 * however. Path cost estimation code may need to recognize that it's
 * dealing with such a case --- the combination of nominal jointype INNER
 * with sjinfo->jointype == JOIN_SEMI indicates that. 

特殊的JoinTypes：JOIN_UNIQUE_INNER 和JOIN_UNIQUE_OUTER ，尝试把外表和内表连接唯一化后，成为inner join。Path代价估算需要考虑这种场景。

与oracle、mysql优化器的对比
#

对比看下oracle、mysql优化器有没有类似的逻辑优化提升

--oracle
create table lzlleft(a number);
create table lzlright(a number);
 select lzlleft.a from lzlleft left join (select distinct a from lzlright) c on lzlleft.a=c.a;

--group by 唯一性
SQL> select lzlleft.a from lzlleft left join (select a from lzlright group by a) c on lzlleft.a=c.a; 

no rows selected


Execution Plan
----------------------------------------------------------
Plan hash value: 3533354041

---------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 26 | 5 (20)| 00:00:01 |
|* 1 | HASH JOIN OUTER | | 1 | 26 | 5 (20)| 00:00:01 |
| 2 | TABLE ACCESS FULL | LZLLEFT | 1 | 13 | 2 (0)| 00:00:01 |
| 3 | VIEW | | 1 | 13 | 3 (34)| 00:00:01 |
| 4 | HASH GROUP BY | | 1 | 13 | 3 (34)| 00:00:01 |
| 5 | TABLE ACCESS FULL| LZLRIGHT | 1 | 13 | 2 (0)| 00:00:01 |
---------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

 1 - access("LZLLEFT"."A"="C"."A"(+))

--ditinct 唯一 
SQL> select lzlleft.a from lzlleft left join (select distinct a from lzlright) c on lzlleft.a=c.a;

no rows selected


Execution Plan
----------------------------------------------------------
Plan hash value: 3859658234

---------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 26 | 5 (20)| 00:00:01 |
|* 1 | HASH JOIN OUTER | | 1 | 26 | 5 (20)| 00:00:01 |
| 2 | TABLE ACCESS FULL | LZLLEFT | 1 | 13 | 2 (0)| 00:00:01 |
| 3 | VIEW | | 1 | 13 | 3 (34)| 00:00:01 |
| 4 | HASH UNIQUE | | 1 | 13 | 3 (34)| 00:00:01 |
| 5 | TABLE ACCESS FULL| LZLRIGHT | 1 | 13 | 2 (0)| 00:00:01 |
---------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

 1 - access("LZLLEFT"."A"="C"."A"(+))

--mysql 
create table lzlleft(a int primary key);
create table lzlright(a int primary key);

--group by唯一
explain select lzlleft.a from lzlleft left join (select a from lzlright group by a) c on lzlleft.a=c.a; 
+----+-------------+------------+------------+-------+---------------+-------------+---------+-----------------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+------------+------------+-------+---------------+-------------+---------+-----------------+------+----------+-------------+
| 1 | PRIMARY | lzlleft | NULL | index | NULL | PRIMARY | 4 | NULL | 1 | 100.00 | Using index |
| 1 | PRIMARY | <derived2> | NULL | ref | <auto_key0> | <auto_key0> | 4 | lzldb.lzlleft.a | 2 | 100.00 | Using index |
| 2 | DERIVED | lzlright | NULL | index | PRIMARY | PRIMARY | 4 | NULL | 1 | 100.00 | Using index |
+----+-------------+------------+------------+-------+---------------+-------------+---------+-----------------+------+----------+-------------+

--distinct唯一
explain select lzlleft.a from lzlleft left join (select distinct a from lzlright) c on lzlleft.a=c.a;
+----+-------------+------------+------------+-------+---------------+-------------+---------+-----------------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+------------+------------+-------+---------------+-------------+---------+-----------------+------+----------+-------------+
| 1 | PRIMARY | lzlleft | NULL | index | NULL | PRIMARY | 4 | NULL | 1 | 100.00 | Using index |
| 1 | PRIMARY | <derived2> | NULL | ref | <auto_key0> | <auto_key0> | 4 | lzldb.lzlleft.a | 2 | 100.00 | Using index |
| 2 | DERIVED | lzlright | NULL | index | PRIMARY | PRIMARY | 4 | NULL | 1 | 100.00 | Using index |
+----+-------------+------------+------------+-------+---------------+-------------+---------+-----------------+------+----------+-------------+

综上，oracle、mysql均不会对left join只查左表且右表唯一做优化，他们会访问右表。 pg优化器确实是有些东西的。

长事务、表膨胀、limit问题的一个经典案例

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

update主键慢，问题分析
#

一个简单的主键更新，update执行了超过1s，由于并发比较高，cpu直接打满

2024-04-01 10:19:36.084 CST,"lzlopr","lzl",158751,"10.33.78.149:51502",66055a6b.26c1f,172,"UPDATE",2024-03-28 19:54:19 CST,528/19816630,970251337,LOG,00000,"duration: 1218.688 ms plan:
Query Text: update table_a set (省略...）=$6 where column_id =$7
Update on table_a (cost=0.40..5.49 rows=1 width=2774)
-> Index Scan using pk_id on table_a (cost=0.40..5.49 rows=1 width=2774)
 Index Cond: ((column_id)::text = $7)",,,,,,,,,"PostgreSQL JDBC Driver","client backend"

sql本身也非常简单，就是条件为=‘主键’的更新。看update的执行计划，是走了pk主键索引的，所以从执行计划上看没有问题，问题不在执行计划突变。

改写下sql（因为是update），explain (analyze,buffers)对比看下SQL的执行消耗

=> explain (analyze,buffers) select * from table_a where column_id='d4f713370e584820a9b15e2218ea436a';
 QUERY PLAN 
---------------------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on table_a (cost=2.91..5.42 rows=1 width=1156) (actual time=55.052..123.354 rows=1 loops=1)
 Recheck Cond: ((column_id)::text = 'd4f713370e584820a9b15e2218ea436a'::text)
 Heap Blocks: exact=1
 Buffers: shared hit=13870
 -> Bitmap Index Scan on pk_id (cost=0.00..2.91 rows=1 width=0) (actual time=3.464..3.465 rows=13866 loops=1)
 Index Cond: ((column_id)::text = 'd4f713370e584820a9b15e2218ea436a'::text)
 Buffers: shared hit=24
 Planning:
 Buffers: shared hit=4261
 Planning Time: 11.028 ms
 Execution Time: 123.567 ms
(11 rows)

这里的真实执行计划没问题，但是shared hit=13870明显太高了。正常来说走主键不应该扫描太多的page，这里比较容易联想到表膨胀

查看表膨胀：

--表大小 \dt
Size | 525 MB

--表的实际行数
count | 827

--死元组 pg_stat_all_tables
n_live_tup | 786
n_dead_tup | 657604

有只有800条活元组，但是有65w条死元组！主键扫描了多个page的原因应该就是这个，但是为啥没有回收死元组呢？表在默认修改20%数据的时候就会触发autovacuum执行vacuum回收，这个在日志中可以看到，autovacuum是有被触发的：

2024-04-01 14:13:46.649 CST,,,14081,,660a5099.3701,1,,2024-04-01 14:13:45 CST,259/17828993,0,LOG,00000,"automatic vacuum of table ""lzl.public.table_a"": index scans: 0
2024-04-01 14:13:47.801 CST,,,14081,,660a5099.3701,2,,2024-04-01 14:13:45 CST,259/17828994,971045014,LOG,00000,"automatic analyze of table ""lzl.public.table_a"" system usage: CPU: user: 0.08 s, system: 0.01 s, elapsed: 1.15 s",,,,,,,,,"","autovacuum worker"
2024-04-01 14:14:46.673 CST,,,26136,,660a50d5.6618,1,,2024-04-01 14:14:45 CST,259/17829090,0,LOG,00000,"automatic vacuum of table ""lzl.public.table_a"": index scans: 0
2024-04-01 14:14:47.833 CST,,,26136,,660a50d5.6618,2,,2024-04-01 14:14:45 CST,259/17829091,971049759,LOG,00000,"automatic analyze of table ""lzl.public.table_a"" system usage: CPU: user: 0.08 s, system: 0.03 s, elapsed: 1.15 s",,,,,,,,,"","autovacuum worker"
2024-04-01 14:15:46.680 CST,,,40743,,660a5111.9f27,1,,2024-04-01 14:15:45 CST,259/17829164,0,LOG,00000,"automatic vacuum of table ""lzl.public.table_a"": index scans: 0
2024-04-01 14:15:47.849 CST,,,40743,,660a5111.9f27,2,,2024-04-01 14:15:45 CST,259/17829165,971055464,LOG,00000,"automatic analyze of table ""lzl.public.table_a"" system usage: CPU: user: 0.08 s, system: 0.03 s, elapsed: 1.16 s",,,,,,,,,"","autovacuum worker"
2024-04-01 14:16:46.677 CST,,,52599,,660a514d.cd77,1,,2024-04-01 14:16:45 CST,259/17829263,0,LOG,00000,"automatic vacuum of table ""lzl.public.table_a"": index scans: 0
2024-04-01 14:16:47.844 CST,,,52599,,660a514d.cd77,2,,2024-04-01 14:16:45 CST,259/17829264,971061382,LOG,00000,"automatic analyze of table ""lzl.public.table_a"" system usage: CPU: user: 0.08 s, system: 0.03 s, elapsed: 1.16 s",,,,,,,,,"","autovacuum worker"
2024-04-01 14:17:46.699 CST,,,64858,,660a5189.fd5a,1,,2024-04-01 14:17:45 CST,234/16589539,0,LOG,00000,"automatic vacuum of table ""lzl.public.table_a"": index scans: 0
2024-04-01 14:17:47.851 CST,,,64858,,660a5189.fd5a,2,,2024-04-01 14:17:45 CST,234/16589540,971066091,LOG,00000,"automatic analyze of table ""lzl.public.table_a"" system usage: CPU: user: 0.09 s, system: 0.02 s, elapsed: 1.15 s",,,,,,,,,"","autovacuum worker"
2024-04-01 14:18:46.703 CST,,,78112,,660a51c5.13120,1,,2024-04-01 14:18:45 CST,259/17829409,0,LOG,00000,"automatic vacuum of table ""lzl.public.table_a"": index scans: 0
2024-04-01 14:18:47.854 CST,,,78112,,660a51c5.13120,2,,2024-04-01 14:18:45 CST,259/17829410,971070390,LOG,00000,"automatic analyze of table ""lzl.public.table_a"" system usage: CPU: user: 0.09 s, system: 0.02 s, elapsed: 1.15 s",,,,,,,,,"","autovacuum worker"		

不仅有触发，而且间隔刚好是一分钟。autovacuum_naptime间隔触发时间默认就是1分钟

>= show autovacuum_naptime ;
 autovacuum_naptime 
--------------------
 1min
(1 row)

可以判断：

autovacuum成功触发
死元组可能回收不及，1分钟内产生的死元组大于20%（可能1分钟太长了）；或者根本没有回收，下次一定触发autovacuum

看下autovacuum的具体内容：

2024-04-01 10:22:44.648 CST,,,16827,,660a1a73.41bb,1,,2024-04-01 10:22:43 CST,170/16910186,0,LOG,00000,"automatic vacuum of table ""lzl.public.table_a"": index scans: 0
pages: 0 removed, 48745 remain, 6 skipped due to pins, 0 skipped frozen
tuples: 0 removed, 744488 remain, 743666 are dead but not yet removable, oldest xmin: 969118077
buffer usage: 97603 hits, 0 misses, 5 dirtied
avg read rate: 0.000 MB/s, avg write rate: 0.028 MB/s
system usage: CPU: user: 0.21 s, system: 0.22 s, elapsed: 1.41 s
WAL usage: 4 records, 3 full page images, 5129 bytes",,,,,,,,,"","autovacuum worker"

autovacuum触发了，但是完全没有回收死元组tuples: 0 removed, 744488 remain, 743666 are dead but not yet removable, oldest xmin: 969118077。oldest xmin代表库内的最旧事务，也就是有长事务，这个很好找到：

>= select pid,usename,xact_start,state_change,wait_event,state,query from pg_stat_activity where state<>'idle' order by xact_start ;
 pid | usename | xact_start | state_change | wait_event | state | 
--------+------------+-------------------------------+-------------------------------+---------------------+---------------------+------------------------------------------------------------------------------
 164658 | phbdspsqp | 2024-04-01 08:36:57.275408+08 | 2024-04-01 08:36:57.299609+08 | DataFileRead | active | SELECT "minval","maxval" FROM (select min(ID) as minval,max(TRACK

长事务就是这个早上8点多跑了几个小时sql。虽然不是一个表，但是因为是oldest xmin所以也会有影响。至此原因已经定位：

表A的update频繁，表膨胀风险较高
表B长事务阻止表A死元组回收
表A的update语句扫描了过多的page

解决办法：

结束长事务。select pg_terminate_backend(164658)
手动vacuum或者等待1分钟（以内）自动vacuum。 vacuum table_a

上面2个操作完成后，查看死元组

n_live_tup | 707
n_dead_tup | 298

65w的死元组已清理。再次查看执行计划：

=> explain (analyze,buffers) select * from table_a where column_id='d4f713370e584820a9b15e2218ea436a';
 QUERY PLAN 
-------------------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using pk_id on table_a (cost=0.40..5.44 rows=1 width=621) (actual time=0.026..0.029 rows=1 loops=1)
 Index Cond: ((column_id)::text = 'd4f713370e584820a9b15e2218ea436a'::text)
 Buffers: shared hit=6
 Planning Time: 0.057 ms
 Execution Time: 0.043 ms

shared hit只有6，故障恢复。

另外，vacuum只会回收死元组，但是不会清理空间，表还是那么大。这个只有等新数据复用空间或者repack等重建表的操作来回收

Size | 525 MB

order by limit的番外sql优化：
#

刚才那个长事务sql，也有问题··· 业务反馈前几天都快，今天跑了几个小时了

explain select min(ID) as minval,max(ID) as maxval from table_b where time_at >= to_timestamp('2024-03-30 00:00:00','yyyy-MM-dd HH24:mi:ss');
 QUERY PLAN 
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
Result (cost=4298.54..4298.55 rows=1 width=64)
 InitPlan 1 (returns $0)
 -> Limit (cost=0.70..2149.27 rows=1 width=32)
 -> Index Scan using pk_b on table_b (cost=0.70..1181490202.27 rows=549896 width=32)
 Index Cond: ((ID)::text IS NOT NULL)
 Filter: (time_at >= to_timestamp('2024-03-30 00:00:00'::text, 'yyyy-MM-dd HH24:mi:ss'::text))
 InitPlan 2 (returns $1)
 -> Limit (cost=0.70..2149.27 rows=1 width=32)
 -> Index Scan Backward using pk_b on table_b table_b_1 (cost=0.70..1181490202.27 rows=549896 width=32)
 Index Cond: ((ID)::text IS NOT NULL)
 Filter: (time_at >= to_timestamp('2024-03-30 00:00:00'::text, 'yyyy-MM-dd HH24:mi:ss'::text))

sql也很简单，条件只有一个时间字段，过滤性还可以不过这个sql没有走 time_at 索引，而是走的 ID主键索引。这个跟limit问题是一样的。analyze是没有用的，最好是改写sql。改写后SQL结果秒出：

explain select min(ID||'') as minval,max(ID||'') as maxval from table_b where time_at >= to_timestamp('2024-03-30 00:00:00','yyyy-MM-dd HH24:mi:ss')

 QUERY PLAN 
----------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=1201418.86..1201418.87 rows=1 width=64)
 -> Index Scan using idx_time_at on table_b (cost=0.57..1195919.90 rows=549896 width=33)
 Index Cond: (time_at >= to_timestamp('2024-03-30 00:00:00'::text, 'yyyy-MM-dd HH24:mi:ss'::text))

这个还不是执行计划突变，因为没有变。前几天同样是这样的执行计划，但是跑的比较快，原因是还是因为数据分布和limit的机制，数据很快就找到自然就返回了，这也是优化器为什么会选择主键索引；“运气不好”数据半天找不到就要跑很久。

小结
#

一个经典的案例：

update频繁更新的小表
长事务阻止死元组回收
长事务是排序和limt操作（order by，max/min，group都有可能）导致的索引选择问题

一个故障，三个postgres的经典知识点，相当有代表性。

PostgreSQL案例 on 最后的DBA

案例-起库失败和sysv共享内存

问题现象 #

报错分析：pre-existing shared memory block #

3种共享内存 #

源码分析 #

sysv shmem #

什么是shmkey和shmid #

PG是怎么拿shmkey的 #

PG在云环境下的shmkey #

shmid的关联性 #

测试 #

生产问题复现 #

实例奔溃正常起库 #

持有文件但不持有shmem #

删除postmaster.pid文件起库失败 #

关闭一个其他库，启动当前库 #

报错分析：lock file "postmaster.pid" already exists #

总结 #

pg数据库运维经验2025

CPU #

执行计划 #

DISTINCT不准确 #

generic plan的干扰 #

行锁导致的LWLock:Lockmanager #

idle连接数 #

idle in transaction #

内存 #

内存问题和大页 #

值得注意的cgroup知识 #

未解之谜 #

关注OS #

关注OS的一切 #

物理读 #

autovacuum #

大库的autovacuum freeze #

大表跑不动 #

checkpoint和bgwriter #

DB4AI #

AI任务调度信息写入数据库 #

vector hnsw #

HNSW索引构建加速 #

HNSW索引查询速度 #

业务发版 #

ddl的技巧 #

并发创建索引 #

cached plan must not change resource #

物理复制 #

查询冲突 #

逻辑复制 #

低版本PG+DDL/DCL语句解析较慢 #

低版本PG+多链路重复解析+flink #

低版本PG无法自动同步新分区 #

迁移和升级 #

迁移信创和glibc升级 #

丝滑大版本升级 #

分区表的管理 #

可观测性 #

buffers_alloc、blks_read #

tup_fetched、tup_returned #

idx_tup_fetch 、idx_tup_read #

参考内容 #

案例-20260101分区数据更新失败

现象 #

临时恢复 #

根因分析 #

疑问一：为什么update没有更新202601的数据（新分区根本没有数据），仍然报错 #

疑问二：表是20251226创建的,为什么是10月30日发现有问题 #

总结 #

ref #

案例-行锁与LWlock-lockmanger

现象 #

分析 #

SQL未见并发上涨 #

LWlock lockmanager分析 #

压测 #

压测同一行更新产生LWLock LockManager #

行锁与fastpath浅析 #

总结 #

案例-从distinct不准确到DISTINCT的计算原理

问题现象
#

报错分析：`pre-existing shared memory block`
#

3种共享内存
#

源码分析
#

sysv shmem
#

什么是shmkey和shmid
#

PG是怎么拿shmkey的
#

PG在云环境下的shmkey
#

shmid的关联性
#

测试
#

生产问题复现
#

实例奔溃正常起库
#

持有文件但不持有shmem
#

删除postmaster.pid文件起库失败
#

关闭一个其他库，启动当前库
#

报错分析：`lock file "postmaster.pid" already exists`
#

总结
#

CPU
#

执行计划
#

DISTINCT不准确
#

generic plan的干扰
#

行锁导致的LWLock:Lockmanager
#

idle连接数
#

idle in transaction
#

内存
#

内存问题和大页
#

值得注意的cgroup知识
#

未解之谜
#

关注OS
#

关注OS的一切
#

物理读
#

autovacuum
#

大库的autovacuum freeze
#

大表跑不动
#

checkpoint和bgwriter
#

DB4AI
#

AI任务调度信息写入数据库
#

vector hnsw
#

HNSW索引构建加速
#

HNSW索引查询速度
#

业务发版
#

ddl的技巧
#

并发创建索引
#

cached plan must not change resource
#

物理复制
#

查询冲突
#

逻辑复制
#

低版本PG+DDL/DCL语句解析较慢
#

低版本PG+多链路重复解析+flink
#

低版本PG无法自动同步新分区
#

迁移和升级
#

迁移信创和glibc升级
#

丝滑大版本升级
#

分区表的管理
#

可观测性
#

buffers_alloc、blks_read
#

tup_fetched、tup_returned
#

idx_tup_fetch 、idx_tup_read
#

参考内容
#

现象
#

临时恢复
#

根因分析
#

疑问一：为什么update没有更新202601的数据（新分区根本没有数据），仍然报错
#

疑问二：表是20251226创建的,为什么是10月30日发现有问题
#

总结
#

ref
#

现象
#

分析
#

SQL未见并发上涨
#

LWlock lockmanager分析
#

压测
#

压测同一行更新产生LWLock LockManager
#

行锁与fastpath浅析
#

总结
#

问题现象
#

问题分析
#

采样模型
#

distinct预估算法
#

验证
#

解决
#