背景

1、产品的问题点

• PG 不支持online DDL

2、问题点背后涉及的技术原理

• DDL需要加排他锁, 堵塞所有与被锁对象相关的操作, 包括select.
• 当然, PG很多DDL操作不需要table rewrite, 只需要改元数据, 例如加字段, 某些改字段长度的操作(具体见alter table的语法手册).

3、这个问题将影响哪些行业以及业务场景

• 几乎所有行业, 当需要对大表执行DDL(例如发布变更), 而且这个DDL需要table rewrite时.

4、会导致什么问题?

• 当DDL需要table rewrite时. 那么需要长时间持有排他锁, 如果是个被频繁访问的表, 可能长时间影响业务, 甚至需要停业务来执行DDL.

5、业务上应该如何避免这个坑

• 几乎无解, 无法缩短业务影响时间
• 或者在业务设计的时候尽量避免未来发生table rewrite的结构变更, 如修改字段类型(导致底层存储内容发生变化时).
• 使用trigger, PG的继承功能实现, 非常复杂. 一般用户不懂.

6、业务上避免这个坑牺牲了什么, 会引入什么新的问题

• 管理复杂度增加

7、数据库未来产品迭代如何修复这个坑

• PG有个插件pg_repack, 在线垃圾回收, 只短暂的加排他锁, 切换数据文件filenode. 可借鉴类似思想, 实现需要table rewrite的DDL的短暂加排他锁, 而不是整个过程加排他锁.