逻辑复制发布端现状

逻辑复制发布端解码运行在一个叫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)

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/),从内核视角讲清楚共享内存是怎么回事 —— 为什么需要它、它分几层、内核开发者怎么用它。

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（物理日志）中的数据修改恢复成“逻辑级别”的变更事件：

postgresql源码阅读（一）

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

taosd基本使用

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