需求
- 一个DDL需要多个事务，比如在线建分区；
- 性能问题；（发布性能较低，流式发布）
- 用户接口跟产品确认；（用户接口清单，ddl同步范围），table和others的清单列出；
- publication决定发布什么，subscription决定apply什么；
- 确认pg_replicate_ddl_command是否需要？是否有必要的使用场景？
- 并发DDL，影响的边界；（靠锁？参考pg truncate）
- 冲突处理（暂不处理，人工介入）
- 工具对异构数据库是怎么处理–》冲突自动处理策略
- 重点说明：核心机制是依赖对象名，不是靠oid？带来的问题说清楚。
- 性能：DDL和DML有一个依赖关系，DDL流式如何处理
- 潜在需求：apply DDL转换为在线DDL
- CSN快照 问题解决
- pg_publication字段是否可以复用？–》不可以–〉要做升级
- 字段名怎么命名参考现有字段。–》名字风格
- 滚动升级需要找升级对齐
- 备份恢复是否会有影响–〉是否拷贝新增的表
- 已有缺陷问题需要兼顾，用户层面的问题需要确认是否是需求？（历史TAPD）
- 定性能指标–》整体的逻辑复制的性能影响（对DML）
- 把others细分，比如增加all；
下面进行具体分析
跨事务DDL
复杂特性，暂不支持。
性能问题
之前反馈G100发布性能较低，可以考虑流式发布，将在设计文档中详细描述。
后续会量化性能指标，明确对整体的逻辑复制的性能影响（主要是DML）。
用户接口确认
与产品进一步确定核对，确认pg_replicate_ddl_command是否需要。
后期转测前会提供用户接口清单，ddl同步范围。
ddl的取值没有other选项，做具体的分类，包括able,function,type,tablespace,all等。
并发DDL
继续分析调研影响的边界；（靠锁？参考pg truncate），但本次需求不考虑实现，后续再迭代完善。
冲突处理
- 暂不处理，人工介入；
- 工具对异构数据库是怎么处理–》冲突自动处理策略
- 重点说明：核心机制是依赖对象名，不是靠oid所带来的问题；（待补充）
在线DDL
在线DDL属于复杂特性，暂不支持。
TPAD问题梳理
目前看没有有价值的需求问题，大部分为实现问题，待进一步确认。
主要考虑 CSN快照 问题解决。
滚动升级
待确认
备份恢复
待确认。
