PostgreSQL中set statement_timeout=0;执行后无效果的原因

以下是几种可能导致该现象的具体场景及验证方式：

• 混淆psql客户端变量与SQL服务器参数
  若你在psql中误执行了客户端命令\set statement_timeout 0，这仅会设置psql本地变量，完全不会影响PostgreSQL服务器的会话参数。此时执行show statement_timeout;仍会返回服务器端的原始配置值。
  验证与修正：确保执行的是SQL命令SET statement_timeout = 0;（注意末尾的分号，psql依赖分号确认执行SQL语句）；可通过\echo :statement_timeout查看psql客户端变量，对比show statement_timeout;的结果区分两者。

• 用户/数据库级默认参数的特殊配置
  若管理员通过ALTER USER myuser SET statement_timeout = '30min';或ALTER DATABASE mydatabase SET statement_timeout = '30min';设置了默认参数，且服务器启用了参数强制锁定（极端场景），会导致会话级SET无法覆盖。
  验证方法：执行以下SQL检查用户和数据库的默认配置：

  SELECT usename, useconfig FROM pg_user WHERE usename = 'myuser';
  SELECT datname, datconfig FROM pg_database WHERE datname = 'mydatabase';
  

• 事务回滚导致SET效果被撤销
  若你的SET语句是在BEGIN启动的事务块内执行，后续又执行了ROLLBACK，事务内的参数修改会被完全回滚，参数恢复到事务前的状态。例如：

  BEGIN;
  SET statement_timeout = 0;
  ROLLBACK; -- 此操作会撤销SET的修改
  SHOW statement_timeout; -- 仍返回30min
  

  验证方法：执行SHOW transaction_status;查看当前是否处于事务中，确保SET在事务外执行。

• 连接字符串强制指定了参数
  若你的psql连接字符串包含options='-c statement_timeout=1800000'（1800000毫秒=30分钟），该参数会在会话启动时被强制加载。部分特殊服务器配置下，会话级SET可能无法覆盖此初始设置。
  验证方法：修改连接字符串，移除该options参数后重新连接重试。

• psql自动执行脚本覆盖设置
  若你存在~/.psqlrc（Linux/macOS）或%APPDATA%\postgresql\psqlrc.conf（Windows）配置文件，且其中包含设置statement_timeout的命令，每次连接或特定操作后，脚本会自动执行覆盖手动设置。
  验证方法：临时重命名psqlrc文件，重新连接后执行SET和show命令验证。

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