PostgreSQL 逻辑复制 Stream 执行逻辑源码级拆解：从 reorderbuffer 触发到订阅端落盘回放

本文是「PostgreSQL 逻辑复制源码系列」。定位说明：

PostgreSQL 目录快照源码级深度拆解：系统表读取的 MVCC 真相与失效机制

本文是「PostgreSQL 内核机制源码系列」。同系列前文：

PostgreSQL 读一行数据源码级深度拆解：MVCC 在每个环节的落点

本文是「PostgreSQL 内核机制源码系列」。同系列前文：

逻辑复制发布端现状

逻辑复制发布端解码运行在一个叫LogicalDecodingContext的上下文里，该上下文主要包含如下几个核心部分：

pgoutput_change 到 HeapTupleSatisfiesVisibility 的函数调用栈分析

本文源码基线：PostgreSQL 18（/Users/growduduan/cwork/postgresql），所有行号可直接 cd 到对应源码目录校对。本文聚焦一条关键链路：从输出插件回调 pgoutputchange 一路追到 HeapTupleSatisfiesVisibility 在何种场景下被触发，并在 SNAPSHOTHISTORICMVCC 分支中如何完成可见性判定。

PostgreSQL reorderbuffer.c 函数级源码全集:5615 行 / 95 个函数的逐函数解析

本文是 reorderbuffer.c 源码深度解析 的姊妹篇:前者讲架构/生命周期/数据结构骨架,本文按 reorderbuffer.c 出现的所有 95 个函数 逐个讲透。每个函数都带 文件:行号 / 原型 / 完整代码 / 逐行解释 / 调用方 / 边界情况。

PostgreSQL 逻辑复制:catalog 改动、可见性判定与 xmin/xmax 推进全景

之前几篇(end-to-end 全流程、LSN 推进全景、snapbuild.c 全函数拆解、SnapBuildFindSnapshot 状态机)虽然覆盖了入口、状态机和 LSN 推进,但对catalog 改动如何从 WAL 一路透传到订阅端的可见性判定这一条核心链路解释得不够细致。本文专门补这一段:

PostgreSQL syscache 模块源码深度拆解:CatCache 数据结构、LRU 哈希表、cache invalidation 全链路

配套源码:~/cwork/postgresql/src/backend/utils/cache/{syscache,catcache,inval}.c(共 5243 行)

openGauss 通过 CSN 保证全序的源码级深度分析:从 nextCommitSeqNo 原子计数到订阅端 CSN 校验

配套源码:~/cwork/openGauss-server/(openGauss 2.x / 3.x)涉及文件:access/transam/{xact,cxlog,csnlog,transam,xlog}.cpp、include/c.h、include/access/transam.h、include/access/xact.h、storage/replication/logical/{prot…

openGauss 并行解码设计原理深度拆解:reader + 多 worker + CSN 三层架构的源码级剖析

配套源码:~/cwork/openGauss-server/src/gausskernel/storage/replication/logical/(openGauss 2.x / 3.x,4250 行并行解码核心代码 + 继承自 PostgreSQL 的逻辑复制框架)

PostgreSQL 逻辑复制 LSN 推进全景:从 WAL 字节到订阅者 apply 的全链路 LSN 视角

配套源码:src/backend/replication/{walsender.c, slot.c, slotfuncs.c} + src/backend/replication/logical/* + src/include/access/xlogdefs.h

PostgreSQL SnapBuildFindSnapshot 深度拆解:每条状态转换路径的具体 WAL 日志与前提条件

配套源码:~/cwork/postgresql/src/backend/replication/logical/snapbuild.c:1238-1430(193 行)

PostgreSQL CREATE_REPLICATION_SLOT 端到端源码分析:从 SQL 到 snapbuild 状态机的完整链路(每个函数每个参数)

配套源码:~/cwork/postgresql/src/backend/replication/涉及文件:walsender.c(2146 行的协议入口)、slotfuncs.c(284 行的 SQL 函数)、logical.c(2198 行的解码框架)、slot.c(1300 行的 slot 实现)、snapbuild.c(2076 行的状态机)

PostgreSQL 逻辑复制端到端深度拆解:从 WAL 字节到订阅者 apply 的全链路源码分析

配套源码:~/cwork/postgresql/src/backend/replication/(PG 18 主干,30+ 文件、30K+ 行)

PostgreSQL snapbuild.c 深度解析:逻辑复制"目录快照"子系统全栈拆解

配套源码:~/cwork/postgresql/src/backend/replication/logical/snapbuild.c(PG 18 主干,2076 行)

PostgreSQL 社区精髓资源汇总:从官方文档到内核贡献者博客的"一键直达"清单

配套源码:~/cwork/postgresql(PostgreSQL 18.3)

PostgreSQL 行锁机制源码级深度拆解：4 种锁模式 + xmax + MultiXact 的完整链路

本文是「PostgreSQL 内核机制源码系列」。同系列前文：

PostgreSQL TOAST 机制源码级深度拆解：从 8KB 页面限制到 chunked 分散对齐

本文是「PostgreSQL 内核机制源码系列」。同系列前文：

如何成为资深的 PostgreSQL 内核开发者：从 0 到 Committer 的 18 个月路线 + 36 个内核主题地图 + 12 大子系统架构

本文是「PostgreSQL 内核机制源码系列」的元文章——它本身不深入某个子系统，而是给出研究所有子系统的学习路径。同系列文章：

PostgreSQL 18 内核数据结构全景：RangeVar 与 20+ 个核心数据结构源码级拆解

本文是「PostgreSQL 内核机制源码系列」。同系列前文：

PostgreSQL WAL 记录类型完全指南：21 个 RMGR × 80+ 种记录的源码级拆解

本文是「PostgreSQL 内核机制源码系列」——同系列前文：

PostgreSQL 逻辑复制全链路：以一个真实事务为例，从 `INSERT` 到 `apply` 的源码级旅程

本文是「PostgreSQL 逻辑复制源码系列」第 6 篇——前 5 篇把 RUNNING_XACTS 写盘、SnapBuild 状态机、ReorderBuffer 重组、pgoutput 协议、apply worker 入口都拆解过。本文第一次把它们串成一条线。同系列前文：

PostgreSQL 逻辑复制里 `RUNNING_XACTS` 写入机制与快照 `xmin / xmax / xip` 的演化：源码级深度拆解

本文是「PostgreSQL 逻辑复制源码系列」。同系列前文：

pg_duckdb 深度解析：从 OLTP 到 OLAP hybrid query 的 DuckDB 内嵌扩展

本文是「PostgreSQL 扩展系列」列存 / OLAP 篇。同系列前文：cstore_fdw 深度解析、Citus Columnar 深度解析

TimescaleDB Columnstore（hypercore）深度解析：时序列存压缩的 hybrid engine

本文是「PostgreSQL 扩展系列」列存篇。同系列前文：TimescaleDB 深度解析、cstore_fdw 深度解析

Citus Columnar 深度解析：从 cstore_fdw 到 Table AM 的 PG 原生列存扩展

本文是「PostgreSQL 扩展系列」列存篇。同系列前文：cstore_fdw 深度解析、Citus 深度解析

cstore_fdw 深度解析：从 Hydra 到 Citus Columnar 的列存 FDW 鼻祖

本文是「PostgreSQL 扩展系列」列存篇。同系列前文：TimescaleDB 深度解析、Citus 深度解析

pgBackRest 深度解析：从 pg_basebackup 到企业级备份恢复的 Go 实现

本文是「PostgreSQL 扩展系列」备份恢复篇。同系列前文：PostgreSQL 核心特性全景

pgcrypto 深度解析：从 md5 到 OpenSSL 集成的 PG 加密扩展

本文是「PostgreSQL 扩展系列」加密篇。同系列前文：PostgreSQL 核心特性全景

pgAudit 深度解析：从 log_statement 到 PG 审计标准的合规扩展

本文是「PostgreSQL 扩展系列」审计合规篇。同系列前文：PostgreSQL 核心特性全景

pg_stat_statements 深度解析：从 query hash 到 pg_stat_* 生态的查询统计扩展

本文是「PostgreSQL 扩展系列」观测篇。同系列前文：PostgreSQL 核心特性全景

Citus 深度解析：从分布式 SQL 到列存扩展的 PG 集群引擎

本文是「PostgreSQL 扩展系列」分布式篇。同系列前文：

TimescaleDB 深度解析：从时间分区到列存压缩的 PG 时序数据库扩展

本文是「PostgreSQL 扩展系列」时序篇。同系列前文：

pgvector 深度解析：从 ANN 索引到 RAG 时代的向量数据库核心

本文是「PostgreSQL 扩展系列」AI / 向量篇。同系列前文：

PostGIS 深度解析：从 OGC Simple Features 到 PG 18 时代的 GIS 引擎

本文是「PostgreSQL 扩展系列」GIS 篇。同系列前文：

PostgreSQL 核心特性全景：12 大功能的设计动因、实现原理与版本演化

本文是「PostgreSQL 源码系列」设计篇。同系列前文：

PostgreSQL 前世今生：从 1986 Berkeley 实验室到 2025 全球基础设施，一条开源数据库的 39 年演化史

本文是「PostgreSQL 源码系列」项目篇。同系列前文：

PostgreSQL 元数据存储机制：从磁盘文件到内存缓存，`pg_class` 撑起的整个系统表体系

本文是「PostgreSQL 源码系列」元数据与缓存篇。同系列前文：

PostgreSQL libpq 机制与缓冲区详解

想象你正坐在一家只能容纳一桌客人的小餐厅里。厨房只有一个炉子，但每天要接待几十位客人。老板不愿意花大钱雇十个厨师，于是发明了一套"接力"流程：客人坐下前先填一份菜单，写好之后交给厨房；厨房不是一道菜做完再接下一道，而是把今天的菜单攒成一摞，按"出餐顺序"一份一份炒；炒好了用小窗口递出去；客人吃完再喊下一份。整个过程里，菜单会不断被改写（客人加菜）、堆叠（多桌拼桌）、回滚（某桌取消）。

PostgreSQL Latch 机制详解：从一行 SetLatch 到 epoll 的内核之旅

想象一下，PostgreSQL 里有 200 个 backend 同时挤在 shared_buffers 上抢同一个热点 page。某个 backend 在等 WALFlush，另一个在等 LockManager，还有一个在等客户端的下一条 SQL。它们都在睡觉，但都不能用 sleep(1)——一秒后醒来数据可能早被别人改完了。

reorderbuffer.c 源码深度解析:PostgreSQL 逻辑复制的"事务重组引擎

PostgreSQL 的逻辑复制链路:

applyparallelworker.c 之 LA 端源码深度解析:Leader Apply Worker 的指挥中枢

applyparallelworker.c 表面上是一个 1646 行的文件,但里面同时承载了 两套截然不同的角色:

applyparallelworker.c 源码深度解析:1646 行代码的完整结构与模块协作

配套源码:~/cwork/postgresql(基于 PG 18 主干)

Apply Parallel Worker 的 lock_stream 与 unlock_stream:为什么"获得就释放"的死锁防护机制

配套源码:~/cwork/postgresql(基于 PG 18 主干)

Injection Point 与 PG 测试框架集成实战:从 Makefile 到 .spec 完整链路

配套源码:~/cwork/postgresql(基于 PG 18 主干)

用 Injection Point 测试无法到达的代码路径:3 种改造模式 + 实战

配套源码:~/cwork/postgresql(基于 PG 18 主干)

PostgreSQL 18 Injection Point 完整指南:原理、API 与实战

配套源码:~/cwork/postgresql(基于 PG 18 主干)

PostgreSQL 18 流式逻辑复制发布端深度解析:从 logical_decoding_work_mem 到 stream_commit 的完整链路

配套源码:~/cwork/postgresql(基于 PG 18 主干)

从内核开发者视角,在 PostgreSQL 18 逻辑复制中新增一个 GUC 参数

配套源码:~/cwork/postgresql(基于 PG 18 主干)

PostgreSQL 行锁机制深度解析:从 MVCC 到多级锁的完整链路

配套源码:~/cwork/postgresql(基于 PG 18 主干)

火焰图怎么看:从一张图到优化方向的完整方法论

配套前文:PostgreSQL 逻辑复制性能分析:火焰图实战 —— 那一篇讲 PG 实战,这一篇讲通用方法论。

PostgreSQL 逻辑复制 Apply Parallel Worker 参数调优实战

配套源码:~/cwork/postgresql(基于 PG 18 主干)配套前文:Apply Parallel Worker 运行机制解析

PostgreSQL 逻辑复制 Apply Parallel Worker 运行机制深度解析

源码基线:PostgreSQL 18(src/backend/replication/logical/{applyparallelworker,worker,launcher}.c)

TWPA 概要设计文档

文档版本:v1.0适配版本:PostgreSQL 18源码基线:src/backend/replication/logical/{worker,applyparallelworker,launcher}.c、src/include/replication/{logicalworker,worker_internal}.h

逻辑复制并行 Apply 用户接口文档

文档版本:v1.0适配版本:PostgreSQL 18(含社区已合入的并行 Apply 增强补丁)源码基线:src/backend/replication/logical/{worker,applyparallelworker,launcher,tablesync}.c

TWPA 依赖冲突检测设计文档

文档版本:v1.0适配版本:PostgreSQL 18源码基线:src/backend/replication/logical/{worker,applyparallelworker}.c、src/include/replication/worker_internal.h

PostgreSQL 逻辑复制性能分析:火焰图实战

本文是一份性能分析入门 + 实战指南。前半段讲清楚火焰图和 perf 是什么、怎么用;后半段用 PostgreSQL 逻辑复制的 4 个真实问题,演示怎么用火焰图定位瓶颈。读完你会获得一个完整的"实战方法论"。

Linux 共享内存机制:从内核到主流项目实践

本文从 Linux 内核视角讲清楚共享内存 —— 为什么有它、内核是怎么实现的、用户态有哪些 API、主流开源项目怎么用。读者:内核 / 系统 / 后端 / 数据库开发者。

PostgreSQL 共享内存机制:原理、使用与开发

本文基于 PostgreSQL 18 源码(src/backend/storage/ipc/、src/backend/utils/mmgr/),从内核视角讲清楚共享内存是怎么回事 —— 为什么需要它、它分几层、内核开发者怎么用它。

PostgreSQL 内核开发：读取一张表的 9 步标准流程与缓存全景

本文是「PostgreSQL 源码系列」内核开发篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql，REL183 之后 77 commit）。同系列前文：

PostgreSQL Background Worker 全解：从 `RegisterBackgroundWorker` 到逻辑复制 4 类 worker 的全生命周期

本文是「PostgreSQL 源码系列」并发篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：

PostgreSQL 18 并行 Worker 机制全解：从 `ParallelContext` 到 `ParallelQueryMain` 的全链路

本文是「PostgreSQL 源码系列」执行器篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：

pgbench 源码全解：一个 C 文件如何撑起 PostgreSQL 官方压测工具

本文是「PostgreSQL 源码系列」压测篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：

PostgreSQL 18 逻辑复制的并行解码与并行 Apply：源码全景

本文是「PostgreSQL 源码系列」的逻辑复制 worker 模型篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：

PostgreSQL 逻辑复制性能与速率测试：从一个公开的"没有"讲起

本文是「PostgreSQL 源码系列」的逻辑复制性能篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：

从 `postgres` 二进制到生产级守护 —— PostgreSQL 最外层模块与启动全流程拆解

本文是「PostgreSQL 源码系列」的总览篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：

为什么要对数据库进行细分：从 RDBMS 到 12 类专用数据库的全景图

本文是「PostgreSQL 系列」的视角篇 · 三。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：

选数据库的时候，我们究竟在选什么 —— 当基础能力都满足时，哪些维度让数据库"脱颖而出"

本文是「PostgreSQL 系列」的视角篇 · 二。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：

当我们在说"数据库"的时候，我们到底在说什么 —— 从用户的视角拆解 PostgreSQL 的能力与接口

本文是「PostgreSQL 系列」的视角篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：

PostgreSQL 逻辑复制集群搭建指北：基于 Docker 的 publisher + subscriber 一键拉起

本文是「PostgreSQL 逻辑复制系列」的第 N 篇，重点不在原理拆解，而在「用一条 docker compose up -d 把 publisher/subscriber 拉起来」。同系列前文：

PostgreSQL 逻辑复制支持 DDL 之后：DDL 与 DML 的时序难题（重点：分区表）

本文是逻辑复制系列的深度专题。

PostgreSQL 逻辑复制的 ReorderBuffer 与事务机制：从一行 WAL 到一致性变更流的全链路绑定

本文是「PostgreSQL 逻辑复制系列」的第 N 篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：

PostgreSQL 逻辑复制的监控：六张视图 + 一组可执行 SQL，把 publisher/subscriber 的速率与健康度彻底看透

本文是「PostgreSQL 逻辑复制系列」的第 N 篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：

PostgreSQL 逻辑复制 spill 文件深度剖析：从 `xid-*.spill` 到 TPC-C 的增长方程

本文是「PostgreSQL 逻辑复制系列」的 spill 专题。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：

PostgreSQL 逻辑复制 streaming 与 spill：从 reorderbuffer 到 `<subid>-<xid>.changes` 的全程真相

本文是「PostgreSQL 逻辑复制系列」的延伸篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：

PostgreSQL 逻辑复制表的生命周期：从 `pg_replication_slots` 到 `pg_subscription_rel` 的全景图

本文是「PostgreSQL 逻辑复制系列」的第 N 篇。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：

PostgreSQL 逻辑复制：`publish_via_partition_root` 的完整行为分析

本文是分区表 + 逻辑复制系列的第六篇。

PostgreSQL 逻辑复制下分区表的 INSERT：从 publisher 到 leaf 的完整时序

本文是 PostgreSQL 逻辑复制与分区表：从 publisher 到 partition leaf 的全链路 的深度细化篇。

PostgreSQL 逻辑复制：DDL 同步后如何启动 apply worker 同步 DML（分区表专题）

本文是 PostgreSQL 逻辑复制的 Worker 模型 与 PostgreSQL 逻辑复制与分区表：从 publisher 到 partition leaf 的全链路 的姊妹篇。

PostgreSQL 逻辑复制的 Worker 模型：一个 apply worker 撑全场，分区表也一样

本文是 PostgreSQL 逻辑复制与分区表：从 publisher 到 partition leaf 的全链路 的姊妹篇。

PostgreSQL 逻辑复制与分区表：从 publisher 到 partition leaf 的全链路

本文是 PostgreSQL 分区表：从一行 PARTITION BY 到路由热路径的全链路拆解 的姊妹篇。

PostgreSQL vs SQL Server 分区表实战：步骤、场景与差异对比

本文是 PostgreSQL 分区表：从一行 PARTITION BY 到路由热路径的全链路拆解 的前置文档。那篇深挖内核源码、catalog、relcache、路由算法；这一篇专门讲实战使用——两边的步骤、典型场景、详细差异。

PostgreSQL 分区表：从一行 `PARTITION BY` 到路由热路径的全链路拆解

想象你是一家快递公司的调度总监。每天有几百万个包裹要按目的地分拣。一开始你让所有快递员把包裹堆在一张巨大的桌子上，靠肉眼找路线——等找到时客户已经催单催到爆。

PostgreSQL "Don't Do This" 完整中文版

本文为 PostgreSQL 官方 Wiki Don't Do This 页面的中文翻译整理。- 原文链接：https://wiki.postgresql.org/wiki/Don%27tDoThis

真希望有人早点告诉我的 Postgres 经验

本文为 Hazel Bachrach 所著 What I Wish Someone Told Me About Postgres 一文的中文翻译整理。

PostgreSQL 万能论：为什么一家公司可以用它替代 Kafka、Redis、Elastic 与 ClickHouse

本文为 Dr. Raphael A. Bauer 所写 PostgreSQL for Everything 一文的中文翻译整理。

PostgreSQL 逻辑复制订阅参数全解：从 run_as_owner 到 disable_on_error

CREATE SUBSCRIPTION 那一长串 WITH (...) 参数，每个都对应 pg_subscription 系统表里的一列，背后是 apply worker 一段真实的代码分支。

PostgreSQL 内存管理：一片共享内存，三座分配器，一座缓冲池

PostgreSQL 启动时申请的 shared_buffers 那一大段内存，其实只是冰山一角。整座数据库的"内存世界"由三层拼起来：

PostgreSQL 事务：一次 BEGIN 与 COMMIT 背后的双层世界

如果你只学过 SQL，看到事务大概是这样的：

PostgreSQL MVCC：一条数据是如何拥有"分身术"的

想象一下，你正坐在一家 24 小时营业的自助图书馆里。顾客们进进出出，有人想改书里的一段话，有人想删掉某一页。如果每改一次都要把整本书收回柜台、贴上封条、再发出去，那这家图书馆基本就瘫痪了。

BenchmarkSQL 使用教程：从配置到运行机制分析

本文介绍如何使用 BenchmarkSQL 对 PostgreSQL 进行 TPC-C 压测，重点覆盖配置、数据装载、运行命令、执行链路、结果分析和常见故障排查。

13 逻辑复制深入

目标：吃透 PG 的 logical replication 全套机制——logical decoding、ReorderBuffer、output plugin、publication/subscription、initial sync、conflict handling、walsummarizer。这是 PG 实现跨大版本、跨表、跨粒度复制的核心能力。

14 列存与 cstore_fdw

目标：搞清楚 OLTP 的行存与 OLAP 的列存的本质差异，了解 PG 原生为啥是行存、cstorefdw / parquetfdw / Hydra 怎么实现列存、PG 17/18 列存方向。这是面试常被问、也是存储引擎内核最常被重构的方向之一。

12 物理复制深入

目标：吃透 PG 的 streaming replication 全套机制——wal sender、wal receiver、replication slot、sync vs async、cascade、failover、monitoring。这是读写分离、高可用、灾备的基石。

11 崩溃恢复深入

目标：把 PG 的 crash recovery 单独成章，吃透 redo 全流程、timeline 切换、PITR 的内部细节、partial restore、recovery target 与 promote。这是"内核工程师"与"会用 PG"的关键分水岭，因为很多线上故障都靠它定位。

10 进阶特性

目标：把前面 9 章没覆盖的访问方法与执行层高级特性收口：其他 access method（hash/gist/gin/spgist/brin）、并行执行、分区、FDW、JIT、logical replication。这一章不要求每项精通，但需要知道“这些都怎么入手”。

09 WAL 与恢复

目标：吃透 PG 的 Write-Ahead Logging 子系统——XLogRecord 结构、rmgr 注册表、redo/undo、checkpoint、recovery、流复制。这是与 InnoDB redo log 最常被拿来对照的部分。

08 事务、锁与并发

目标：把 PG 的“事务子系统”吃透：xact 状态机、Snapshot、clog/subtrans、lmgr 的表/页/元组三级锁、lwlock、SSI 实现。这是“资深内核开发”与“会用 PG”的分水岭。

07 B-Tree 索引

目标：从页面布局到搜索 / 插入 / 分裂 / 删除 / WAL 全流程吃透 PG 的 B-Tree 实现。PG 13+ 引入的 deduplication 是重点。

06 堆表与 MVCC

目标：理解 PostgreSQL 堆表的页面布局、HeapTuple 结构、xmin/xmax/cmin/cmax 语义、HOT 链、pruning、vacuumlazy。这是 PG 与 MySQL InnoDB 在工程上最大的差异点。

05 缓冲区管理

目标：掌握 PostgreSQL shared buffer pool 的实现——BufferDesc 元数据、hash 索引、clock-sweep 替换策略、AIO 集成、lock 与 pin 的差别。这一章是“存储引擎内核”最关键的章节。

04 存储抽象层 SMGR

目标：理解 PG 在“OS 文件系统”和“表/索引页面”之间插的一层抽象（Storage Manager），以及默认实现磁碟版（md.c）。这一层是 PG 与其它 DBMS 在工程上差异最大的一处——比 InnoDB 的 fil_system 还更“裸露”。

03 查询管线全景

目标：从 backend 收到一条 query 字节那一刻起，逐函数跟踪到执行器出口。理解 解析 → 重写 → 优化 → 执行 四阶段的产物（RawStmt / Query / PlannedStmt / PlanState）。

02 进程架构与生命周期

目标：理解“一个客户端连接 = 一个 backend 进程”的进程模型，掌握 postmaster 如何 fork / signal 整个家族，以及每个子进程的工作。

01 编译调试与代码布局

目标：能在 ~/cwork/postgresql 上 30 分钟内编译成功、能 GDB 跟一条 SQL、能用 ctags / cscope 在代码里跳转。

DDL同步架构（美化版）

:root {--primary: #2c5aa0;--primary-light: #4a7fc7;--secondary: #6c5ce7;

逻辑解码DDL Replay框架设计

当前逻辑复制支持DDL同步功能已适配PG模式，其整体流程如下：

postgresql逻辑复制(DML)

postgresql逻辑复制采用发布者订阅者模式，并且发布者和订阅者之间是多对多的关系。

逻辑复制适配sqlserver模式分区表问题分析

问题原因：逻辑复制同步DDL在sqlserver模式下不支持分区表同步，根本原因为分区表创建依赖于Partition Function 、Partition Scheme，但这两个语句不走PG标准的执行流程（ProcessUtility），无法被捕获。

逻辑复制支持同步系统表概要设计

下面给你一份基于 PG18 的“逻辑复制支持系统表同步”完整设计文档（可直接用于研发/评审）。我会严格结合你前面分析的源码链路来设计，重点保证：

PostgreSQL 逻辑复制支持系统表同步详细设计文档

本设计的目标不是实现完整 DDL 自动复制链路，而是先补齐以下两项基础能力：

支持逻辑复制同步 DDL 适配 SQL Server 方案

Babelfish 是 PostgreSQL 的一个扩展，通过双端口设计支持 SQL Server 协议：

内核执行 Babelfish 上下文需要考虑的问题

SQL Server 和 PG 本身在数据库架构层面 schema 的含义就不一致：

逻辑复制同步ddl适配bbf面临的挑战

1.当前产品面向比亚迪现场，现场需要sqlserver模式，当前sqlserver模式下的逻辑复制能力范围边界尚不清楚；（从产品和架构层面出发评估）

SQLServer模式逻辑复制DDL支持 - 架构分析

{margin: 0;padding: 0;box-sizing: border-box;}body {font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif;

sqlserver模式逻辑复制支持ddl

当前数据库使用babelfish插件（bbf）来支持sqlserver模式，bbf采用双端口的设计：即数据库在启动时会监听多个端口，一般是pg原生的端口和tsql端口，比如5432和1433.

Babelfish DDL 同步已知限制与客户使用建议

本文档汇总 Babelfish 插件在 SQL Server 模式下使用逻辑复制 DDL 自动同步时的已知限制，并按客户使用影响给出分级和建议做法。

安装mysql

逻辑解码ddl replay支持sqlserver模式

当前 PostgreSQL Logical Replication 仅支持 DML 同步。

逻辑复制系统表支持DDL实现问题

逻辑解码会过滤掉系统表，不支持系统表进行逻辑解码；2. pglogical使用的是用户表，并使用usercatalogtable=true;

多数据库模式命名空间问题

PostgreSQL 的 searchpath 可以设置多个 schema，但其他数据库如 Oracle 的 ALTER SESSION SET CURRENTSCHEMA = ZXF 只能设置一个。这在一条 SQL 包含多个 schema 的场景下，无法进行直接转换。

数据库命名空间机制对比

本文档对比主流数据库（PostgreSQL、Oracle、MySQL、SQL Server）的 schema/命名空间机制。

ddl同步架构

逻辑复制支持ddl ai配置流程

逻辑复制支持DDL概要设计

PostgreSQL 当前内建逻辑复制主要覆盖表级 DML 复制。logical decoding 的本质是从 WAL 中提取持久化变更，转成更高层可理解的变更流；复制槽保证“按源端发生顺序”向客户端提供变化序列。([PostgreSQL][1])

逻辑复制支持DDLAI提示词

逻辑复制需要支持自动同步DDL。

一、结论（先说清楚）

这个问题非常关键，而且是内核方案必须回答清楚的两个核心风险：

1. 设计选择

可以，下面我直接给你一版接近 PostgreSQL patch 风格的 LogLogicalDDLMessage() 实现草稿。它的设计核心是：复用 PostgreSQL 现有 generic logical decoding message 的 WAL 记录格式与写入路径。

逻辑复制DDL支持详细设计方案

逻辑复制当前仅支持同步DML操作。为了提升用户使用体验和增强逻辑复制功能，需要扩展支持DDL（数据定义语言）的自动同步。

逻辑复制源码分析

逻辑复制与物理复制使用相同的发送框架，都在walsender中进行发送。整体流程大致如下：

逻辑复制验证步骤

1.使用root用户执行如下编译

逻辑复制解惑

在初次写入数据的时候，ddl写到了系统表，dml先写入日志，然后apply成数据。当前逻辑复制的原理是根据lsn读取wal日志，将wal日志decode成sql，然后发送目标端。

逻辑复制支持DDL开发交付计划

[x] 添加用户接口和参数校验；- [x] 新增系统表pgpublicationsync；- [x] 客户端DDL捕获保存

支持ddl评审相关问题

一个DDL需要多个事务，比如在线建分区；2. 性能问题；（发布性能较低，流式发布）3. 用户接口跟产品确认；（用户接口清单，ddl同步范围），table和others的清单列出；

指定列同步对逻辑复制支持DDL的影响

在逻辑复制支持DDL的需求分析中，需要考虑如下场景：

PostgreSQL 15 逻辑复制操作流程详解

本文通过实际操作演示 PostgreSQL 15 逻辑复制的完整流程，重点展示：- WAL（Write-Ahead Logging）日志的生成与解析

PostgreSQL `LogLogicalMessage`

本文面向需要理解 PostgreSQL 逻辑复制/逻辑解码链路的开发人员，解释 LogLogicalMessage 的定位、内部实现、设计初衷和工程使用方式。

pg常用函数

在 PostgreSQL 扩展开发中，DefineCustom*Variable 系列函数用于 注册自定义 GUC（Grand Unified Configuration）参数。

逻辑复制支持DDL需求分析

postgresql当前的逻辑复制仅支持复制DML，不支持复制DDL，需要手动在目标端执行DDL。

pglogical支持DDL搭建

使用如下命令初始化数据库：

pg15逻辑复制支持DDL

如果你的目标是：

pglogical.so详解

pglogical.so是pglogical中的数据库扩展（extension），负责管理复制拓扑、节点、replication set、apply worker 等控制逻辑。

逻辑解码支持DDL

逻辑解码需要源端数据库把DDL转换成某一种格式存储，可以是某种数据库语法格式的sql或者其他格式的文本文件，比如json。

polardb逻辑解码

对于同构数据库，由于polardb采用共享存储实现，其会把DDL写入wal，因为只有一份物理数据，采用DDL锁同步DDL；

pglogical详解

pglogical 是 PostgreSQL 的拓展模块, 为 PostgreSQL 数据库提供了逻辑流复制发布和订阅的功能。

ai逻辑解码

基于对PolarDB源码和PostgreSQL LogLogicalMessage 机制的分析，以下是DDL自动传输的实现原理详解：

DDL

数据定义语言（DDL）是SQL（结构化查询语言）的一部分，它用于定义、管理和控制数据库的结构和元素。

使用meson编译pg

一般在build目录下进行编译，先生成编译需要文件：

逻辑解码

逻辑解码（Logical Decoding）是 PostgreSQL（及其扩展版本）提供的一套机制，用来将 WAL（物理日志）中的数据修改恢复成“逻辑级别”的变更事件：

polardb竞争力分析

100%兼容mysql和postgresql生态，秒级弹性、高性能、海量存储、安全可靠的云原生数据库。

postgresql源码阅读（一）

这个代码片段的主要目的是在程序启动时进行一些特定平台的初始化，并保存原始的 argv[] 数组以便在设置进程标题时使用。以下是详细解析：

taosd基本使用

taos是一个开源的时序数据库，目前发展势头较好，走的开源路线。