PL/pgSQL更新同一行触发max_stack_depth超限问题排查

嘿，我来帮你拆解这个问题的核心——你遇到的max_stack_depth报错，本质是触发器无限递归调用导致的！咱们一步步理清楚：

问题根源分析 #

你的触发器是AFTER UPDATE类型，意思是当对support_fh表完成更新操作后，才会触发maj_diam()函数。但函数里又执行了update support_fh set diametre = '12.2' where id = new.id;——这相当于又对同一张表发起了一次更新，会再次触发同一个AFTER UPDATE触发器。循环往复，PostgreSQL的调用栈被不断填满，最终触发栈深度超限的报错。

另外，你的函数里还有两个额外的问题：

• 完全没必要重新查询表获取fabricant、section等值：触发器函数中的NEW变量已经包含了更新后的行数据，直接调用即可。
• 存在拼写错误：Select capcite into capa_loc里的capcite应该是capacite，这会导致你的条件判断永远不生效。

修正后的实现方案 #

我们可以通过两个关键调整解决问题：

1. 将触发器改为BEFORE UPDATE类型，直接修改NEW变量的字段值，避免额外的UPDATE操作
2. 简化函数逻辑，直接使用NEW变量获取字段值

修正后的触发器函数 #

create or replace function maj_diam() returns trigger as $$
BEGIN
    -- 直接使用NEW变量获取更新后的字段值，无需重复查询表
    IF NEW.fabricant = 'NEXANS' 
       AND NEW.section = 'DISTRIBUTION' 
       AND NEW.capacite = '12' 
       AND NEW.modulo = '6' THEN
        NEW.diametre := '12.2';  -- 直接修改NEW对象的字段，触发器会自动将其应用到行上
    END IF;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

修正后的触发器 #

CREATE TRIGGER maj_diam 
BEFORE UPDATE ON support_fh 
FOR EACH ROW 
EXECUTE PROCEDURE maj_diam();

为什么这样改能解决问题？ #

• BEFORE UPDATE触发器在实际写入数据到表之前触发，你修改NEW变量的字段后，PostgreSQL会把修改后的NEW作为最终的更新值直接写入表，不需要额外执行UPDATE语句，从根源上避免了递归触发。
• 直接使用NEW变量省去了不必要的表查询，既提升了性能，也减少了出错的可能性。

你的思维盲区总结 #

1. 没有意识到AFTER UPDATE触发器内执行同表UPDATE会触发递归调用，最终导致栈溢出。
2. 忽略了触发器函数中NEW/OLD变量的核心作用——它们已经包含了当前行的新旧数据，无需重复查询表。
3. 代码中的拼写错误（capcite）会导致条件判断失效，这也是日常开发中容易忽略的细节。

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