Postgres 源码学习 on roseduan

Postgres 源码学习番外篇—FDW 详解

Wed, 07 Aug 2024 16:51:56 +0800

FDW 概述

FDW，即 Foreign Data Wrapper，是 PostgreSQL 中的一项关键特性，通过接入 fdw，用户可以直接通过 SQL 语句访问各种外部数据源。

在 Postgres 中，FDW 有很多应用场景，比如：

1. 跨数据库查询： 在 PostgreSQL 数据库中，我们可以通过 FDW 直接请求和查询其他 PostgreSQL 实例，或是其他数据库如 MySQL、Oracle、DB2、SQL Server 等。

2. 数据整合： 当我们需要从不同数据源整合数据时，例如 RESTFUL API、文件系统、NoSQ L数据库以及流式系统等，FDW 能够帮助我们轻松实现这种跨来源的数据整合。

3. 数据迁移： 利用 FDW，我们可以高效地将数据从旧系统迁移到新的 PostgreSQL 数据库中。

4. 实时数据访问： 通过 FDW，我们能够访问外部实时更新的数据源。

常见的 FDW

PostgreSQL 支持非常多常见的 FDW，能够直接访问多种类型的外部数据源。例如，可以连接并查询远程的PostgreSQL，或者其他主流的 SQL 数据库如 Oracle、MySQL、DB2 以及 SQL Server。同时，PostgreSQL FDW 也具备灵活的接口，支持用户自定义外部访问方式。

此外，对于 NoSQL 数据库，以及实时数据库如 InfluxDB、消息队列如 Kafka、文档型数据库如 MongoDB 等等都能通过FDW实现数据访问。

常见的文本格式数据，如 CSV、JSON、Parquet 和 XML，也可以通过 FDW 轻松访问。大数据组件如 Elasticsearch、BigQuery，以及 Hadoop 生态系统中的 HDFS 和 Hive 等等都可以通过 FDW 实现无缝集成。

FDW 基本使用

FDW机制由四个核心组件构成：

1. Foreign Data Wrapper： 特定于各数据源的库，定义了如何建立与外部数据源的连接、执行查询及处理其他操作。

2. Foreign Server： 在本地PostgreSQL中定义一个外部服务器对象，对应实际的远程或非本地数据存储实例。

3. User Mapping： 为每个外部服务器设置用户映射，明确哪些本地用户有权访问，并提供相应的认证信息，如用户名和密码。

4. Foreign Table： 在本地数据库创建表结构，作为外部数据源中表的映射。对这些外部表发起的 SQL 查询将被转换并传递给相应的 FDW，在外部数据源上执行。

以 postgres_fdw 为例，下面是一个 fdw 的基础使用方法：

创建插件和 Foreign Server

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


创建插件

test=# create extension postgres_fdw;
CREATE EXTENSION

创建 Foreign Server

CREATE SERVER foreign_server
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (host '127.0.0.1', port '8001', dbname 'postgres');

创建 User Mapping 和外部表

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


创建 User Mapping

CREATE USER MAPPING FOR gpadmin SERVER foreign_server;

创建外部表

CREATE FOREIGN TABLE foreign_table (
 val int
)
SERVER foreign_server
OPTIONS (schema_name 'public', table_name 't2');

FDW 实现原理

在 PostgreSQL 的内核代码中，FDW 访问外部数据源的操作接口主要通过 FdwRoutine 这一结构体进行定义。任何接入外部数据源的插件都可以根据自身需要去实现这些接口。

接口函数大致分为多个类别，包括但不限于扫描、修改、分析外部表等等。例如，扫描外部表相关接口定义了如何扫描外部表，常见的操作包括开始扫描（ BeginForeignScan，主要进行准备工作）、执行扫描（IterateForeign Scan，从扫描中获取数据）、重新扫描（RescanForeignScan）以及结束扫描（EndForeignScan）等。

此外，还有用于修改数据的外部表接口，支持对数据进行 insert、delete、updat e等操作，以及 explain 和 analyze 等外部表接口。

如下图，这是一个file_fdw 插件实现 FdwRoutine 的示例，这里仅实现了一些基础的扫描操作接口（如BeginForeignScan、IterateForeignScan 等），以及用于表分析的 AnalyzeForeignTable 接口。

在 PostgreSQL 的执行过程中，这些接口函数会在 planner 或 executor 阶段被调用。尤其是当 executor 需要依赖外部服务插件访问数据时，它会通过插件提供的数据访问接口来获取数据。这使得 FDW 能够与 PostgreSQL 的Parser、Planner 以及 Rewriter 等组件能够无缝协作。

在需要访问外部数据源时，我们只需定义好相应的数据访问接口，就能直接获取数据，并按照PostgreSQL的标准流程进行后续处理。在执行过程中，执行器会分解为几个阶段进行：

1.首先进入 初始化阶段，核心任务是执行外部表扫描 ExecInitForeignScan。在这个阶段，主要是定义了一些外部扫描的接口，并调用 FdwRoutine 中用户自定义的接口，从而进行扫描前的准备。

2.紧接着是执行查询阶段 ，此时会调用 ExecuteForeignScan 方法。在这个方法中，我们主要需指定 ForeignNext 来获取下一条数据，并定义 ForeignRecheck 来检验数据元组的可见性。

3.最后进入结束查询阶段 ，即执行 EndForeignScan，该阶段主要负责资源清理工作。若系统检测到存在 FDWRoutine，就会利用用户自定义的 EndForeignScan 函数来释放资源。

以上就是FDW整体的实现流程。接下来，为了更深入地了解FDW的工作机制，我们将深入探讨FDW的源码。

FDW源码解析

FDW 支持的数据类型众多，但在此我们以常见的 Postgres_fdw 为例，剖析其源码实现，同样可帮助理解其他 FDW的源码逻辑。

首先，我们需要定义 FdwRoutine。前文提到了 FdwRoutine 主要负责定义外部数据扫描的接口，接口需要自定义实现外部扫描的方法。

访问外部数据源

定义好 FdwRoutine 之后，开始访问并扫描外部数据源。在 Postgres_fdw 中，流程也就是进入 BeginForeignScan 阶段。这一阶段主要是获取我们先前定义的外部表实例和用户信息，然后初始化并获取一个连接到远端数据源。

执行查询阶段

获取连接后，执行查询，即进行 IterateForeignScan 阶段。这个过程的逻辑是创建一个游标迭代器(cursor)，并从cursor中持续获取数据。

当全部数据迭代或扫描完成后，我们会释放连接并关闭 cursor 等资源，通过自定义的 EndForeignScan 阶段完成。

insert操作

对于 insert 操作，例如，在本地 PostgreSQL 数据库中修改Web数据源，增加一条数据，需要访问插入Web数据的接口。此操作先进入BeginForeignInsert 阶段，任务是构造SQL语句，通过预处理语句进行初始化，做好插入准备。

之后，进入 ExecuteForeignInsert 阶段，执行数据插入，主要通过预处理语句传递参数，然后发送SQL到远端执行。

最后，EndForeignInsert 阶段负责收尾和资源清理。

更新/删除操作

更新和删除操作的逻辑与插入类似。首先进入BeginDirectModify阶段，进行数据修改前的准备，如构建查询语句、获取连接等。随后执行修改操作，主要通过发送参数和查询到远端来执行。

Postgres 源码学习 5—FSM 空闲空间映射

Sun, 30 Jun 2024 16:51:56 +0800

前面提到了 Postgres 中的数据文件是被换分为了多个 page，每个 page 的大小默认是 8 KB。当我们向表中插入数据的时候，就需要从这些 page 中找到一个能够放得下这条数据的 page。

因为数据文件 page 的组织是无序的，元组的插入也是无序的，所以如果依次遍历查找满足条件的 page，可能会非常的低效，Postgres 中使用 FSM（Free Space Map）来进行查找，加速找到适合插入的 page 的过程。

FSM（Free Space Map），即空闲空间映射，其目的主要是快速定位一个有足够空间容纳插入元组的文件页。

我们需要保证这个映射空间尽可能小，并且辅以一个高效的数据组织方式，这样才能够快速的检索。

在 Postgres 中，一个 page 默认的大小是 8KB，默认情况下一个文件的大小是 1GB，所以能够最多容纳 131072 个 page。

如果我们采用一个 32 位 int 类型来表示一个 page 的空闲空间的话，当然是没问题的。但是如果 page 很多的话，每个 page 都需要 32 位来表示空闲空间的值。

FSM 也是需要物理存储的，为了在搜索的时候，能够更加快速，我们需要保证 FSM 占用的空间尽可能的少，所以在 Postgres 中采用了分类别的方式，将空闲空间的大小以 32 为步长，分为了 256 个区间：

这样一个 8KB 的 page 的空闲空间大小，使用一个 uint8 类型就可以表示了，由 4 个字节变成了 1 个字节。

如果 page 大小超过了 8KB，例如是 32KB，那么步长也随之增加：32KB / 256

表示空闲空间的数据信息，存储到了在磁盘文件上，以 _fsm 结尾。文件的数据存储方式和 heap page 类似，也是采用了 page 的方式，page 的内部结构和前面提到的 heap page 类似，也有对应的 page header。

存储的内容则比 heap page 简单很多，主要是两个属性：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


/*
 * Structure of a FSM page. See src/backend/storage/freespace/README for
 * details.
 */
typedef struct
{
 /*
 * fsm_search_avail() tries to spread the load of multiple backends by
 * returning different pages to different backends in a round-robin
 * fashion. fp_next_slot points to the next slot to be returned (assuming
 * there's enough space on it for the request). It's defined as an int,
 * because it's updated without an exclusive lock. uint16 would be more
 * appropriate, but int is more likely to be atomically
 * fetchable/storable.
 */
 int fp_next_slot;

 /*
 * fp_nodes contains the binary tree, stored in array. The first
 * NonLeafNodesPerPage elements are upper nodes, and the following
 * LeafNodesPerPage elements are leaf nodes. Unused nodes are zero.
 */
 uint8 fp_nodes[FLEXIBLE_ARRAY_MEMBER];
} FSMPageData;

fp_next_slot：从堆中搜索的起始位置
fp_nodes：空闲空间的数据（uint8 类型）

解决了空闲空间占用的问题，接下来就是空闲空间的数据如何组织的问题。其实这可以理解为是一个从无序的数组中，找到一个大于等于给定值的元素。

所以 Postgres 中使用了堆这个数据结构来存储空闲空间的大小，堆的叶子节点对应的是 page 的空闲大小，堆顶元素是最大的元素，当查找是，从堆顶元素进入，依次和其子节点进行对比，一直到达叶子节点。

查找的时候，还需要注意一个问题，那就是如果每次都从堆的顶层节点进入，那么有可能不同的进程找到的 page 是一样的。

为了提升并发性能，让不同的进程尽量找到不同的 page，这样能够避免锁竞争。

所以在查找的时候，记录了一个下次开始查找的下标值，如果该下标处的值不满足条件，则跳转到其右边的那个节点，然后从右边的节点的父节点开始查找，以此类推。

还需要注意一个问题，一个 FSMPage 有可能存不下所有的 heap page 的空闲空间大小。

所以实际上在存储的时候，会将空闲空间大小存储到不同的 FSM Page 中，那么不同 fsm page 中的空闲空间数据，又怎么维护成一个堆结构呢？

实际上是使用了多层结构，将不同 fsm page 的数据维护成了多个 level 层级的关系。

Postgres 源码学习 4—表文件 Page 结构概览

Sun, 02 Jun 2024 16:51:56 +0800

前面一节主要从宏观上了解 Postgres 表数据文件的组织方式，接下来我们深入到一个表文件的 page 内部，查看 page 的具体结构表示。

存储在磁盘上的一个表数据文件，内部切分为了多个 page，每个 page 默认的大小是 8KB，为了从磁盘上读取数据的效率，每次从文件中读取数据的时候，都是以 page 作为基本单位。

文件页中的每个 Page 被赋予了一个连续递增的唯一的编号，叫做 BlockNumber。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


/*
 * BlockNumber:
 *
 * each data file (heap or index) is divided into postgres disk blocks
 * (which may be thought of as the unit of i/o -- a postgres buffer
 * contains exactly one disk block). the blocks are numbered
 * sequentially, 0 to 0xFFFFFFFE.
 *
 * InvalidBlockNumber is the same thing as P_NEW in bufmgr.h.
 *
 * the access methods, the buffer manager and the storage manager are
 * more or less the only pieces of code that should be accessing disk
 * blocks directly.
 */
typedef uint32 BlockNumber;

我们可以通过 Postgres 的插件 pageinspect 来查看一个 page 的内部结构和状态。

1
2
3
4
5


postgres=#
postgres=#
postgres=# create extension pageinspect;
CREATE EXTENSION
postgres=# create table t as select generate_series(1,100)a;

我这里创建了一个对应的插件，并且创建了一个表。

然后可以通过 pageinspect 插件的一些函数查看表所属的 page 的数据信息：

1
2
3
4
5


postgres=# select * from page_header(get_raw_page('t', 0));
 lsn | checksum | flags | lower | upper | special | pagesize | version | prune_xid
------------+----------+-------+-------+-------+---------+----------+---------+-----------
 1/8CA839B0 | 0 | 0 | 824 | 1792 | 8192 | 8192 | 4 | 0
(1 row)

get_raw_page 是插件实现的方法，接收两个参数，分别是表名和 page 编号；page_header 方法则可以获取到 page 的 Header 头部信息。

可以看到获取到的字段和下图的 PageHeader 结构基本一致。

每个 page 主要由页头、内容、special 三部分组成，大致物理存储结构如下所示：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


 /*
 * +----------------+---------------------------------+
 * | PageHeaderData | linp1 linp2 linp3 ... |
 * +-----------+----+---------------------------------+
 * | ... linpN | |
 * +-----------+--------------------------------------+
 * | ^ pd_lower |
 * | |
 * | v pd_upper |
 * +-------------+------------------------------------+
 * | | tupleN ... |
 * +-------------+------------------+-----------------+
 * | ... tuple3 tuple2 tuple1 | "special space" |
 * +--------------------------------+-----------------+
 * ^ pd_special
 */

 typedef struct PageHeaderData
{
 /* XXX LSN is member of *any* block, not only page-organized ones */
 PageXLogRecPtr pd_lsn; /* LSN: next byte after last byte of xlog
 * record for last change to this page */
 uint16 pd_checksum; /* checksum */
 uint16 pd_flags; /* flag bits, see below */
 LocationIndex pd_lower; /* offset to start of free space */
 LocationIndex pd_upper; /* offset to end of free space */
 LocationIndex pd_special; /* offset to start of special space */
 uint16 pd_pagesize_version;
 TransactionId pd_prune_xid; /* oldest prunable XID, or zero if none */
 ItemIdData pd_linp[FLEXIBLE_ARRAY_MEMBER]; /* line pointer array */
} PageHeaderData;

页头部分其实是这个 page 的一些元数据信息，由 PageHeaderData 结构体表示，主要有如下内容：

pd_lsn：xlog（WAL）在当前 page 的最后一次修改的日志记录
pd_checksum：文件页对应的校验和，保护文件页内容
pd_flags：page 的一些状态信息，取值有如下几种
- #define PD_HAS_FREE_LINES 0x0001 /* are there any unused line pointers? / #define PD_PAGE_FULL 0x0002 / not enough free space for new tuple? / #define PD_ALL_VISIBLE 0x0004 / all tuples on page are visible to * everyone / #define PD_VALID_FLAG_BITS 0x0007 / OR of all valid pd_flags bits */
- PD_HAS_FREE_LINES：是否还有未使用的 linp 指针
- PD_PAGE_FULL：页面已满，剩余的空间无法容纳新的 Tuple
- PD_ALL_VISIBLE：page 所有的 tuple 都是可见的
- PD_VALID_FLAG_BITS：全部有效的 pd_flags 标记位
pd_lower：该 page 内空闲空间的起始位置
pd_upper：该 page 内空闲空间的结束位置
pd_special：存储一些特定的信息，比如 BTree 索引会用到
pd_pagesize_version：存储页面大小和版本信息
pd_prune_xid：page 中可删除的最旧的事务 ID
pd_linp：即前面注释中标注的 linp 1 linp 2 linp 3 … Linp n，是一个数组，用来标识 page 内一条数据的位置偏移，使用结构体 ItemIdData 表示。

ItemIdData 结构体主要有三个字段：

1
2
3
4
5
6


typedef struct ItemIdData
{
 unsigned lp_off:15, /* offset to tuple (from start of page) */
 lp_flags:2, /* state of line pointer, see below */
 lp_len:15; /* byte length of tuple */
} ItemIdData;

lp_off 占 15 位，表示数据在 page 的偏移
lp_flags 占 2 位，表示状态，取值有这几种：
- /* * lp_flags has these possible states. An UNUSED line pointer is available * for immediate re-use, the other states are not. / #define LP_UNUSED 0 / unused (should always have lp_len=0) / #define LP_NORMAL 1 / used (should always have lp_len>0) / #define LP_REDIRECT 2 / HOT redirect (should have lp_len=0) / #define LP_DEAD 3 / dead, may or may not have storage */
- LP_UNUSED：表示此空间空闲，未被使用
- LP_NORMAL：指向实际的偏移位置
- LP_REDIRECT：不指向实际数据，而是一个跳转，指向其他的 ItemIdData，用于 HOT（Heap Only Tuple）
- LP_DEAD：数据已经被删除
lp_length：数据的长度

从前面的 page 结构描述中可以得知，一条 Tuple 在插入到 page 当中的时候，是无序的，所以 Postgres 中最常用的表组织方式叫做 Heap，意为杂乱的，无顺序的。

这种数据组织的方式，其实可以非常高效的读取、插入、删除表中的一行数据，因此 Postgres 的 Heap 表结构其实适用于 OLTP 的场景。

当读取数据的时候，可以根据 BlockNumber 确定 page 编号，以及页内偏移 OffsetNumber 确定数据在 page 内的位置，使用结构体 ItemPointerData 表示一条数据的物理存储位置。

1
2
3
4
5


typedef struct ItemPointerData
{
 BlockIdData ip_blkid;
 OffsetNumber ip_posid;
}

参考资料

https://www.postgresql.org/docs/14/storage-page-layout.html

https://www.interdb.jp/pg/pgsql01/03.html

Postgres 源码学习 3—Postgres 存储管理器

Sun, 26 May 2024 16:51:56 +0800

前面一节说到，在 Postgres 的 VFD 机制之上，我们可以避开打开文件数量的系统限制，通过 VFD 可以进行打开、读写、关闭、删除文件等操作，简单来说就是 VFD 为我们提供了一个抽象，屏蔽了操作系统文件描述符的接口，后续我们对文件的 open、close，以及 CRUD 操作都在 VFD 的基础之上。

文件类型和文件块

要了解 Postgres 的存储管理，需要先对 Postgres 的表文件的组织方式、类型有一个简单的了解。

Postgres 中的表文件可能会非常大，在物理存储上会将表文件拆分为多个，每一个表文件通过 segno 来区分。

在 Postgres 的数据目录中，表文件的存储格式为 base/<database oid>/<table relfilenode>。

在 base 目录下，存储了不同 Database 的数据，例如在我的当前环境中，当前的数据库名为 rose，其 oid 为 24582。

所以在 Postgres 数据目录的 base 目录下，就会有对应的 Database 目录，目录名称就是 Oid：

我在当前数据库中有一个表，其名为 articles，我们可以通过 pg_class 表查询到对应的表 relfilenode。

可以看到表对应的 relfilenode 是 24588，所以可以到 24582 这个数据库目录中，查看所有表数据相关的文件：

img

可以看到表数据文件被分为了

24588 24588.1 24588.2 24588.3 24588.4 24588.5

每一个数据文件被称为一个数据段（Segment）文件，符号 . 后就是段号（segno），第 0 个分段文件没有段号。

除了数据文件，还有 24588_fsm 表示的是表的空闲空间映射文件，记录每个文件的空闲空间大小，24588_vm 即 VisibilityMap 文件，记录的是每个文件页的可见状态。

在源码中，定义了枚举 ForkNumber 来表示每种文件的类型。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


 /*
 * Stuff for fork names.
 *
 * The physical storage of a relation consists of one or more forks.
 * The main fork is always created, but in addition to that there can be
 * additional forks for storing various metadata. ForkNumber is used when
 * we need to refer to a specific fork in a relation.
 */
 typedef enum ForkNumber
 {
 InvalidForkNumber = -1,
 MAIN_FORKNUM = 0,
 FSM_FORKNUM,
 VISIBILITYMAP_FORKNUM,
 INIT_FORKNUM,

 /*
 * NOTE: if you add a new fork, change MAX_FORKNUM and possibly
 * FORKNAMECHARS below, and update the forkNames array in
 * src/common/relpath.c
 */
 } ForkNumber;

MAIN_FORKNUM：表数据文件 FSM_FORKNUM：空闲空间映射文件 VISIBILITYMAP_FORKNUM：文件页可见性 INIT_FORKNUM：主要用于 UNLOGGED 表

在分配和读取数据文件的时候，为了效率，一般会以块为单位，在 Postgres 中默认块大小是 8KB，可以在系统初始化时设置。

1
2
3
4
5
6
7
8


 /* Size of a disk block --this also limits the size of a tuple. You can set
 it bigger if you need bigger tuples (although TOAST should reduce the need
 to have large tuples, since fields can be spread across multiple tuples).
 BLCKSZ must be a power of 2. The maximum possible value of BLCKSZ is
 currently 2^15 (32768). This is determined by the 15-bit widths of the
 lp_off and lp_len fields in ItemIdData (see include/storage/itemid.h).
 Changing BLCKSZ requires an initdb. */
 #define BLCKSZ 8192

还有另一个参数是 RELSEG_SIZE，表示一个文件中的最大块数量，使用这个参数和 BLOCKZ，就能够计算出每个数据文件的最大值，目前默认是 1GB（131072 * 8192 / 1024 / 1024 / 1024 = 1GB）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


 /* RELSEG_SIZE is the maximum number of blocks allowed in one disk file. Thus,
 the maximum size of a single file is RELSEG_SIZE * BLCKSZ; relations bigger
 than that are divided into multiple files. RELSEG_SIZE * BLCKSZ must be
 less than your OS' limit on file size. This is often 2 GB or 4GB in a
 32-bit operating system, unless you have large file support enabled. By
 default, we make the limit 1 GB to avoid any possible integer-overflow
 problems within the OS. A limit smaller than necessary only means we divide
 a large relation into more chunks than necessary, so it seems best to err
 in the direction of a small limit. A power-of-2 value is recommended to
 save a few cycles in md.c, but is not absolutely required. Changing
 RELSEG_SIZE requires an initdb. */
 #define RELSEG_SIZE 131072

存储管理器

在 Postgres 中，在对表文件管理和操作时，提供了存储管理器（SMGR）的抽象，由于历史原因，早期的系统中，可能存在不同的存储系统，比如磁盘（magnetic disk）、索尼光盘（Sony WORM optical disk jukebox）、持久化主存（persistent main memory）等。

但是目前在操作系统层面，已经提供了文件系统的抽象，所以存储管理器其实已经没有存在的必要了，但是 Postgres 依然选择将其保留，主要是认为这层抽象并没有什么其他的影响。

所以目前只保留了基于磁盘的存储管理，实际上底层还是调用的操作系统的文件系统。

img

在源代码中也体现的很明显，两个文件，smgr.c 主要是存储管理器，而 md.c 就是磁盘的存储管理。

存储管理器类似一个顶层抽象，具体的存储管理操作都交给了磁盘存储管理器。

磁盘存储管理器

在 Postgres 中，一个表会有多个文件，对于表中打开的文件的管理，使用结构体 SMgrRelationData 来表示：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53


 /*
 * smgr.c maintains a table of SMgrRelation objects, which are essentially
 * cached file handles. An SMgrRelation is created (if not already present)
 * by smgropen(), and destroyed by smgrclose(). Note that neither of these
 * operations imply I/O, they just create or destroy a hashtable entry.
 * (But smgrclose() may release associated resources, such as OS-level file
 * descriptors.)
 *
 * An SMgrRelation may have an "owner", which is just a pointer to it from
 * somewhere else; smgr.c will clear this pointer if the SMgrRelation is
 * closed. We use this to avoid dangling pointers from relcache to smgr
 * without having to make the smgr explicitly aware of relcache. There
 * can't be more than one "owner" pointer per SMgrRelation, but that's
 * all we need.
 *
 * SMgrRelations that do not have an "owner" are considered to be transient,
 * and are deleted at end of transaction.
 */
 typedef struct SMgrRelationData
 {
 /* rlocator is the hashtable lookup key, so it must be first! */
 RelFileLocatorBackend smgr_rlocator; /* relation physical identifier */

 /* pointer to owning pointer, or NULL if none */
 struct SMgrRelationData **smgr_owner;

 /*
 * The following fields are reset to InvalidBlockNumber upon a cache flush
 * event, and hold the last known size for each fork. This information is
 * currently only reliable during recovery, since there is no cache
 * invalidation for fork extension.
 */
 BlockNumber smgr_targblock; /* current insertion target block */
 BlockNumber smgr_cached_nblocks[MAX_FORKNUM + 1]; /* last known size */

 /* additional public fields may someday exist here */

 /*
 * Fields below here are intended to be private to smgr.c and its
 * submodules. Do not touch them from elsewhere.
 */
 int smgr_which; /* storage manager selector */

 /*
 * for md.c; per-fork arrays of the number of open segments
 * (md_num_open_segs) and the segments themselves (md_seg_fds).
 */
 int md_num_open_segs[MAX_FORKNUM + 1];
 struct _MdfdVec *md_seg_fds[MAX_FORKNUM + 1];

 /* if unowned, list link in list of all unowned SMgrRelations */
 dlist_node node;
 } SMgrRelationData;

其中比较关键的字段有：

md_num_open_segs：记录每个 FORK 类型当前已经打开的文件数量 md_seg_fds：针对每个 FORK 类型打开文件的 VFD 信息

SMgrRelationData 会使用一个进程私有的哈希表来保存，每次需要打开一个表的文件时，可以首先从这个哈希表中查找，如果找到的话直接返回，这样同一个表只需要维护一个结构体即可，有利于保持对表文件操作的一致性。

哈希表的 key 是 SMgrRelationData 结构体的第一个属性 smgr_rlocator：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


 typedef struct RelFileLocator
 {
 Oid spcOid; /* tablespace */
 Oid dbOid; /* database */
 RelFileNumber relNumber; /* relation */
 } RelFileLocator;

 /*
 * Augmenting a relfilelocator with the backend ID provides all the information
 * we need to locate the physical storage. The backend ID is InvalidBackendId
 * for regular relations (those accessible to more than one backend), or the
 * owning backend's ID for backend-local relations. Backend-local relations
 * are always transient and removed in case of a database crash; they are
 * never WAL-logged or fsync'd.
 */
 typedef struct RelFileLocatorBackend
 {
 RelFileLocator locator;
 BackendId backend;
 } RelFileLocatorBackend;

smgr_rlocator 的类型是 RelFileLocatorBackend，locator 是一个三元组，分别是 <tablespaceid，database id，relation id>，backend 只对临时表有用，对普通表来说，其值一般是 -1。

在磁盘存储管理器中，其实主要就是对 SMgrRelationData 的管理，涉及到对其创建、打开、关闭、删除、扩展等操作。

创建表文件

在函数 mdcreate 中实现，一个数据表会有很多个数据文件，这里的创建表文件指的是传入给定的 tablespace id、database id、relation id，以及文件类型（ForkNumber），创建第一个物理文件，后续其他新的文件会在写入数据的时候动态扩展。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


 TablespaceCreateDbspace(reln->smgr_rlocator.locator.spcOid,
 reln->smgr_rlocator.locator.dbOid,
 isRedo);

 path = relpath(reln->smgr_rlocator, forknum);

 fd = PathNameOpenFile(path, _mdfd_open_flags() | O_CREAT | O_EXCL);

 if (fd < 0)
 {
 int save_errno = errno;

 if (isRedo)
 fd = PathNameOpenFile(path, _mdfd_open_flags());
 if (fd < 0)
 {
 /* be sure to report the error reported by create, not open */
 errno = save_errno;
 ereport(ERROR,
 (errcode_for_file_access(),
 errmsg("could not create file \"%s\": %m", path)));
 }
 }

 pfree(path);

 _fdvec_resize(reln, forknum, 1);
 mdfd = &reln->md_seg_fds[forknum][0];
 mdfd->mdfd_vfd = fd;
 mdfd->mdfd_segno = 0;

 if (!SmgrIsTemp(reln))
 register_dirty_segment(reln, forknum, mdfd);

所以 mdcrete 的逻辑其实比较简单，如上，主要就是创建第一个文件，通过 PathNameOpenFile 方法创建（或打开）文件并获得文件描述符，然后存储到 SMgrRelation 的 md_seg_fds 数组中。

打开表文件

在函数 smgropen 中，注意这个方法并不会实际去打开文件，只会初始化一些状态。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50


 /*
 * smgropen() -Return an SMgrRelation object, creating it if need be.
 *
 * This does not attempt to actually open the underlying file.
 */
 SMgrRelation
 smgropen(RelFileLocator rlocator, BackendId backend)
 {
 RelFileLocatorBackend brlocator;
 SMgrRelation reln;
 bool found;

 if (SMgrRelationHash == NULL)
 {
 /* First time through: initialize the hash table */
 HASHCTL ctl;

 ctl.keysize = sizeof(RelFileLocatorBackend);
 ctl.entrysize = sizeof(SMgrRelationData);
 SMgrRelationHash = hash_create("smgr relation table", 400,
 &ctl, HASH_ELEM | HASH_BLOBS);
 dlist_init(&unowned_relns);
 }

 /* Look up or create an entry */
 brlocator.locator = rlocator;
 brlocator.backend = backend;
 reln = (SMgrRelation) hash_search(SMgrRelationHash,
 &brlocator,
 HASH_ENTER, &found);

 /* Initialize it if not present before */
 if (!found)
 {
 /* hash_search already filled in the lookup key */
 reln->smgr_owner = NULL;
 reln->smgr_targblock = InvalidBlockNumber;
 for (int i = 0; i <= MAX_FORKNUM; ++i)
 reln->smgr_cached_nblocks[i] = InvalidBlockNumber;
 reln->smgr_which = 0; /* we only have md.c at present */

 /* implementation-specific initialization */
 smgrsw[reln->smgr_which].smgr_open(reln);

 /* it has no owner yet */
 dlist_push_tail(&unowned_relns, &reln->node);
 }

 return reln;
 }

如果哈希表 SMgrRelationHash 为空，则初始化
从哈希表中查找表对应的 SMgrRelation 结构
1. 如果没找到的话，则初始化一个对应的表文件管理结构体（reln）
2. 然后调用磁盘存储管理器（md.c）中的 smgr_open 进行初始化

md 中的 smgr_open 其实也非常简单，只是对 md_num_open_segs 属性进行了初始化。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


 /*
 * mdopen() -Initialize newly-opened relation.
 */
 void
 mdopen(SMgrRelation reln)
 {
 /* mark it not open */
 for (int forknum = 0; forknum <= MAX_FORKNUM; forknum++)
 reln->md_num_open_segs[forknum] = 0;
 }

关闭表文件

通过函数 mdclose 实现，主要是对每个 Fork 类型的文件，查询 md_seg_fds 中保存的文件描述符信息，然后通过 FileClose 方法关闭文件。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


 /*
 * mdclose() -Close the specified relation, if it isn't closed already.
 */
 void
 mdclose(SMgrRelation reln, ForkNumber forknum)
 {
 int nopensegs = reln->md_num_open_segs[forknum];

 /* No work if already closed */
 if (nopensegs == 0)
 return;

 /* close segments starting from the end */
 while (nopensegs > 0)
 {
 MdfdVec *v = &reln->md_seg_fds[forknum][nopensegs 1];

 FileClose(v->mdfd_vfd);
 _fdvec_resize(reln, forknum, nopensegs 1);
 nopensegs--;
 }
 }

删除表文件

在 smgr 中，删除表文件的方法是 smgrdounlinkall，主要会将表文件先关闭（mdclose）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


 /*
 * create an array which contains all relations to be dropped, and close
 * each relation's forks at the smgr level while at it
 */
 rlocators = palloc(sizeof(RelFileLocatorBackend) * nrels);
 for (i = 0; i < nrels; i++)
 {
 RelFileLocatorBackend rlocator = rels[i]->smgr_rlocator;
 int which = rels[i]->smgr_which;

 rlocators[i] = rlocator;

 /* Close the forks at smgr level */
 for (forknum = 0; forknum <= MAX_FORKNUM; forknum++)
 smgrsw[which].smgr_close(rels[i], forknum);
 }

然后遍历每个 Fork 类型，删除其中的每个文件。

1
2
3
4
5
6
7


 for (i = 0; i < nrels; i++)
 {
 int which = rels[i]->smgr_which;

 for (forknum = 0; forknum <= MAX_FORKNUM; forknum++)
 smgrsw[which].smgr_unlink(rlocators[i], forknum, isRedo);
 }

实际的删除文件流程都在 md.c 中的 mdunlinkfork 方法，删除表文件的时候，会立即删除除了 MAIN_FORK 第 0 个分段文件（Segment）之外的其他文件。

对于 MAIN_FORK 的 0 个文件，会将其保留防止其他表重用文件名，并且将文件内容截取（truncate）到 0，然后发送请求给 checkpointer 进程，让其在下一次 checkpoint 之后再实际删除该文件，关键代码如下：

1
2
3
4
5
6
7


 /* Prevent other backends' fds from holding on to the disk space */
 ret = do_truncate(path);

 /* Register request to unlink first segment later */
 save_errno = errno;
 register_unlink_segment(rlocator, forknum, 0 /* first seg */ );
 errno = save_errno;

扩展表文件

在对数据表文件进行写入时，如果表文件空间不够了，那么需要扩展表文件的大小，通过函数 mdextend 实现。

在扩展时，会以 BLOCK 为单位，每次扩展一个或多个 BLOCK。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


 v = _mdfd_getseg(reln, forknum, blocknum, skipFsync, EXTENSION_CREATE);

 seekpos = (off_t) BLCKSZ * (blocknum % ((BlockNumber) RELSEG_SIZE));

 Assert(seekpos < (off_t) BLCKSZ * RELSEG_SIZE);

 if ((nbytes = FileWrite(v->mdfd_vfd, buffer, BLCKSZ, seekpos, WAIT_EVENT_DATA_FILE_EXTEND)) != BLCKSZ)
 {
 if (nbytes < 0)
 ereport(ERROR,
 (errcode_for_file_access(),
 errmsg("could not extend file \"%s\": %m",
 FilePathName(v->mdfd_vfd)),
 errhint("Check free disk space.")));
 /* short write: complain appropriately */
 ereport(ERROR,
 (errcode(ERRCODE_DISK_FULL),
 errmsg("could not extend file \"%s\": wrote only %d of %d bytes at block %u",
 FilePathName(v->mdfd_vfd),
 nbytes, BLCKSZ, blocknum),
 errhint("Check free disk space.")));
 }

 if (!skipFsync && !SmgrIsTemp(reln))
 register_dirty_segment(reln, forknum, v);

大致逻辑是会获得对应的文件描述符，然后通过 FileWrite 方法写入 block 数量大小的数据。

写完之后，会标识该文件是 dirty 的，然后发送请求到 checkpointer 进程（register_dirty_segment），让其在下一次发生 checkpoint 的时候将文件内容落盘。

读写表文件

读写表文件中的 block 主要是通过 mdread/mdwrite 方法。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


 /*
 * mdread() -Read the specified block from a relation.
 */
 void
 mdread(SMgrRelation reln, ForkNumber forknum, BlockNumber blocknum,
 void *buffer)
 {
 off_t seekpos;
 int nbytes;
 MdfdVec *v;

 /* If this build supports direct I/O, the buffer must be I/O aligned. */
 if (PG_O_DIRECT != 0 && PG_IO_ALIGN_SIZE <= BLCKSZ)
 Assert((uintptr_t) buffer == TYPEALIGN(PG_IO_ALIGN_SIZE, buffer));

 TRACE_POSTGRESQL_SMGR_MD_READ_START(forknum, blocknum,
 reln->smgr_rlocator.locator.spcOid,
 reln->smgr_rlocator.locator.dbOid,
 reln->smgr_rlocator.locator.relNumber,
 reln->smgr_rlocator.backend);

 v = _mdfd_getseg(reln, forknum, blocknum, false,
 EXTENSION_FAIL | EXTENSION_CREATE_RECOVERY);

 seekpos = (off_t) BLCKSZ * (blocknum % ((BlockNumber) RELSEG_SIZE));

 Assert(seekpos < (off_t) BLCKSZ * RELSEG_SIZE);

 nbytes = FileRead(v->mdfd_vfd, buffer, BLCKSZ, seekpos, WAIT_EVENT_DATA_FILE_READ);
 }

读取的时候，会传入表文件的 SMgrRelation 结构体，以及文件类型 forknum 和块号 blocknum，然后通过 FileRead 方法将数据读取到指定的 buffer 中。

mdwrite 的方法和读取基本类似，主要是将指定的 buffer 内容通过 FileWrite 方法写入到对应的文件中。

1
2
3
4
5
6
7
8


 v = _mdfd_getseg(reln, forknum, blocknum, skipFsync,
 EXTENSION_FAIL | EXTENSION_CREATE_RECOVERY);

 seekpos = (off_t) BLCKSZ * (blocknum % ((BlockNumber) RELSEG_SIZE));

 Assert(seekpos < (off_t) BLCKSZ * RELSEG_SIZE);

 nbytes = FileWrite(v->mdfd_vfd, buffer, BLCKSZ, seekpos, WAIT_EVENT_DATA_FILE_WRITE);

注意这里写入之后，并不会等待操作系统刷盘之后再返回，而是直接返回，将刷盘的请求交给了 checkpointer 进程，由此来提高数据写入的效率，而数据的崩溃恢复、一致性，是通过 WAL 来保证的。

Postgres 源码学习 2—Postgres 的 VFD 机制

Thu, 18 Apr 2024 10:51:56 +0800

操作系统中的文件

数据库的本质其实就是用来存储数据的，所以免不了和文件系统、存储进行交互，万丈高楼平地起，存储一般是一个数据库的最底层，Postgres 在存储的文件管理方面也有很多的设计与抽象。

在操作系统层面，提供了一些文件操作相关的系统调用（fopen、fclose、fsync 等），我们作为上层使用者，可以直接通过 C 语言库进行调用即可（Postgres 使用 C 语言编写）。

具体和文件系统的交互我们并不关心，操作系统打开文件之后，会在进程的控制块中维护一些打开文件的相关信息，并返回一个文件描述符，后续我们与文件的交互都通过文件描述符进行。

操作系统能够打开多少文件，是有限制的，一个是系统级限制，指的是在内核中可以打开多少文件，可以通过命令 sysctl fs.file-max 查看。另一个是用户级限制，为了不让某个进程打开太多的文件，进而消耗所有的资源，对单个进程能打开文件也有限制，可以通过 ulimit -n 命令查看。

Postgres 的 VFD 作用

Postgres 数据库在运行的过程当中，可能会打开非常多的文件，比如数据表对应的文件，元数据表文件，以及一些在 SQL 运行时打开的临时文件，例如排序、哈希表所需的文件。

所以有非常大的概率超过单个进程打开文件数量的限制，为了解决这个问题，Postgres 设计了 VFD（虚拟文件描述符）机制，主要是将实际的操作系统文件描述符维护到一个 LRU 缓存中，通过切换打开的方式，规避了进程打开文件数量的限制。

如果一个进程打开的文件数目达到了限制，则暂时关闭最久未使用的文件，保存其状态，待下次重新打开。

VFD 的基本工作方式

Postgres 主要通过一个进程私有的数组来维护 VFD，名为 VfdCache。

1
2
3
4
5
6


/*
 * Virtual File Descriptor array pointer and size. This grows as
 * needed. 'File' values are indexes into this array.
 * Note that VfdCache[0] is not a usable VFD, just a list header.
 */
static Vfd *VfdCache;

VfdCache 数组的第一个元素不存储任何数据，仅作为头部使用，下面是 vfdCache 的初始化逻辑，会在 backend 进程启动的时候调用，大致的逻辑就是为 VfdCache 数组分配内存。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


/*
 * InitFileAccess --- initialize this module during backend startup
 *
 * This is called during either normal or standalone backend start.
 * It is *not* called in the postmaster.
 *
 * Note that this does not initialize temporary file access, that is
 * separately initialized via InitTemporaryFileAccess().
 */
void
InitFileAccess(void)
{
 Assert(SizeVfdCache == 0); /* call me only once */

 /* initialize cache header entry */
 VfdCache = (Vfd *) malloc(sizeof(Vfd));
 if (VfdCache == NULL)
 ereport(FATAL,
 (errcode(ERRCODE_OUT_OF_MEMORY),
 errmsg("out of memory")));

 MemSet((char *) &(VfdCache[0]), 0, sizeof(Vfd));
 VfdCache->fd = VFD_CLOSED;

 SizeVfdCache = 1;
}

如果需要打开一个文件，那么会首先在 VfdCache 数组中查找空闲的虚拟文件描述符，主要是通过 nextFree 指针进行查找，如果当前没有空闲的 vfd 了，那么会启动扩容机制，初始情况下，VfdCache size 是 32，每次扩容为原来的 2 倍。

Vfd 扩容和分配的逻辑都在方法 AllocateVfd 中。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57


static File
AllocateVfd(void)
{
 Index i;
 File file;

 DO_DB(elog(LOG, "AllocateVfd. Size %zu", SizeVfdCache));

 Assert(SizeVfdCache > 0); /* InitFileAccess not called? */

 if (VfdCache[0].nextFree == 0)
 {
 /*
 * The free list is empty so it is time to increase the size of the
 * array. We choose to double it each time this happens. However,
 * there's not much point in starting *real* small.
 */
 Size newCacheSize = SizeVfdCache * 2;
 Vfd *newVfdCache;

 if (newCacheSize < 32)
 newCacheSize = 32;

 /*
 * Be careful not to clobber VfdCache ptr if realloc fails.
 */
 newVfdCache = (Vfd *) realloc(VfdCache, sizeof(Vfd) * newCacheSize);
 if (newVfdCache == NULL)
 ereport(ERROR,
 (errcode(ERRCODE_OUT_OF_MEMORY),
 errmsg("out of memory")));
 VfdCache = newVfdCache;

 /*
 * Initialize the new entries and link them into the free list.
 */
 for (i = SizeVfdCache; i < newCacheSize; i++)
 {
 MemSet((char *) &(VfdCache[i]), 0, sizeof(Vfd));
 VfdCache[i].nextFree = i + 1;
 VfdCache[i].fd = VFD_CLOSED;
 }
 VfdCache[newCacheSize - 1].nextFree = 0;
 VfdCache[0].nextFree = SizeVfdCache;

 /*
 * Record the new size
 */
 SizeVfdCache = newCacheSize;
 }

 file = VfdCache[0].nextFree;

 VfdCache[0].nextFree = VfdCache[file].nextFree;

 return file;
}

拿到虚拟文件描述符之后，会调用 C 库函数 open 实际去打开文件，并且将一些文件状态维护到 Vfd 结构体中，这个结构体主要存储的是虚拟文件描述符的一些信息，也就是存储到 VfdCache 数组中的结构。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


typedef struct vfd
{
 int fd; /* current FD, or VFD_CLOSED if none */
 unsigned short fdstate; /* bitflags for VFD's state */
 ResourceOwner resowner; /* owner, for automatic cleanup */
 File nextFree; /* link to next free VFD, if in freelist */
 File lruMoreRecently; /* doubly linked recency-of-use list */
 File lruLessRecently;
 off_t fileSize; /* current size of file (0 if not temporary) */
 char *fileName; /* name of file, or NULL for unused VFD */
 /* NB: fileName is malloc'd, and must be free'd when closing the VFD */
 int fileFlags; /* open(2) flags for (re)opening the file */
 mode_t fileMode; /* mode to pass to open(2) */
} Vfd;

Vfd 结构体中，主要通过 nextFree、lruMoreRecently、lruLessRecently 指针将 vfd 维护到不同的队列里面。

每次新打开一个文件，都会将该 vfd 通过 lruMoreRecently 和 lruLessRecently 指针，维护这个双向链表，每次关闭一个 VfdCache 中的文件，都会将其从链表中删除。

每次查找空闲的 VfdCache 的时候，都会通过 nextFree 链表进行查找。

以访问文件为例，首先会判断文件是否打开，如果没有打开的话，则打开文件并且将其放到最近使用的链表中。

主要的逻辑在函数 LruInsert 中，在实际打开文件之前，会尝试关闭最久未使用的文件。

然后会通过系统调用打开文件，并且获取到实际的文件描述符（fd），将其保存到 vfdP 结构中。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


static int
LruInsert(File file)
{
 Vfd *vfdP;

 Assert(file != 0);

 DO_DB(elog(LOG, "LruInsert %d (%s)",
 file, VfdCache[file].fileName));

 vfdP = &VfdCache[file];

 if (FileIsNotOpen(file))
 {
 /* Close excess kernel FDs. */
 ReleaseLruFiles();

 /*
 * The open could still fail for lack of file descriptors, eg due to
 * overall system file table being full. So, be prepared to release
 * another FD if necessary...
 */
 vfdP->fd = BasicOpenFilePerm(vfdP->fileName, vfdP->fileFlags,
 vfdP->fileMode);
 if (vfdP->fd < 0)
 {
 DO_DB(elog(LOG, "re-open failed: %m"));
 return -1;
 }
 else
 {
 ++nfile;
 }
 }

 /*
 * put it at the head of the Lru ring
 */

 Insert(file);

 return 0;
}

如果文件已经是打开状态，那么会先从链表中删除，然后将其插入到最近使用的链表中。将 Vfd 加入到链表中，代码如下，可以看到主要是通过维护 lruMoreRecently 和 lruLessRecently 这两个指针，将当前 vfd 加入到链表的头部。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


static void
Insert(File file)
{
 Vfd *vfdP;

 Assert(file != 0);

 DO_DB(elog(LOG, "Insert %d (%s)",
 file, VfdCache[file].fileName));
 DO_DB(_dump_lru());

 vfdP = &VfdCache[file];

 vfdP->lruMoreRecently = 0;
 vfdP->lruLessRecently = VfdCache[0].lruLessRecently;
 VfdCache[0].lruLessRecently = file;
 VfdCache[vfdP->lruLessRecently].lruMoreRecently = file;

 DO_DB(_dump_lru());
}

而 Delete 方法则描述的是将一个 vfd 从链表中删除。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


static void
Delete(File file)
{
 Vfd *vfdP;

 Assert(file != 0);

 DO_DB(elog(LOG, "Delete %d (%s)",
 file, VfdCache[file].fileName));
 DO_DB(_dump_lru());

 vfdP = &VfdCache[file];

 VfdCache[vfdP->lruLessRecently].lruMoreRecently = vfdP->lruMoreRecently;
 VfdCache[vfdP->lruMoreRecently].lruLessRecently = vfdP->lruLessRecently;

 DO_DB(_dump_lru());
}

小结

Postgres 中的 VFD，即虚拟文件描述符，主要是为了能够规避操作系统中最大打开文件数的限制，采用切换打开的方式，维护了一个链表，将最近打开的文件维护到链表头部，最久未使用的文件放置到链表尾部。

访问文件的时候，会从 VfdCache 数组中查找空闲的虚拟文件描述符，如果找到的话，则直接使用，否则分配新的 VfdCache 空间。

在打开文件的时候，会尝试关闭最久未使用的文件，将位置留给最新打开的文件。

通过这种方式，Postgres 可以打开远超过系统和进程限制的文件数量，是一个非常精妙的设计。

Postgres 源码学习 1—Postgres 源码编译和 debug

Tue, 16 Apr 2024 10:51:56 +0800

docker 环境

这里我使用了一个纯净的 Ubuntu 环境来进行演示，为了方便，使用了 docker。

如果你有其他的物理机，或者云服务器，都是可以的，Postgres 支持多种平台编译，如果你是非 Ubuntu 环境，可以自行查阅相关的资料进行编译安装，步骤都是大同小异的。

我使用了 Ubuntu 20.04 版本的镜像作为演示：

使用镜像启动容器：

1

docker run -itd --name <container-name> --privileged <image id>

进入环境：

1

docker exec -it <container-name | container id> /bin/bash

创建用户

最好不要在 root 用户下编译和安装 Postgres，这里我们可以新建一个用户

1

useradd <username> -m -s /bin/bash

切换到新的用户环境中。

1

su <username>

安装依赖

安装 Postgres 编译所需的依赖（这里是摘取了 Greenplum 的安装依赖，可能包含了一些没必要安装的，但肯定是涵盖了 Postgres 需要的依赖，所以全部安装上也没啥问题）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


sudo apt-get update
sudo apt-get install -y \
 bison \
 ccache \
 cmake \
 curl \
 flex \
 git-core \
 gcc \
 g++ \
 inetutils-ping \
 krb5-kdc \
 krb5-admin-server \
 libapr1-dev \
 libbz2-dev \
 libcurl4-gnutls-dev \
 libevent-dev \
 libkrb5-dev \
 libpam-dev \
 libperl-dev \
 libreadline-dev \
 libssl-dev \
 libxerces-c-dev \
 libxml2-dev \
 libyaml-dev \
 libzstd-dev \
 locales \
 net-tools \
 ninja-build \
 openssh-client \
 openssh-server \
 openssl \
 pkg-config \
 python3-dev \
 python3-pip \
 python3-psycopg2 \
 python3-psutil \
 python3-yaml \
 zlib1g-dev

执行编译

拉取 Postgres 的源代码，并进入到 postgres 代码目录中。

如果是拉取最新版本的代码，可以从 Github 上获取：

1

git clone https://github.com/postgres/postgres.git

如果想要获取对应版本的源代码，则可以从 Postgres 官网中下载：

地址：https://www.postgresql.org/ftp/source/

Postgres 有非常多的编译选项，详情可以参考官方文档：https://www.postgresql.org/docs/current/install-make.html#CONFIGURE-OPTIONS

我们这里只使用最简单的编译方式即可。

1

CFLAGS=-O0 ./configure --prefix=/home/roseduan/pg-install --enable-debug

我们关闭了编译器的优化，方便后续的调试，并且打开了 debug 模式。

--prefix 指定编译后的二进制目录的位置，这里不指定也是可以的，默认是在 /usr/local 下面。

Configure 之后，如果没有错误产生的话，则执行编译并安装：

1

make -s -j`nproc` install

编译安装之后，得到了二进制目录，可以将 bin 目录加入到 PATH 环境变量中，如果嫌麻烦，可以加入到 $HOME 目录中的 .bashrc 或者 .zshrc（取决于你的 sh 是什么），这样下次登录就不用重复设置了。

1

export PATH=/<posgres-install-dir>/bin:$PATH

初始化 DB

上述步骤完成后，可以使用 init 命令来初始化 postgres 的数据目录。

1

pg_ctl -D <pg 数据目录路径> init

初始化完成后，直接启动 postgres 的服务即可。

1

pg_ctl -D pg-data start

启动之后，可以查看 postgres 的进程状态。

也可以通过 psql 命令连接到数据库中：

1

psql postgres

如何 Debug

有了源码环境之后，其实 Debug 调试就比较简单。

使用 psql 登录之后，后台会启动一个工作进程来服务于这个客户端的请求，可以通过 pg_backend_pid() 方法查看进程 id。

这里我的进程 id 是 1857，直接通过 gdb -p 1857 即可对该进程进行 Debug。

我们可以在 gdb 中设置一个断点，比如 Postgres 的简单查询命令都会走 exec_simple_query 方法，可以直接对这个方法打断点，然后在客户端任意执行一个 select 语句，就会到 gdb 的断点中了：

参考资料

https://www.postgresql.org/docs/current/installation.html