PostgreSQL分区表并发更新报错：tuple已移至其他分区，重试是否安全？

错误本质 #

你遇到的ERROR: tuple to be locked was already moved to another partition due to concurrent update错误，是PostgreSQL分区表行移动场景下的典型并发冲突：当更新分区键（active字段）时，PostgreSQL需要将行从当前分区迁移到目标分区，若有其他并发事务先完成了该迁移，你的事务就会因找不到待锁定的原元组而报错。

重试的安全性判断 #

基础场景：无外部副作用时安全 #

从ACID原则出发，报错的事务会被完全回滚——包括事务内所有未提交的修改，以及触发器在事务内执行的操作，都不会留下持久化影响。这种情况下，重试操作是安全的，相当于重新执行一次未产生任何影响的操作。

风险场景：触发器存在非事务性副作用时不安全 #

如果你的触发器执行了事务边界外的操作（比如调用外部API、写入非事务性日志、发送消息队列），这类操作不会随事务回滚而撤销。此时重试会导致这些副作用重复执行（比如重复发送通知），这种场景下重试是不安全的。

实践建议 #

• 优化并发冲突根源：尽量避免高并发场景下更新分区键。如果业务允许，改用逻辑删除+定期归档的方式替代直接修改active字段，从根源减少冲突。
• 控制重试范围：若必须重试，先确认所有触发器仅包含事务性操作（无外部副作用）。优先在应用层实现重试：捕获错误码55006，限制重试次数（如3次），避免无限重试拖垮性能。库层面可通过PL/pgSQL函数封装更新逻辑并加入重试，但要确保每次重试都是独立事务。
• 版本升级优化：PostgreSQL 12.8属于旧版本，13+版本对分区表并发行移动做了针对性优化，能降低这类冲突概率，业务允许的话建议升级。

内容的提问来源于stack exchange，提问作者ilia.karelia