【PG 内核】PostgreSQL 内核机制深度拆解
内容提要
该文介绍PostgreSQL内核机制深度拆解系列，共26章，分内核机制与运维实战两部分。内容涵盖进程模型、MVCC、WAL、查询优化、索引、复制等核心机制，并针对故障排查、配置陷阱等实战问题提供方法论。文章强调从源码层面解释“为什么”，而非简单操作指南，适合内核开发者、后端工程师及SRE等读者。
延伸解读
为什么这份资料值得读
中文互联网不缺 PG 操作教程，但缺从源码层面解释“为什么”的系统性资料。本系列承诺给出 PG 17 源码路径、关键函数名和可复现实验，帮助读者自己追踪机制，而非停留在“怎么用”层面。对于想深入内核的开发者、后端工程师和 SRE，这是一份难得的实战与原理结合的资源。
阅读路径设计有讲究
系列按读者角色推荐了不同阅读路径：日常用户从物理基础到查询规划，内核开发者聚焦存储与并发，SRE 则从 MVCC/VACUUM 和故障模式入手。这种设计避免了“从头读到尾”的低效，让不同背景的读者能快速找到与自己工作最相关的章节，提升学习效率。
运维章节强调根因与边界
运维实战部分（第 21–26 章）不写 runbook，而是讲“为什么这样做、不这样做的后果”。例如，连接风暴、wraparound、slot 溢出等故障模式，每个都从内核根因讲到修复边界。这种思路有助于读者真正理解问题本质，而不是机械地执行命令，从而在复杂生产环境中做出正确判断。
Q&A
PostgreSQL 内核机制深度拆解系列包含哪些部分，适合哪些读者？
该系列共26章，分为内核机制（第1-20章）和运维实战（第21-26章）两部分。内容涵盖进程模型、MVCC、WAL、查询优化、索引、复制等核心机制，以及故障排查、配置陷阱等实战问题。适合数据库内核开发者、后端工程师和SRE/DBRE等读者。
PostgreSQL 的进程模型是如何工作的？
PostgreSQL 采用多进程共享内存架构。Postmaster 启动后，通过 fork() 创建 backend 进程处理客户端连接，还有 autovacuum worker 等后台进程。共享内存中包含 PGPROC、LWLock 数组等关键数据结构。fork() 的开销通过缓存和优化来消化。
为什么 PostgreSQL 需要 VACUUM？膨胀是如何发生的？
PG 的 MVCC 机制导致旧版本数据需要清理。VACUUM 负责清理死元组、更新可见性映射、防止事务ID回卷。膨胀是因为更新和删除操作产生死元组，如果不及时清理，表会越来越大，影响性能。
PostgreSQL 查询优化器如何利用统计信息？统计信息不准时怎么办？
优化器使用 pg_statistic 中的统计信息（如MCV、直方图、相关性）估算选择率，并基于代价模型选择执行计划。统计信息不准时，可以通过 ANALYZE 重新采样，或使用扩展统计（CREATE STATISTICS）来改善。
PostgreSQL 高可用方案有哪些？各自的机制边界是什么？
PG 的高可用方案包括流复制和逻辑复制。流复制通过 WAL Sender/Receiver 协议实现，支持同步和异步复制；逻辑复制通过逻辑解码和 reorder buffer 实现，支持更灵活的数据分发。每种方案都有其适用场景和限制，如同步复制可能影响性能，逻辑复制需要处理冲突。
PostgreSQL 最危险的故障模式有哪些？如何排查？
最危险的故障模式包括连接风暴、事务ID回卷（wraparound）、replication slot 溢出、OOM kill 和长事务。排查时可以从第22章入手，该章从内核根因讲到修复边界，并提供排查断点。
work_mem 为什么可能是最危险的 GUC？配错会有什么后果？
work_mem 不是每个操作的内存上限，而是每个操作可用的内存。如果200个连接同时做 hash join，每个连接分配 work_mem，可能导致内存溢出。配错 work_mem 可能导致性能下降或 OOM。
pg_upgrade --link 为什么快且没有回滚机制？
pg_upgrade --link 使用硬链接，零拷贝，所以快。但硬链接意味着新旧数据文件共享同一 inode，升级后旧集群无法独立使用，因此没有回滚机制。
