如何在Amazon Redshift中模拟Serializable隔离违例错误并排查存储过程问题

触发该错误的核心条件 #

Serializable是Redshift最严格的隔离级别，要求事务执行结果和串行执行完全一致。触发101841错误的核心是事务间形成循环依赖链：

• 两个或多个Serializable级别的事务，对同一组资源（比如incremental_table的行）执行交叉读写操作：比如事务A先读行X再更新行Y，事务B先读行Y再更新行X，此时两者形成互相等待的循环
• 这类错误具有间歇性，只有当交叉操作的时序刚好命中循环检测条件时才会触发，Redshift会终止其中一个事务来打破循环

手动触发违例的测试方法 #

完全可以在受控环境中手动模拟，步骤如下：

1. 先准备测试表（可用测试环境的incremental_table，或新建模拟表）：

   CREATE TABLE IF NOT EXISTS test_incremental (id INT PRIMARY KEY, value INT);
   INSERT INTO test_incremental VALUES (1, 10), (2, 20);
   

2. 打开两个Redshift客户端会话（比如两个psql窗口），都设置Serializable隔离级别并开启事务：

   SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
   BEGIN;
   

3. 按以下时序执行操作：
   • 会话1：读取行1 SELECT * FROM test_incremental WHERE id=1;
   • 会话2：读取行2 SELECT * FROM test_incremental WHERE id=2;
   • 会话1：尝试更新行2 UPDATE test_incremental SET value=21 WHERE id=2;（此时会进入等待状态）
   • 会话2：尝试更新行1 UPDATE test_incremental SET value=11 WHERE id=1;
     此时其中一个会话会立刻抛出你遇到的Serializable isolation violation on table - [表ID], transactions forming the cycle are错误

处理此类错误的最佳实践 #

• 重试机制：这类错误是时序性的，不是逻辑错误，捕获后自动重试是最直接的解决方案。在存储过程中可以用异常块实现：

  CREATE OR REPLACE PROCEDURE update_incremental()
  LANGUAGE plpgsql
  AS $$
  DECLARE
    retry_count INT := 0;
    max_retries INT := 3;
  BEGIN
    WHILE retry_count < max_retries LOOP
      BEGIN
        SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
        BEGIN TRANSACTION;
        -- 替换为你的UPDATE业务逻辑
        UPDATE incremental_table SET value = value + 1 WHERE id > 0;
        COMMIT;
        EXIT;
      EXCEPTION
        WHEN OTHERS THEN
          IF SQLERRM LIKE '%Serializable isolation violation%' THEN
            ROLLBACK;
            retry_count := retry_count + 1;
            -- 可选：加短暂延迟避免立即重试再次冲突
            PERFORM pg_sleep(1);
          ELSE
            -- 非序列化违例的错误直接抛出
            RAISE;
          END IF;
      END;
    END LOOP;
    IF retry_count >= max_retries THEN
      RAISE EXCEPTION 'Failed after % retries due to serializable violation', max_retries;
    END IF;
  END;
  $$;
  

• 调整隔离级别：如果业务不需要严格的Serializable一致性，降级到REPEATABLE READ可以彻底避免这类错误，同时能满足大部分业务的一致性需求，还能提升事务性能
• 优化事务逻辑：
  • 缩小事务范围，尽量减少事务持有锁的时间
  • 统一更新操作的访问顺序：比如所有事务都按id从小到大的顺序更新行，从根源上避免循环依赖
  • 批量更新时拆分小批次，减少单次事务影响的行数

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