Postgres FDW更新遇could not serialize access并发更新报错

问题说明 #

该问题和常规PostgreSQL本地表的并发更新序列化报错场景类似，但受FDW自身实现机制限制，本地表的通用解决方案无法直接套用。
执行如下更新SQL时，系统抛出序列化访问错误：

update fdw_table set last_new_data=clock_timestamp() where fn_name='something' and id=1234

根据postgres_fdw官方文档的机制说明，问题根源是FDW建立远端连接时采用的事务隔离级别无法手动单独修改，规则比本地表更严格。
曾尝试使用带行锁的SQL规避问题，语句如下：

update fdw_table set last_new_data=clock_timestamp() 
where fn_name='something' and id=( 
     select id from fdw_table
     where fn_name='something' and id=1234
     FOR UPDATE SKIP LOCKED 
);

执行后依然抛出相同错误。

可行解决方法 #

• 调整本地会话事务隔离级别后再执行操作
  FDW的远端事务隔离级别会和本地事务保持一致，如果你当前本地事务是可重复读（Repeatable Read）或可序列化（Serializable）级别，远端的行版本并发校验会非常容易触发序列化错误。执行更新前先运行SET LOCAL transaction_isolation = 'read committed';，将当前事务隔离级别调整为读已提交，再执行更新语句，可规避绝大多数并发场景下的报错。
• 移除FDW层面的行锁逻辑，改用异常重试机制
  之前写的FOR UPDATE SKIP LOCKED不生效的核心原因是：FDW的行锁申请发生在远端数据库节点，本地事务的锁状态判定和远端存在天然时序差，无法像本地表一样靠行锁完全避免冲突。这类报错属于FDW跨节点事务的正常偶发冲突，不需要设计复杂的锁逻辑，只需要在应用层捕获该异常，间隔10~50ms重试更新即可，重试成功率接近100%。
• 高并发场景下将更新逻辑下沉到远端执行
  如果该更新语句的调用频率很高、并发量大，可以直接把更新逻辑放到FDW映射的远端数据库执行，通过dblink或者远端函数调用的方式触发更新，完全规避跨节点事务的隔离级别一致性校验，示例调用逻辑：

  -- 先配置好远端连接映射，直接在远端执行更新
  SELECT dblink_exec('remote_server_conn', 
    'update target_table set last_new_data=clock_timestamp() where fn_name=''something'' and id=1234'
  );
  

注意：不要尝试通过修改FDW内部参数强行调整远端事务隔离级别，这类参数是FDW建立连接时根据本地事务状态自动适配的，手动修改会引发数据一致性风险。

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