PostgreSQL 终于有密码过期预警了, 虽然来得有点迟

本期播客

PostgreSQL 终于有密码过期报警了, 虽然来得有点迟

在企业级数据库的安防阵地上，PostgreSQL（以下简称 PG）一直是个“偏科生”：它能处理最复杂的 SQL，支持最先进的向量检索，但在某些基础的合规性细节上，却倔强得像个上个世纪的极客。

就在 2026 年 2 月，PG 社区终于合并了一项让无数企业级 DBA 泪流满面的提交：正式引入密码过期预警机制（Password Expiration Warnings）。

通过新增的 password_expiration_warning_threshold 参数，PG 终于学会了在密码失效前“温柔地叮嘱”用户。虽然这比 Oracle 和 SQL Server 晚了十几年，但它的意义绝不仅仅是加个闹钟。

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=1d92e0c2cc4789255c630d8776bbe85ca9ebc27f

一、 痛点：被“突然死亡”支配的生产事故

在没有这个功能之前，PG 的密码管理逻辑极其冷酷。

• 现状： 如果你设置了 VALID UNTIL，到了时间点，数据库会瞬间拒绝所有连接。
• 后果： 没有任何缓冲，没有任何通知。昨天还跑得好好的业务，今天早上可能因为一个定时任务的账号过期，导致全线崩溃。
• DBA 的无奈： 为了防止这种“硬着陆”，DBA 往往需要手写复杂的外部监控脚本，定期扫描 pg_authid 系统表，然后再通过邮件或钉钉报警。

这正是企业级应用中的一个“低级杀手”：因为缺乏原生预警，导致合规性配置（定期更换密码）反而成了系统可用性的最大威胁。

二、 技术剖析：不只是报警，更是“基础设施”的进化

此次更新的核心在于引入了 password_expiration_warning_threshold（默认 7 天）。当用户通过密码认证成功后，如果距离过期时间低于阈值，服务器会主动抛出一个“Connection Warning”。

1. 架构级的战略伏笔

这不仅仅是改了几个判断逻辑。Commit 明确提到：此补丁引入了一套全新的“连接预警（Connection Warning）”基础设施。

• 第一性原理： 数据库与客户端的通信协议应该是具备“前瞻性反馈”的。
• 后续扩展： 这套机制未来将用于 MD5 密码淘汰预警、陈旧协议警告等。这意味着 PG 开始重视 “平滑演进” ，而不是暴力地断开连接。

2. 跨版本迁移的“安全垫”

在合规要求极高的金融或医疗行业，账号必须每 90 天更换一次密码。原生预警的加入，让客户端驱动（如 JDBC, psycopg2）能够捕获到这个 Warning 并透传给应用层，从而实现在业务不停机的情况下提醒用户修改密码。

三、 权威案例：合规性带来的“隐形损失”

为什么这个“迟到”的功能如此重要？看数据就知道。

权威数据： 根据《数据安全等级保护（等保 2.0）》要求，三级系统必须具备身份鉴别信息定期更换机制。
案例支撑： 某大型国有银行在从 Oracle 迁移至 PG 早期，曾因某核心中间件账号密码过期且无预警，导致该网点业务中断 40 分钟。复盘结论显示：非技术性故障（如配置过期）在数据库停机诱因中占比高达 15%。

由于 PG 长期缺失原生报警，很多企业不得不选择“绕过合规”——将密码有效期设为 infinity。这种做法在安全审计中是红线，也是数据泄露的巨大隐患。

四、 逻辑的崩塌与新时代的生存法则

前提假设： 我们假设数据库的安全性必须由“外部管理系统”来兜底。
逻辑崩塌： 随着云原生和无服务器（Serverless）架构的普及，数据库实例往往是动态扩缩容的。如果内核不具备“自我感知”和“主动告知”的能力，外部监控系统将面临巨大的维护成本和滞后性。

引申观点： PG 的这次更新，标志着它正在从“纯粹的内核引擎”向“完备的管理平台”转型。

• 防御性编程： 数据库不应只是被动地执行命令，更应该主动参与到系统的稳定性治理中。
• 人性化设计： 减少 DBA 那些低价值的“巡检脚本”，让系统本身具备生命感。

结语

PostgreSQL 终于补齐了密码过期的“最后一公里”。虽然有人会嘲讽：“这功能 20 年前就该有了”，但从工程角度看，在如此庞大的内核中优雅地插入一套预警框架，其严谨性远超想象。

这也是 PG 愈发成熟的标志：它不再只关注那些毁天灭地的极致性能，而开始关心那些每天在凌晨两点因为账号过期而被叫醒的 DBA。

那么问题来了：既然 PG 已经开始“温情报警”了，你那些设为 infinity 的生产账号，是不是该考虑加上一个有效期了？