postgresql原生逻辑复制不支持ddl同步，需通过事件触发器捕获ddl_command_end事件并写入专用表，再由外部工具按id顺序消费，确保与dml时序一致且防循环。
PostgreSQL 原生逻辑复制不支持 DDL 同步，但能通过触发器补足这一缺口——关键不是用触发器替代逻辑复制，而是让它捕获 DDL 变更并写入一张普通表，再由同步工具（如 CloudCanal）或自定义消费者统一拉取。
为什么不能直接用触发器做全量数据同步
触发器在每条 INSERT/UPDATE/DELETE 上执行，会显著拖慢写性能；且无法保证事务内 DML 与 DDL 的全局顺序一致性。逻辑复制本身已高效处理 DML 流，触发器只应聚焦它缺失的部分：DDL。
-
CREATE TABLE、ALTER TABLE ADD COLUMN、DROP INDEX等操作不会进入逻辑复制流 - 原生
pg_event_trigger只能在数据库级监听，必须配合函数 + 表记录才能被外部消费 - 若在目标库也启用相同触发器，不加防循环机制会导致无限递归同步
如何创建 DDL 捕获触发器（PostgreSQL 11+）
需在源库创建事件触发器（event trigger），监听 ddl_command_end 事件，并将语句文本写入一张专用表（如 cc_pg_ddl_capture_tab 或 hwdrs_ddl_info）。
- 确保用户有
EVENT TRIGGER权限：GRANT EVENT TRIGGER ON DATABASE mydb TO rep_user; - 建表时主键用
bigserial，避免高并发下 ID 冲突：CREATE TABLE cc_pg_ddl_capture_tab (id bigserial PRIMARY KEY, ddl text, ts timestamptz DEFAULT now()); - 触发器函数中用
pg_event_trigger_ddl_commands()提取标准化 SQL，而非TG_TAG（它只返回命令类型，如CREATE TABLE） - 不要在触发器里执行远程写或网络调用，只做本地 insert，否则事务阻塞风险极高
订阅端如何安全消费 DDL 表
逻辑复制订阅本身不拉取这张 DDL 表——你得单独配置一个「普通表订阅」或用外部工具轮询它。重点是顺序和幂等。
- DDL 表必须和业务表在同一个数据库、同一事务中写入（例如在触发器里显式
INSERT INTO ...; COMMIT;不行，必须依赖外层事务） - 消费程序需按
id升序读取，且每条 DDL 执行前先检查目标库是否已存在对应对象（如SELECT 1 FROM pg_tables WHERE tablename = 'xxx'） - 遇到
ALTER TABLE RENAME TO时，后续对该表的 DML 可能因名字变更而失败，需提前缓存旧名→新名映射 - 云 RDS（如阿里云、腾讯云）可能禁用
pg_event_trigger，此时只能改用日志解析或数据库代理层拦截
防循环与多活场景下的陷阱
双向同步时，如果 A→B 和 B→A 都部署了相同 DDL 触发器，CREATE INDEX 会被反复传播。必须加隔离层。
- 在 DDL 表中增加标记字段：
source_node text，插入时写入本机标识（如'node_a'） - 消费端只执行
source_node != current_node的记录，避免自产自销 - 逻辑复制的
publication不能包含 DDL 捕获表本身，否则触发器插入会再次触发——发布列表必须显式排除该表 - PostgreSQL 15+ 支持
REPLICA IDENTITY FULL对无主键表，但 DDL 表必须有主键，否则逻辑复制 slot 无法定位变更位置
真正难的不是写触发器，而是让 DDL 变更和它所影响的 DML 在跨库场景下保持严格时序——这要求触发器、逻辑复制 slot、消费程序三者对 WAL 位点的理解完全一致。任何一环用错 pg_logical_slot_get_changes 的参数或忽略 commit_lsn，都会导致 DDL 执行早于或晚于关联表数据到达。
