Electric-SQL 项目中表删除时自动清理关联形状的技术方案

在 Electric-SQL 项目中，当用户从 PostgreSQL 数据库中删除表时，目前需要手动删除与该表关联的所有形状(shape)定义。这一操作若不及时执行，可能导致数据一致性问题——例如当用户重新创建同名表但使用不同结构时，Electric 仍保留着旧表的过时数据。

当前技术背景

Electric-SQL 通过订阅 PostgreSQL 的发布(publiation)来获取表数据变更(DML)。然而，PostgreSQL 的逻辑复制机制存在一个关键限制：它不会传输 DDL 语句(如表删除操作)。这使得 Electric 无法直接感知表结构变更事件。

现有解决方案分析

项目团队曾考虑过几种技术方案：

1. 事件触发器方案：通过 PostgreSQL 的事件触发器(event trigger)在表删除时调用特殊函数，向元数据表写入记录，从而通过复制流通知 Electric。这一方案虽然优雅，但存在权限限制——事件触发器需要超级用户权限，且不适用于单用户模式(如 PGlite)。

2. 用户定义函数方案：提供专用函数供用户在迁移脚本中显式调用，主动通知 Electric 表删除事件。这一方案依赖用户自觉调用，无法完全自动化。

3. 表标识符验证方案：利用 PostgreSQL 内部的对象标识符(OID)进行验证。当复制流中传递 Relation 消息时，包含表的 OID 信息。然而，这一方案存在局限性——仅当表发生变更时才会发送 Relation 消息，无法及时检测静态表的删除。

深入技术探讨

PostgreSQL 的逻辑复制机制中，Relation 消息仅在需要解释后续数据变更时才会发送。这意味着：

• 删除表后，除非重建并插入数据，否则不会发送新的 Relation 消息
• 重建同名表会分配新的 OID，但 Electric 可能继续使用旧的缓存映射
• 存在一段时间的数据不一致窗口期

创新解决方案

基于上述分析，项目团队提出了更完善的解决方案：

1. 主动健康检查机制：为形状设置"心跳"检测，定期验证底层表是否存在且 OID 匹配。通过批处理方式优化性能，避免对数据库造成突发负载。

2. 自动回收机制：对长期未更新的形状实施渐进式回收策略。结合配置参数，允许用户根据业务需求调整回收策略的激进程度。

3. 多维度验证：在初始同步和复制流处理时均进行表标识验证，建立防御性编程模式。

实现考量

在实际实现中需要特别注意：

• 性能与实时性的平衡：过于频繁的健康检查会影响系统吞吐量
• 边缘情况处理：表重建、重命名等复杂场景
• 权限管理：在受限环境中确保功能可用性
• 用户体验：提供清晰的错误提示和恢复路径

这一技术演进将显著提升 Electric-SQL 在动态数据库环境中的可靠性，为开发者提供更无缝的使用体验。