Author: 卓刀
根据之前月报的分析，PostgreSQL中的MVCC机制（详见月报）同时存储新旧版本的元组，对于经常更新的表来说，会造成表膨胀的情况。为了解决这个问题，PostgreSQL 引入了VACUUM和ANALYZE命令，并且引入了AutoVacuum自动清理。
在PostgreSQL中，AutoVacuum自动清理操作包括：
为了实现自动清理，PostgreSQL引入了两种类型的辅助进程：
本文主要分析autovacuum launcher进程相关操作，autovacuum worker比较复杂和重要，我们将在下期月报详细分析。
autovacuum launcher 进程可以理解为AutoVacuum机制的守护进程，周期性地调度autovacuum worker进程。
autovacuum launcher 进程在postgresql.conf文件中的相关配置参数（支持对每个表单独配置参数，方法见文档）如下：
因为AutoVacuum依赖于统计信息，所以只有track_counts=on 且autovacuum=on 时，PostgreSQL才启动autovacuum launcher 进程。
autovacuum launcher 进程会周期性地创建autovacuum worker 进程，最多能够创建autovacuum_max_workers个autovacuum worker 进程。我们将会从下面二个方面来分析autovacuum launcher：
上文的参数autovacuum_naptime决定了autovacuum launcher 的基本执行周期。在PostgreSQL中，理想状态是在autovacuum_naptime的时间内对所有的数据库进行一次清理，即每个数据库希望能够分配到autovacuum_naptime/(数据库的个数) 的时间片去创建一个autovacuum worker进行自动清理。这就要求autovacuum launcher 进程每经过autovacuum_naptime/(数据库的个数) 的时间就要被唤醒，并启动对应的autovacuum worker 进程。
基于此设计思想，autovacuum launcher 进程中维护了一个数据库列表DatabaseList，其中维护了各个database的期望AutoVacuum时间等信息，具体的元素结构如下：
/* struct to keep track of databases in launcher */
typedef struct avl_dbase
{
Oid adl_datid; /* hash key -- must be first */
TimestampTz adl_next_worker;
int adl_score;
dlist_node adl_node;
} avl_dbase;
其中：
struct dlist_node
{
dlist_node *prev;
dlist_node *next;
};
当autovacuum launcher初始化时，DatabaseList为空，需要重建，具体步骤如下：
可以看出，创建完成之后，DatabaseList中存储按照期望执行自动化清理的时间从大到小排序的数据库信息。
通过分析代码发现，autovacuum launcher进程的执行周期主要是由launcher_determine_sleep 函数来决定的：
如果当前的时间已经晚于第2种情况得到的时间戳，则纠正为autovacuum launcher最小的休眠时间100ms。
综上所述，我们知道：
因为AutoVacuum的具体过程会消耗数据库资源（比如CPU），可能影响性能，在PostgreSQL中规定，autovacuum launcher可以启动最多autovacuum_max_workers个autovacuum worker 进程。为了管理autovacuum worker 进程，PostgreSQL维护了共享内存AutoVacuumShmemStruct来存储当前所有autovacuum worker的情况，其结构如下：
typedef struct
{
sig_atomic_t av_signal[AutoVacNumSignals];
pid_t av_launcherpid;
dlist_head av_freeWorkers;
dlist_head av_runningWorkers;
WorkerInfo av_startingWorker;
AutoVacuumWorkItem av_workItems[NUM_WORKITEMS];
} AutoVacuumShmemStruct;
其中：
/*-------------
* This struct holds information about a single worker's whereabouts. We keep
* an array of these in shared memory, sized according to
* autovacuum_max_workers.
*
* wi_links entry into free list or running list
* wi_dboid OID of the database this worker is supposed to work on
* wi_tableoid OID of the table currently being vacuumed, if any
* wi_sharedrel flag indicating whether table is marked relisshared
* wi_proc pointer to PGPROC of the running worker, NULL if not started
* wi_launchtime Time at which this worker was launched
* wi_cost_* Vacuum cost-based delay parameters current in this worker
*
* All fields are protected by AutovacuumLock, except for wi_tableoid which is
* protected by AutovacuumScheduleLock (which is read-only for everyone except
* that worker itself).
*-------------
*/
typedef struct WorkerInfoData
{
dlist_node wi_links;
Oid wi_dboid;
Oid wi_tableoid;
PGPROC *wi_proc;
TimestampTz wi_launchtime;
bool wi_dobalance;
bool wi_sharedrel;
int wi_cost_delay;
int wi_cost_limit;
int wi_cost_limit_base;
} WorkerInfoData;
从上面可以看出，autovacuum launcher中维护三种不同状态的autovacuum worker 进程列表：
autovacuum launcher 通过维护AutoVacuumShmemStruct的信息，达到调度autovacuum worker的作用，具体如下：
其中需要注意的是autovacuum launcher进程中只允许存在一个“启动中”状态的autovacuum worker进程，如果启动超时（状态一直为“启动中”时间超过autovacuum_naptime）将被取消启动。autovacuum launcher进程调用launch_worker函数来选择一个database，并为其启动相应的autovacuum worker。launch_worker主要做两件事情：
其中，符合下面条件的database将会启动一个worker，进行自动清理：
至此，我们可以概括出autovacuum launcher的大致操作：
经过上面的分析，我们可以得出以下结论：
除此之外，autovacuum launcher中还涉及到对各个autovacuum_worker的资源限制，这部分内容我们将会和autovacuum_worker进程一起在下次月报进行分析。