不能直接拦住存储过程里的纯PL/pgSQL死循环，statement_timeout仅对执行SQL语句（如SELECT/INSERT/UPDATE/DELETE）阶段生效；纯计算逻辑（如WHILE true LOOP+赋值）不触发超时，需靠代码修复或pg_terminate_backend强制终止。
statement_timeout 能拦住存储过程里的死循环吗？
不能直接拦住。只要循环体里没有 SQL 语句（比如纯 PL/pgSQL 的 WHILE true LOOP ... END LOOP），statement_timeout 就不会触发。它只对「执行 SQL 语句」的阶段起作用，而 PL/pgSQL 的循环控制本身不消耗查询时间片。
哪些场景下 statement_timeout 会生效
它只在存储过程中包含可中断的 SQL 操作时才可能中断执行，比如：
-
SELECT、INSERT、UPDATE、DELETE等语句执行超时 - 递归 CTE 中每一轮
UNION ALL子查询耗时叠加后超限 - 游标
FETCH或隐式遍历时，底层查询被判定超时
但注意：如果死循环写在 LOOP 里且内部只有赋值、RAISE NOTICE、CONTINUE 这类纯计算逻辑，statement_timeout 完全无效。
真正能打断纯循环的配置是哪些
必须靠更底层的中断机制：
-
idle_in_transaction_session_timeout：只管空闲事务，不适用 -
lock_timeout：只在等锁时生效，和循环无关 -
tcp_keepalives_idle等网络参数：断连后会终止会话，但非即时、不可控 - 唯一可靠手段是
pg_terminate_backend(pid)—— 但前提是进程没卡死在 C 函数里（如缺失CHECK_FOR_INTERRUPTS()）
如果你写了自定义 C 函数并在里面用 while(1)，连 pg_terminate_backend 都可能失效，只能 kill -9 进程。
实际建议：别依赖 timeout，改代码逻辑
死循环几乎总是设计缺陷，而不是配置问题。重点检查：
- 递归 CTE 是否漏了
CYCLE子句，或没加MAX_RECURSION_DEPTH（PostgreSQL 15+ 支持） - 显式游标是否漏了
EXIT WHEN NOT FOUND - WHILE 循环是否用了恒真条件，且未在循环体内更新判断变量
- 是否误把
IF condition THEN ... END IF写成IF condition THEN ... END IF后少了个EXIT，导致本该跳出的逻辑继续循环
最易被忽略的是：递归查询中数据闭环（比如 (1,1) 自指）和 PL/pgSQL 里忘记在循环末尾修改循环变量 —— 这两类错误，statement_timeout 根本救不了。
