ElectricSQL中关于生成列与连接管理器崩溃问题的技术解析

问题背景

在ElectricSQL数据库同步系统中，用户在使用PostgreSQL的生成列(GENERATED ALWAYS AS)功能时遇到了连接管理器(Connection.Manager)进程崩溃的问题。该问题发生在表结构变更后，特别是当表包含生成列时，ElectricSQL的同步机制会出现异常。

技术细节分析

生成列的特性

PostgreSQL的生成列是一种特殊类型的列，其值由表中其他列的值计算得出。在用户案例中，表TrashItemPb包含多个生成列：

• id列由pbjson字段中的id值转换而来
• description列直接取自pbjson中的description字段
• picture列将pbjson中的picture字符串转换为BYTEA类型
• ts列通过自定义函数rfc3339_to_tz转换时间格式

问题根源

当表结构发生变更时，特别是生成列被修改或重建时，ElectricSQL的连接管理器进程会出现以下问题：

1. 进程会因架构变更而崩溃
2. 崩溃会触发监控系统(Monitoring System)的重启机制
3. 当重启次数超过限制时，整个连接管理器进程将终止

深层原因

问题的根本原因在于PostgreSQL的WAL(Write-Ahead Logging)机制对生成列的特殊处理：

• 生成列的更新不会写入WAL日志
• ElectricSQL依赖WAL日志进行数据同步
• 当生成列的值发生变化时，这些变化无法被ElectricSQL捕获
• 这导致客户端和服务器之间的数据状态不一致

解决方案

ElectricSQL团队在版本1.0.4中通过以下方式解决了这个问题：

1. 明确禁止在同步范围(shape)中包含生成列
2. 当检测到生成列时返回明确的错误信息而非崩溃
3. 在架构验证阶段就拒绝包含生成列的同步请求

最佳实践建议

对于需要使用类似功能的开发者，建议：

1. 避免在需要同步的表上使用生成列
2. 如需类似功能，可以考虑：
   • 使用触发器维护派生数据
   • 在应用层实现计算逻辑
   • 使用视图而非生成列
3. 在表结构设计阶段就考虑数据同步需求

总结

这个问题展示了数据库同步系统中一个典型的设计挑战：如何处理数据库原生特性与同步机制之间的兼容性。ElectricSQL通过明确限制而非隐式崩溃的方式，既解决了稳定性问题，又为用户提供了清晰的指导。这种处理方式体现了成熟系统的设计哲学：宁可明确拒绝，也不隐式失败。