想象你正坐在一家只能容纳一桌客人的小餐厅里。厨房只有一个炉子，但每天要接待几十位客人。老板不愿意花大钱雇十个厨师，于是发明了一套"接力"流程：客人坐下前先填一份菜单，写好之后交给厨房；厨房不是一道菜做完再接下一道，而是把今天的菜单攒成一摞，按"出餐顺序"一份一份炒；炒好了用小窗口递出去；客人吃完再喊下一份。整个过程里，菜单会不断被改写（客人加菜）、堆叠（多桌拼桌）、回滚（某桌取消）。
想象一下，PostgreSQL 里有 200 个 backend 同时挤在 shared_buffers 上抢同一个热点 page。某个 backend 在等 WALFlush，另一个在等 LockManager，还有一个在等客户端的下一条 SQL。它们都在睡觉，但都不能用 sleep(1)——一秒后醒来数据可能早被别人改完了。
本文是「PostgreSQL 源码系列」内核开发篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql，REL183 之后 77 commit）。同系列前文：
本文是「PostgreSQL 源码系列」并发篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：
本文是「PostgreSQL 源码系列」执行器篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：
本文是「PostgreSQL 源码系列」压测篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：
本文是「PostgreSQL 源码系列」的逻辑复制 worker 模型篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：
本文是「PostgreSQL 源码系列」的逻辑复制性能篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：
本文是「PostgreSQL 源码系列」的总览篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：
本文是「PostgreSQL 系列」的视角篇 · 三。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：
本文是「PostgreSQL 系列」的视角篇 · 二。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：
本文是「PostgreSQL 系列」的视角篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：
本文是「PostgreSQL 逻辑复制系列」的第 N 篇，重点不在原理拆解，而在「用一条 docker compose up -d 把 publisher/subscriber 拉起来」。同系列前文：
本文是「PostgreSQL 逻辑复制系列」的第 N 篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：
本文是「PostgreSQL 逻辑复制系列」的第 N 篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：
本文是「PostgreSQL 逻辑复制系列」的 spill 专题。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：
本文是「PostgreSQL 逻辑复制系列」的延伸篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：
本文是「PostgreSQL 逻辑复制系列」的第 N 篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：
本文是 PostgreSQL 逻辑复制与分区表：从 publisher 到 partition leaf 的全链路 的深度细化篇。
本文是 PostgreSQL 逻辑复制的 Worker 模型 与 PostgreSQL 逻辑复制与分区表：从 publisher 到 partition leaf 的全链路 的姊妹篇。
本文是 PostgreSQL 逻辑复制与分区表：从 publisher 到 partition leaf 的全链路 的姊妹篇。
本文是 PostgreSQL 分区表：从一行 PARTITION BY 到路由热路径的全链路拆解 的姊妹篇。
本文是 PostgreSQL 分区表：从一行 PARTITION BY 到路由热路径的全链路拆解 的前置文档。那篇深挖内核源码、catalog、relcache、路由算法；这一篇专门讲实战使用——两边的步骤、典型场景、详细差异。
想象你是一家快递公司的调度总监。每天有几百万个包裹要按目的地分拣。一开始你让所有快递员把包裹堆在一张巨大的桌子上，靠肉眼找路线——等找到时客户已经催单催到爆。
本文为 PostgreSQL 官方 Wiki Don't Do This 页面的中文翻译整理。- 原文链接：https://wiki.postgresql.org/wiki/Don%27tDoThis
本文为 Hazel Bachrach 所著 What I Wish Someone Told Me About Postgres 一文的中文翻译整理。
本文为 Dr. Raphael A. Bauer 所写 PostgreSQL for Everything 一文的中文翻译整理。
CREATE SUBSCRIPTION 那一长串 WITH (...) 参数，每个都对应 pg_subscription 系统表里的一列，背后是 apply worker 一段真实的代码分支。
PostgreSQL 启动时申请的 shared_buffers 那一大段内存，其实只是冰山一角。整座数据库的"内存世界"由三层拼起来：
想象一下，你正坐在一家 24 小时营业的自助图书馆里。顾客们进进出出，有人想改书里的一段话，有人想删掉某一页。如果每改一次都要把整本书收回柜台、贴上封条、再发出去，那这家图书馆基本就瘫痪了。
本文介绍如何使用 BenchmarkSQL 对 PostgreSQL 进行 TPC-C 压测，重点覆盖配置、数据装载、运行命令、执行链路、结果分析和常见故障排查。
目标：搞清楚 OLTP 的行存与 OLAP 的列存的本质差异，了解 PG 原生为啥是行存、cstorefdw / parquetfdw / Hydra 怎么实现列存、PG 17/18 列存方向。这是面试常被问、也是存储引擎内核最常被重构的方向之一。
目标：吃透 PG 的 logical replication 全套机制——logical decoding、ReorderBuffer、output plugin、publication/subscription、initial sync、conflict handling、walsummarizer。这是 PG 实现跨大版本、跨表、跨粒度复制的核心能力。
目标：吃透 PG 的 streaming replication 全套机制——wal sender、wal receiver、replication slot、sync vs async、cascade、failover、monitoring。这是读写分离、高可用、灾备的基石。
目标：把 PG 的 crash recovery 单独成章，吃透 redo 全流程、timeline 切换、PITR 的内部细节、partial restore、recovery target 与 promote。这是"内核工程师"与"会用 PG"的关键分水岭，因为很多线上故障都靠它定位。
目标：把前面 9 章没覆盖的访问方法与执行层高级特性收口：其他 access method（hash/gist/gin/spgist/brin）、并行执行、分区、FDW、JIT、logical replication。这一章不要求每项精通，但需要知道“这些都怎么入手”。
目标：吃透 PG 的 Write-Ahead Logging 子系统——XLogRecord 结构、rmgr 注册表、redo/undo、checkpoint、recovery、流复制。这是与 InnoDB redo log 最常被拿来对照的部分。
目标：把 PG 的“事务子系统”吃透：xact 状态机、Snapshot、clog/subtrans、lmgr 的表/页/元组三级锁、lwlock、SSI 实现。这是“资深内核开发”与“会用 PG”的分水岭。
目标：从页面布局到搜索 / 插入 / 分裂 / 删除 / WAL 全流程吃透 PG 的 B-Tree 实现。PG 13+ 引入的 deduplication 是重点。
目标：理解 PostgreSQL 堆表的页面布局、HeapTuple 结构、xmin/xmax/cmin/cmax 语义、HOT 链、pruning、vacuumlazy。这是 PG 与 MySQL InnoDB 在工程上最大的差异点。
目标：掌握 PostgreSQL shared buffer pool 的实现——BufferDesc 元数据、hash 索引、clock-sweep 替换策略、AIO 集成、lock 与 pin 的差别。这一章是“存储引擎内核”最关键的章节。
目标：理解 PG 在“OS 文件系统”和“表/索引页面”之间插的一层抽象（Storage Manager），以及默认实现磁碟版（md.c）。这一层是 PG 与其它 DBMS 在工程上差异最大的一处——比 InnoDB 的 fil_system 还更“裸露”。
目标：从 backend 收到一条 query 字节那一刻起，逐函数跟踪到执行器出口。理解 解析 → 重写 → 优化 → 执行 四阶段的产物（RawStmt / Query / PlannedStmt / PlanState）。
目标：理解“一个客户端连接 = 一个 backend 进程”的进程模型，掌握 postmaster 如何 fork / signal 整个家族，以及每个子进程的工作。
目标：能在 ~/cwork/postgresql 上 30 分钟内编译成功、能 GDB 跟一条 SQL、能用 ctags / cscope 在代码里跳转。