PostgreSQL为角色设置statement_timeout后配置不生效问题咨询

你遇到的现象不是ALTER ROLE的配置没有持久化，而是完全踩中了PostgreSQL配置加载机制的设计边界，具体问题可以拆成几点：

• 配置生效的触发时机有明确边界
  ALTER ROLE <角色> SET <参数>的配置本身会立刻持久化存储在系统表中，它的自动加载流程只发生在该角色直接作为登录身份、建立全新数据库连接的初始鉴权阶段。
• 临时切换角色的操作不会触发参数重载
  你当前的操作流程是：先以其他身份（比如超级管理员、其他业务账号）建立数据库连接，再在事务中通过SET ROLE api_user临时切换当前会话的权限身份。这类会话中途的角色切换，仅会修改当前会话的权限校验逻辑，不会重新读取api_user账号绑定的自定义配置参数，因此会话里的statement_timeout还是你初始登录时继承的全局默认值（示例中的0）。
• 容易忽略的前提校验
  如果api_user本身没有被授予LOGIN权限，它就只是一个纯权限组角色，永远不可能作为初始登录身份建立连接，哪怕给它配置了自定义参数，也永远不会触发自动加载流程。
• 常见认知误区
  很多人会误以为SET ROLE会完全模拟该角色的所有会话初始配置，但实际该语句仅做权限上下文切换，不会重置或重载关联角色的自定义GUC参数。

• 验证配置持久化效果：完全断开当前数据库连接，再以api_user的账号凭证重新建立新连接，此时执行show statement_timeout就会看到预期的500ms结果。
• 已建立会话中临时切角色的场景：如果确实需要在现有连接里临时切换到api_user身份时应用对应的超时限制，需要在SET ROLE操作完成后手动执行参数设置：

begin;
    set role api_user;
    -- 手动应用目标配置
    set statement_timeout = '500ms';
    show statement_timeout; -- 输出 500ms

额外说明：不存在“执行完ALTER ROLE需要手动重载配置、需要提交事务才会生效”的问题，这类DDL语句执行后配置立刻持久化，不需要额外操作。

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