企业官网建设流程全解析

1. 为什么现在还要亲手编译 PostgreSQL 11.7？这真不是“复古行为艺术”

你点开这个标题，大概率心里已经闪过几个念头：Docker 一键拉镜像不香吗？云厂商 RDS 点几下就开库，连密码都自动生成；甚至本地 Homebrew 或 apt install postgresql 几秒钟完事——谁还耐烦去翻 configure 参数、等 make 编译二十分钟、再手动 initdb？

但现实是，我去年在某高校实验室带一个数据库原理课设项目时，连续三届学生都在同一个环节卡住：用现成包安装的 PostgreSQL，默认关闭了 pg_stat_statements 扩展、禁用了 WAL 归档配置项、shared_buffers 被硬编码为 128MB 且无法突破系统限制、甚至 pg_config 输出的 include 目录路径和实际头文件位置对不上。他们想做查询计划深度分析、想模拟主从同步故障、想调试 buffer manager 的 LRU 实现逻辑——这些动作，全被二进制包的“安全封装”挡在门外。

PostgreSQL 11.7 是一个关键分水岭版本：它首次完整支持并默认启用 JIT 编译（需 LLVM），引入了分区表原生剪枝优化器，同时保留了对传统 C 函数扩展的完全兼容性。更重要的是，它的源码结构清晰、注释密度高、构建依赖极简——不像 15+ 版本那样强耦合 Python 构建工具链。这意味着：你花 40 分钟亲手编译一次，换来的不是“能跑”，而是对整个 PostgreSQL 运行时骨架的触觉式理解：从 postmaster 进程如何 fork 子进程，到 shared memory segment 如何按 GUC 参数初始化，再到 WAL writer 线程如何与 checkpointer 协同刷盘——这些，在src/backend/目录下全是可读、可断点、可修改的 C 代码。

这不是怀旧，是建立技术主权。当你在生产环境排查一个诡异的 vacuum freeze 阻塞问题时，官方文档只告诉你vacuum_freeze_table_age的含义，而源码里src/backend/access/heap/heapam.c第 3287 行的注释会明确写出：“此阈值触发时，将强制扫描全表以推进 relfrozenxid，但若 concurrent update 活跃，可能引发 XID wraparound 风险”。这种颗粒度的信息，永远不可能出现在任何二进制包的--help输出里。

所以，这篇内容面向三类人：

• 正在准备数据库内核面试的后端开发者（你得能讲清楚StartupProcess和BackgroundWriter的启动时序）；
• 需要定制化审计日志字段或修改 WAL 记录格式的安全合规工程师；
• 或者只是单纯想搞懂“为什么 pg_dump 有时候快有时候慢”的 DBA——因为答案藏在src/bin/pg_dump/pg_backup_archiver.c里，而只有源码安装，你才能git blame到每一行的来龙去脉。

我们不走 Dockerfile 抄作业路线，也不用 Ansible 做黑盒部署。就从官网 tarball 解压开始，一行 configure、一次 make、一次 initdb，全程透明，每一步都告诉你“为什么这么选”“不这么选会怎样”。

2. 源码安装全流程拆解：从下载到可调试服务的七步闭环

2.1 下载与校验：别跳过 checksum，这是你和上游代码的第一次握手

PostgreSQL 官方发布页（https://www.postgresql.org/download/）提供多个镜像站，但必须使用 .tar.gz 源码包，而非 .zip——后者在 Windows 下解压可能损坏符号链接，而 PostgreSQL 源码中大量使用src/include到src/backend的软链做头文件统一管理。我试过用 7-Zip 解压 .zip 包，结果make时直接报pg_config.h: No such file or directory，折腾两小时才发现是软链丢失。

正确操作是：

# 进入临时工作目录（避免污染家目录） cd /tmp && mkdir pg117-src && cd pg117-src # 下载源码包（注意：必须是 11.7，不是 11.7.1 或 11.7.2 —— 后者是补丁版本，源码结构有微调） curl -O https://ftp.postgresql.org/pub/source/v11.7/postgresql-11.7.tar.gz # 校验 SHA256（关键！官网发布页右侧有 checksum 列表） echo "d9a7b3c2e8f1a0b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d postgresql-11.7.tar.gz" | sha256sum -c

提示：如果校验失败，立刻停止！常见原因是 CDN 缓存了旧版本。此时应改用主站直连：curl -O https://ftp.postgresql.org/pub/source/v11.7/postgresql-11.7.tar.gz，并重新校验。我曾因跳过这步，在一台 CentOS 7 机器上编译出的 postgres 二进制文件，pg_config --version显示 11.7，但SELECT version();却返回 11.6，根源就是下载了被篡改的包。

解压后执行ls -la，确认src/include是指向../backend/catalog的软链，且configure文件存在且可执行（权限为-rwxr-xr-x）。这是后续所有步骤成立的前提。

2.2 依赖检查：Linux 发行版差异比你想象中更致命

PostgreSQL 11.7 的编译依赖非常克制：GCC 4.8+、make、perl（用于生成部分头文件）、Python 2.7（仅用于构建文档，可跳过）、以及基础开发库（readline、zlib、openssl）。但不同发行版的“基础开发库”命名天差地别：

实测教训：在一台最小化安装的 CentOS 7 上，我漏装perl，configure脚本运行到一半突然退出，错误信息是Can't locate File/Spec.pm in @INC——这根本不是 PostgreSQL 的错，而是 Perl 的核心模块缺失。解决方法不是重装 Perl，而是yum install perl-core。

更隐蔽的问题是readline版本。PostgreSQL 11.7 要求 readline ≥ 6.3，但某些老旧系统（如 CentOS 6）默认只有 6.0。此时configure不报错，但make时会在src/bin/psql/command.c报rl_filename_completion_function未定义。解决方案是：不要升级系统 readline（可能破坏 shell），而是用--with-readline-prefix指向新版本：

# 下载 readline 8.0 源码编译安装到 /opt/readline ./configure --prefix=/opt/readline && make && sudo make install # 在 PostgreSQL configure 中指定 ./configure --with-readline-prefix=/opt/readline

注意：--with-openssl参数不是可选的，而是必须显式声明。即使系统已装 openssl-devel，configure也会默认禁用 SSL 支持，导致后续psql无法连接sslmode=require的远程库。务必加上--with-openssl，否则你会在src/interfaces/libpq/Makefile里看到SSL_ENABLED = false。

2.3 configure 参数精解：每个开关背后都是一个运行时决策

./configure是整个流程的“大脑”，它生成 Makefile 并决定 PostgreSQL 的能力边界。以下是针对 11.7 的生产级最小必要参数集，逐条解释其不可替代性：

./configure \ --prefix=/usr/local/pgsql-11.7 \ # 【强制】安装根目录，必须绝对路径，不能是 ~/pgsql --with-openssl \ # 【强制】启用 SSL，否则 libpq 不支持加密连接 --with-readline \ # 【强制】启用命令行编辑（上下箭头、Ctrl+R 搜索） --with-zlib \ # 【强制】启用压缩，否则 pg_dump 无法用 -Z 参数 --with-python \ # 【可选但推荐】启用 PL/Python，数据分析场景刚需 --enable-debug \ # 【开发必选】加入调试符号，gdb 可见变量名 --enable-cassert \ # 【测试必选】开启断言，崩溃时输出精确位置 --without-docs \ # 【强烈推荐】跳过文档编译，省 15 分钟，且 docs 不影响运行 CFLAGS="-O2 -g -fno-omit-frame-pointer" # 【关键】优化级别与调试平衡：-O2 保证性能，-g 保留符号，-fno-omit-frame-pointer 确保 gdb 回溯准确

重点解析三个易错参数：

• --prefix：绝不能写成--prefix=$HOME/pgsql。PostgreSQL 的pg_config工具会把此路径硬编码进所有扩展的 Makefile，一旦你之后用CREATE EXTENSION加载插件，它会固执地去$HOME/pgsql找头文件，而你的实际安装路径可能是/opt/pgsql，导致编译失败。必须用绝对路径，且建议避开/usr（系统包管理器冲突）和/opt（某些企业策略禁止）。

• CFLAGS="-O2 -g -fno-omit-frame-pointer"：这是性能与调试的黄金配比。-O3会导致内联函数过多，gdb 断点失效；-O0则让查询执行慢 3 倍以上。-fno-omit-frame-pointer是关键——没有它，gdb bt只能看到#0 0x00007f... in ?? ()，你永远不知道 crash 发生在ExecHashJoin还是ExecSeqScan。

• --enable-debug与--enable-cassert：二者必须共存。单独--enable-debug只加符号，不加断言；单独--enable-cassert会编译出无符号的二进制，gdb 无法查看局部变量。我曾因此在一个死锁复现中浪费 8 小时，直到发现gdb里print queryDesc显示<optimized out>。

执行./configure后，务必检查末尾输出：

... checking for library containing socket... none required checking for library containing gethostbyname... none required checking for dlopen in -ldl... yes checking for OpenSSL header files... found checking for OpenSSL library... found ...

只要出现not found，立即停下。比如checking for OpenSSL library... not found，说明pkg-config openssl失败，需检查PKG_CONFIG_PATH是否包含/usr/lib64/pkgconfig（CentOS）或/usr/lib/x86_64-linux-gnu/pkgconfig（Ubuntu）。

2.4 make 编译：时间管理与资源分配的实战课

make是最耗时也最不可控的环节。PostgreSQL 11.7 全量编译约需 1200 个目标文件，单线程编译在 4 核机器上需 18~25 分钟。但盲目加-j参数会引发内存溢出：

• -j4：4 核机器安全上限，内存占用峰值约 1.2GB；
• -j8：需 16GB 内存，否则cc1进程 OOM 被 kill；
• -j$(nproc)：在 CI 环境中极其危险，某次 Jenkins 构建因-j32导致宿主机 swap 耗尽，整个集群假死。

更稳妥的做法是：

# 查看可用内存（单位 MB） free -m | awk 'NR==2{print $7}' # 若空闲内存 < 2000MB，强制单线程 make -j1 # 若空闲内存 >= 2000MB，用 nproc-1 避免抢占系统进程 make -j$(($(nproc)-1))

编译过程中，make会依次构建：

1. src/common/：通用工具函数（字符串处理、内存分配）；
2. src/include/：头文件生成（由src/backend/catalog的.dat文件生成）；
3. src/backend/：核心服务端（占总编译时间 65%）；
4. src/bin/：客户端工具（psql, pg_dump 等）；
5. src/interfaces/：驱动（libpq, ecpg）。

当看到make[1]: Leaving directory '/tmp/pg117-src/src/backend'时，说明最耗时的部分已完成。此时可以喝杯咖啡——剩下的 5 分钟，你基本只能等待。

实操心得：编译中途 Ctrl+C 不会损坏已生成文件，make有智能续编能力。但若make因磁盘满失败，不要直接make clean——它会删掉所有.o文件，从头再来。正确做法是df -h清理空间后，直接make续编。我曾在一台 20GB 磁盘的 VPS 上栽过跟头，make卡在 98% 时提示No space left on device，make clean后重编，又花了 22 分钟。

2.5 make install：安装不是复制，是权限与路径的精密校准

make install看似简单，实则暗藏三处权限雷区：

1. 目标目录所有权：/usr/local/pgsql-11.7必须由当前用户可写。若用sudo make install，则所有文件属主为 root，后续initdb会因无法创建data目录失败。正确姿势是：

   # 创建目录并赋权 sudo mkdir -p /usr/local/pgsql-11.7 sudo chown $USER:$USER /usr/local/pgsql-11.7 # 再执行安装 make install

2. bin 目录的硬链接陷阱：make install会在bin/下创建postgres、postmaster等二进制文件的硬链接。但某些文件系统（如 NFS）不支持硬链接，此时make install会静默失败，bin/postgres为空文件。验证方法：

   ls -li /usr/local/pgsql-11.7/bin/postgres # 正常应显示 inode 号相同（如 123456），若为 0 或不同，则链接损坏

3. share/extension/ 目录的完整性：这是CREATE EXTENSION的根基。make install后检查：

   ls /usr/local/pgsql-11.7/share/extension/ | grep -E "(pg_stat_statements|plpgsql)" # 必须看到 pg_stat_statements.control 和 plpgsql.control

   若缺失，说明configure时漏了--with-python（plpythonu 依赖）或--with-openssl（某些扩展依赖 SSL 头文件）。

安装完成后，执行ls -la /usr/local/pgsql-11.7，确认结构为：

bin/ # 二进制文件 include/ # 头文件（供扩展开发） lib/ # 动态库（libpq.so, pgxs.mk） share/ # SQL 脚本、扩展定义、时区数据

其中share/目录大小应 > 120MB，若只有 20MB，说明--without-docs生效但--with-openssl失效，导致扩展脚本未生成。

2.6 initdb 初始化：数据目录不是空文件夹，是运行时契约的起点

initdb是 PostgreSQL 的“创世仪式”，它生成PG_VERSION、global/、base/等核心目录，并写入初始 WAL 日志。但绝不能在 root 用户下运行——这会导致所有数据文件属主为 root，后续普通用户无法启动postgres进程。

标准流程：

# 创建专用用户（生产环境必须） sudo adduser --home /var/lib/pgsql --shell /bin/bash postgres sudo su - postgres # 创建数据目录（必须空目录） mkdir -p /var/lib/pgsql/data-11.7 chmod 700 /var/lib/pgsql/data-11.7 # 执行初始化（关键参数详解见下表） /usr/local/pgsql-11.7/bin/initdb \ -D /var/lib/pgsql/data-11.7 \ --auth=peer \ --encoding=UTF8 \ --locale=C \ --lc-collate=C \ --lc-ctype=en_US.UTF-8

initdb关键参数避坑指南：

初始化成功后，检查>/usr/local/pgsql-11.7/bin/pg_controldata /var/lib/pgsql/data-11.7

输出中Catalog version number:应为201909212（11.7 的固定值），Database cluster state:应为shut down。若为in production，说明初始化被中断，需rm -rf>/usr/local/pgsql-11.7/bin/pg_ctl \ -D /var/lib/pgsql/data-11.7 \ -l /var/lib/pgsql/data-11.7/logfile \ start # 检查进程 ps aux | grep postgres | grep -v grep # 正常应看到 postmaster 进程，且 -D 参数指向你的 data 目录

第二层：端口监听

ss -tlnp | grep :5432 # 必须看到 LISTEN 状态，且 PID 对应 postmaster 进程号

第三层：本地连接

# 切换到 postgres 用户 sudo su - postgres # 使用 peer 认证连接（无需密码） /usr/local/pgsql-11.7/bin/psql -U postgres -d postgres # 在 psql 中执行 SELECT version(), current_database(), inet_server_addr(); # 应返回 11.7 版本、postgres 库名、本机 IP

第四层：WAL 与共享内存心跳这是最易被忽略的深度验证：

-- 连接后执行 SELECT pg_is_in_recovery(), pg_wal_lsn(), pg_postmaster_start_time(); -- 正常返回：f（非备库）、一串 LSN（如 0/14F0B98）、一个时间戳 -- 若 pg_is_in_recovery() 返回 t，说明 initdb 时指定了 --waldir 或配置了 recovery.conf，需检查 data 目录下是否有该文件

常见问题：psql: FATAL: database "postgres" does not exist。这是因为initdb默认创建template1和template0，但postgres库需手动创建。解决：

CREATE DATABASE postgres OWNER postgres;

至此，一个可调试、可扩展、可审计的 PostgreSQL 11.7 源码实例已就绪。下一步，才是真正的开始：修改源码、添加日志、编译调试。

3. 源码级调试实战：从打第一个断点到读懂查询执行树

3.1 环境准备：gdb + PostgreSQL 符号的黄金组合

源码安装的价值，90% 体现在调试能力上。而gdb调试 PostgreSQL 的前提是：符号表必须完整加载。make install后，/usr/local/pgsql-11.7/bin/postgres是 stripped 的，需用strip --strip-unneeded前的原始文件：

# 编译目录下保留的未 strip 二进制 ls -la /tmp/pg117-src/src/backend/ # 找到 postgres（权限 -rwxr-xr-x，大小 > 15MB） # 复制到安全位置 cp /tmp/pg117-src/src/backend/postgres /usr/local/pgsql-11.7/bin/postgres-debug

然后配置gdb：

gdb /usr/local/pgsql-11.7/bin/postgres-debug (gdb) set environment LD_LIBRARY_PATH=/usr/local/pgsql-11.7/lib (gdb) set args -D /var/lib/pgsql/data-11.7 -c log_statement=all (gdb) break exec_simple_query (gdb) run

这里break exec_simple_query是关键入口——所有 SQL 查询都经过此函数。log_statement=all确保你能看到每条语句的执行日志，与 gdb 断点联动。

注意：gdb不能 attach 正在运行的postmaster进程，因为它是守护进程，会 fork 出postgres子进程处理连接。正确方式是gdb直接run启动，或attach到子进程（需先kill -STOP主进程，再ps aux | grep postgres | grep -v postmaster找子进程 PID）。

3.2 调试一个 SELECT：从网络包到执行计划的全链路追踪

我们以一条简单查询为例：

SELECT * FROM pg_class WHERE relname = 'pg_class';

在gdb中设置断点后，执行此查询，gdb会停在exec_simple_query。此时用bt查看调用栈：

#0 exec_simple_query (query_string=0x1234567 "SELECT * FROM pg_class WHERE relname = 'pg_class';") #1 PostgresMain (argc=1, argv=0x7fff12345678, dbname=0x1234567, username=0x1234567) #2 BackendRun (port=0x1234567) #3 BackendStartup (port=0x1234567)

逐层step进入：

• exec_simple_query→pg_parse_query：SQL 文本转RawStmt结构体；
• pg_analyze_and_rewrite→parse analysis：语义分析，检查pg_class是否存在；
• pg_plan_queries→standard_planner：生成执行计划，此处会调用create_seqscan_plan（因为无索引）；
• ExecutorStart→ExecInitSeqScan：初始化顺序扫描节点；
• ExecutorRun→ExecSeqScan：真正读取数据块。

最关键的洞察在ExecSeqScan函数内：

// src/backend/executor/nodeSeqscan.c TupleTableSlot * ExecSeqScan(PlanState *pstate) { SeqScanState *node = castNode(SeqScanState, pstate); // 此处 node->ss.ss_currentScanDesc 指向 HeapScanDesc // 而 HeapScanDesc->rs_rd 指向 Relation，即 pg_class 的表描述符 // rs_rd->rd_rel->relkind == 'r' 表示是普通表 }

gdb中print node->ss.ss_currentScanDesc->rs_rd->rd_rel->relname.data，就能看到"pg_class"——你亲手看到了查询如何定位到物理表。

实操心得：gdb调试时，print命令前加set print pretty on，结构体输出自动缩进；set print elements 0防止长字符串被截断。这些小技巧能让调试效率提升 50%。

3.3 修改源码：给 pg_stat_statements 加一个自定义字段

源码安装的终极价值，是能自由修改。我们以增强pg_stat_statements为例——官方版本只统计执行次数、总耗时、最大耗时，但不记录“最后一次执行时间”。这对监控异常查询极有价值。

步骤：

1. 定位源码：/tmp/pg117-src/contrib/pg_stat_statements/pg_stat_statements.c
2. 在pgss_store函数中（约第 820 行），找到entry->calls++行，在其后添加：

   entry->last_call_time = GetCurrentTimestamp();

3. 在结构体定义struct pgssEntry（约第 120 行）中，添加字段：

   TimestampTz last_call_time; /* last execution time */

4. 修改pg_stat_statements的 SQL 视图定义（pg_stat_statements--1.6.sql），在SELECT列表中加入last_call_time。

然后重新编译安装：

cd /tmp/pg117-src/contrib/pg_stat_statements make clean && make && sudo make install

重启 PostgreSQL 后：

SELECT query, calls, last_call_time FROM pg_stat_statements LIMIT 1; -- now returns the new column

这就是源码安装赋予你的能力：不依赖任何第三方 patch，不等待下一个版本，当场实现需求。

4. 常见问题与硬核排查：那些官网文档不会写的血泪经验

4.1 “configure: error: library 'readline' is required for psql” —— 但明明装了！

这是最经典的“幻觉错误”。原因有三：

1. readline 头文件路径未被发现：configure通过pkg-config readline --cflags获取路径，若pkg-config未安装或 readline.pc 未在PKG_CONFIG_PATH中，就会失败。解决：

   # 查找 readline.pc find /usr -name "readline.pc" 2>/dev/null # 若在 /usr/local/lib/pkgconfig/readline.pc，则 export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH

2. readline 版本太低：configure检查RL_VERSION_MAJOR，若为 5.x，直接拒绝。验证：

   echo '#include <readline/readline.h>' | gcc -E - 2>/dev/null | grep RL_VERSION_MAJOR # 应输出 #define RL_VERSION_MAJOR 6

3. 静态库 vs 动态库冲突：某些系统同时存在libreadline.a（静态）和libreadline.so（动态），configure优先选静态，但链接时找不到-lreadline。强制指定动态：

   ./configure LDFLAGS="-L/usr/lib64 -lreadline"

4.2 make 编译卡在 “Compiling src/backend/utils/adt/geo_ops.c” —— 实际是内存不足

geo_ops.c是 PostgreSQL 最大的单文件（> 20000 行），GCC 编译时内存峰值达 1.8GB。make卡住时，top会看到cc1进程 CPU 0%，RSS 1.7GB。此时kill -9无用，必须swapoff -a释放 swap 后重试。

根本解法：限制 GCC 内存使用：

# 编译前设置环境变量 export GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01' export CC="gcc -frecord-gcc-switches" # 并在 configure 中加入 ./configure CFLAGS="-O2 -g -fno-omit-frame-pointer -fno-stack-protector"

-fno-stack-protector可降低geo_ops.c编译内存 30%。

4.3 initdb 后 pg_ctl start 报 “could not create lock file” —— 权限还是路径？

错误日志通常在pg_log/下，但initdb时未指定-l，日志可能在/tmp。真正原因是：postmaster.pid文件被残留进程锁定。

排查步骤：

# 查找残留 pid 文件 find /var/lib/pgsql -name "postmaster.pid" 2>/dev/null # 若存在，cat 查看内容，第一行是 PID cat /var/lib/pgsql/data-11.7/postmaster.pid | head -1 # 用 ps 确认该 PID 是否存活 ps -p <PID> # 若不存在，直接 rm -f postmaster.pid # 若存在，kill -9 <PID> 后再 rm

注意：postmaster.pid不是锁文件，而是进程状态快照。强行删除正在运行的 PID 文件，会导致pg_ctl stop失败，但start不受影响。

4.4 psql 连接报 “psql: could not connect to server: No such file or directory” —— Unix socket 路径错了

psql默认连接/tmp/.s.PGSQL.5432，但initdb时若未指定-k，socket 路径由unix_socket_directories参数决定，默认是/tmp。但某些系统（如 macOS）/tmp是内存文件系统，重启后清空。

解决：在postgresql.conf中显式设置：

unix_socket_directories = '/var/run/postgresql'

然后mkdir -p /var/run/postgresql && chmod 1777 /var/run/postgresql，再pg_ctl restart。

验证：psql -h /var/run/postgresql -p 5432 -U postgres。

4.5 源码调试时 gdb 报 “No symbol table loaded” —— 符号没加载

原因：gdb加载的是install后的 stripped 二进制。必须用编译目录下的原始文件：

# 正确路径 gdb /tmp/pg117-src/src/backend/postgres # 错误路径 gdb /usr/local/pgsql-11.7/bin/postgres

若仍无符号，检查configure是否用了--enable-debug，并在gdb中执行：

(gdb) info files # 应看到 "Symbols from "/tmp/pg117-src/src/backend/postgres"" # 若显示 "No debugging symbols found"，说明 configure 时漏了 -g

5. 后续演进：从源码安装到内核定制的三条可行路径

完成源码安装只是起点。基于 PostgreSQL 11.7，你可以走向三个深度方向：

5.1 方向一：轻量级审计增强 —— 在关键函数注入日志

src/backend/tcop/postgres.c中的exec_simple_query是所有 SQL 的入口。在此函数开头添加：

ereport(LOG, (errmsg("AUDIT: user %s db %s query %s", GetUserNameFromId(GetUserId(), false), get_database_name(MyDatabaseId), query_string)));

重新编译后，所有查询都会写入日志。这比log_statement=all更轻量，且可定制字段（如客户端 IP、执行时长）。

5.2 方向二：WAL 格式定制 —— 修改 wal_level 语义

wal_level默认replica，但你想为某个表开启“逻辑复制级” WAL，而其他表保持replica。修改src/backend/access/transam/xlog.c中XLogSetRecordFlags，根据