Actian/Pervasive PSQL Zen 13.30 随机触发error 46只读锁求助

Error 46在官方文档里归类为权限类错误，但稳定运行10年的环境无诱因出现该报错、且伴随表级只读锁无法自动释放的场景，基本不属于静态权限配置错误，按以下优先级排查处理即可：

根因定位排查（优先做，避免反复治标） #

• 核查客户端驱动一致性：老PSQL环境最常见的触发原因是近期个别客户端因系统补丁更新、软件重装，替换了和服务端小版本不一致的PSQL客户端驱动，驱动版本不匹配时，事务提交/回滚流程会异常，残留无法自动释放的表级只读锁。开启服务端PSQL Monitor的连接审计，每次锁触发时定位第一个持有锁的连接，核对对应客户端的驱动版本，将所有客户端驱动统一替换为和服务端完全匹配的版本，替换后重启客户端侧的PSQL客户端服务即可。
• 排查文件系统锁冲突：如果数据文件存放在SMB共享、分布式存储卷上，近期存储侧杀毒扫描策略更新、文件锁机制调整，会直接把PSQL正在写入的.ddf/.mkd数据文件标记为系统层面只读，PSQL检测到文件状态变化就会抛出Error 46。将PSQL的数据目录、事务日志目录全路径加入杀毒软件实时扫描排除项，核心业务表数据不要放在SMB 3.0以下版本的共享存储上，这类存储本身不兼容PSQL的字节范围锁机制，长期运行必然出现锁残留。
• 校验表数据完整性：运行10年以上的核心表如果长期未做维护，存在页损坏、索引断裂问题时，PSQL存储引擎写入损坏页失败会自动触发表级只读保护锁，避免数据进一步损坏。不要手动删表重建，业务低峰期先对所有核心表执行butil -recover做完整性校验，校验不通过的表执行butil -rebuild完成在线重建，操作前务必做好全量冷备。

应急处理方案（无需重启服务器） #

• 出现锁阻塞时不要直接重启服务或服务器，打开PSQL Monitor定位持有异常只读锁的连接ID，执行kill connection <连接ID>即可单独释放异常锁，不会影响其他正常连接的业务操作。
• 如果控制台杀连接后锁仍未释放，先停止PSQL事务引擎服务，删除数据目录下后缀为.lck的残留锁文件，再启动服务即可，整个过程业务中断时间可控制在1分钟内。

根治复发的配置调整 #

• 修改PSQL引擎锁参数：将Transaction Wait Lock Timeout从默认的无限等待调整为30秒，异常锁不会长期阻塞后续请求，避免出现全用户阻塞的多米诺效应。
• 核查应用连接串配置：检查所有业务端的PSQL连接串，去掉非只读查询账号下的ReadOnly=1参数，这类配置在客户端异常断连时极容易残留只读锁。
• 建立定期维护机制：每月业务低峰期对高频更新的核心表执行butil -stat检查碎片率，碎片率超过30%时执行一次rebuild操作，避免页损坏触发保护锁。

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