使用pg_repack遇更新报错：表无副本标识且已发布更新

针对你遇到的pg_repack因表无replica identity、且发布为FOR ALL TABLES无法排除临时表的问题，提供以下几个可行方案：

方案1：临时转换发布为指定表模式 #

这是风险较低的常规操作，适合大多数场景：

1. 先导出当前所有非repack模式的表清单，生成添加到临时发布的SQL：

   SELECT 'ALTER PUBLICATION temp_pub ADD TABLE ' || schemaname || '.' || tablename || ';'
   FROM pg_tables
   WHERE schemaname != 'repack' AND tablename NOT LIKE 'repack_%';
   

2. 创建临时发布temp_pub，执行上面生成的所有SQL，确保它包含原发布的所有业务表。
3. 修改原发布dbzm_postgres，取消全量表配置：

   ALTER PUBLICATION dbzm_postgres DROP ALL TABLES;
   ALTER PUBLICATION dbzm_postgres SET (publish = 'insert, update, delete');
   

4. 把之前导出的业务表重新添加回原发布：

   -- 执行类似如下的语句，替换为实际表名
   ALTER PUBLICATION dbzm_postgres ADD TABLE public.table_1;
   ALTER PUBLICATION dbzm_postgres ADD TABLE public.table_2;
   

5. 此时执行pg_repack，其创建的临时表不会被原发布包含，可正常完成操作。
6. 完成后将原发布改回全量模式：

   ALTER PUBLICATION dbzm_postgres ADD ALL TABLES;
   

注意：操作需在业务低峰期进行，期间避免创建新表，否则新表会被遗漏在发布外；备库会有短暂同步延迟，需提前评估影响。

方案2：用pg_repack的--exclude-schema参数跳过repack模式 #

如果你的pg_repack版本≥1.4，可直接在调用时排除repack模式，避免临时表被发布捕获：

pg_repack --exclude-schema=repack -d your_database_name -t table_123

原理：让pg_repack生成的临时表所在的repack模式不被全量发布包含，绕过replica identity的校验。

方案3：临时限制发布仅同步INSERT操作（极端场景） #

若业务允许短暂的更新/删除同步中断，可临时修改发布的同步类型：

1. 修改发布仅同步INSERT：

   ALTER PUBLICATION dbzm_postgres SET (publish = 'insert');
   

2. 执行pg_repack，此时UPDATE操作不会触发复制层面的replica identity校验。
3. 完成后恢复原同步配置：

   ALTER PUBLICATION dbzm_postgres SET (publish = 'insert, update, delete');
   

警告：此操作会导致操作期间备库无法获取更新和删除数据，仅适用于对数据一致性要求不高的场景，操作前务必备份数据。

方案4：使用--no-order参数跳过UPDATE步骤 #

如果目标表有唯一索引（无主键），可尝试用--no-order参数让pg_repack用COPY方式迁移数据，避免UPDATE操作：

pg_repack --no-order -d your_database_name -t table_123

原理：跳过pg_repack的UPDATE阶段，直接用COPY将数据迁移到新表，绕过replica identity的校验，但需确保操作期间没有并发写入，否则可能导致数据丢失。

内容的提问来源于stack exchange，提问作者MANJULA KURAPATI