AWS Redshift存储过程处理异常后提前退出，如何排查？

你的存储过程在Step1的异常处理后直接退出，核心原因是异常处理块内部的dummy_error_log调用抛出了未被捕获的异常，导致异常传播到主过程层面，触发整个存储过程终止。

具体原因 #

当Step1的INSERT触发NOT NULL约束异常后，进入对应的EXCEPTION块，此时如果调用dummy_error_log时出现错误（比如存储过程不存在、参数类型不匹配、内部逻辑报错），这个新的异常会跳出当前的EXCEPTION块，而主过程没有外层异常处理，因此整个存储过程直接停止，不会执行后续的Step2。

从你给出的错误信息来看，虽然显示的是INSERT的NULL错误，但实际导致过程退出的是后续日志调用的未处理异常。

解决步骤 #

1. 验证dummy_error_log的有效性 #

先确认这个存储过程存在，且参数定义与调用匹配：

• 检查dummy_error_log的参数是否为(BIGINT, VARCHAR, VARCHAR)，和你调用时传入的v_load_id(BIGINT)、SQLSTATE(VARCHAR)、SQLERRM(VARCHAR)类型一致。
• 手动调用dummy_error_log(1, '23502', 'Cannot insert a NULL value into column process')，测试是否能正常执行，无报错。

2. 给日志调用添加独立异常处理 #

在Step1的EXCEPTION块内，给dummy_error_log的调用套一层BEGIN...EXCEPTION，避免其异常传播：

EXCEPTION WHEN OTHERS THEN
  RAISE INFO 'Step 1 error caught: %', SQLERRM;
  -- 为日志调用添加异常捕获
  BEGIN
    CALL dummy_error_log(v_load_id, SQLSTATE, SQLERRM);
  EXCEPTION WHEN OTHERS THEN
    RAISE INFO 'Failed to log Step1 error: %', SQLERRM;
  END;

3. 临时排查测试 #

先注释掉CALL dummy_error_log(...)这一行，重新执行sp_dummy_etl()，如果此时能正常输出Continuing to Step 2并执行Step2，就可以100%确认是日志过程的调用导致了过程终止。

补充建议 #

所有在EXCEPTION块内的外部调用（比如日志存储过程）都应该加上独立的异常处理，避免因为日志操作失败导致整个ETL流程中断。

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