PostgreSQL 13配置statement_timeout为0仍出现90秒超时的原因

以下是几个常见的排查点，帮你定位问题根源：

• 会话/事务级临时设置覆盖
  即使用户全局没设超时，当前会话或事务可能被临时修改了参数。执行SHOW statement_timeout;查看当前会话的实际生效值；也可以查pg_stat_activity视图，看对应会话的current_query里有没有SET statement_timeout相关语句。

• 数据库/模式级参数优先级更高
  PostgreSQL的参数可以在多个层级设置，数据库级的配置会覆盖全局配置。执行以下SQL检查数据库层面的设置：

  SELECT name, setting, source FROM pg_settings WHERE name = 'statement_timeout';
  

  如果结果里source显示为database且setting是90000（即90秒），说明数据库单独配置了超时。

• 连接池或应用端强制设置
  很多连接池工具（如PgBouncer）、应用的数据库驱动会在建立连接时自动注入超时配置。比如某些Java驱动、Python的psycopg2可能自带默认超时，或者连接池的初始化脚本里包含了SET statement_timeout = '90s'，需要检查应用代码或连接池的配置文件。

• 第三方扩展/运维工具干预
  监控、审计类的PostgreSQL扩展，或者运维脚本可能会批量修改会话参数。比如有些DBA工具在连接数据库后，会自动为会话设置超时策略，排查这类工具的运行记录或扩展配置。

• 配置文件未实际生效
  先确认当前实例加载的配置文件路径：SHOW config_file;，对比路径下的文件内容是否和截图一致。另外，修改配置后如果没执行SELECT pg_reload_conf();或重启实例，旧配置可能仍在生效。

• 混淆了超时类型
  90秒超时可能不是statement_timeout，而是其他超时参数触发的，比如：

  • idle_in_transaction_session_timeout：事务空闲超时
  • lock_timeout：锁等待超时
    查看数据库错误日志，错误信息里会明确标注是哪种超时导致的，比如ERROR: canceling statement due to statement timeout或ERROR: canceling statement due to lock timeout。

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