银行狂喜, PostgreSQL 重新支持AIX

银行狂喜, PostgreSQL 重新支持AIX

在数据库开源界的权力版图中，PostgreSQL（以下简称 PG）一直以“硬核、冷酷、追求代码极致”著称。就在几年前，当 PG 社区宣布因维护成本过高而打算放弃对 IBM AIX 系统的支持时，全球那些奔跑在 Power 架构上的银行、电信和核心制造业巨头们，仿佛听到了“末日倒计时”。

然而，2026年2月，反转来了！PG 传奇开发者 Tom Lane 亲自提交 Commit：正式恢复（Restore）对 AIX 的支持。 这不是一次简单的代码回滚，而是一场多方博弈后的“精准救赎”。

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=4a1b05caa55dc14a1f936af78d8d19c843bfd8b9

一、 痛点：被遗忘的“大象”，那些无法搬迁的遗留系统

为什么 AIX 用户的祈祷如此迫切？

• 现状： 在 Linux 统治世界的今天，AIX 依然是全球金融级、政府级核心业务的底座。在这些场景下，系统不是想迁就能迁的。
• 断层危机： 之前的版本移除 AIX 支持，意味着这些用户被锁死在了旧版本（如 v16）上，无法享受后面性能翻倍、安全性提升的红利。
• 后果： 缺乏原生支持意味着要么忍受不稳定的社区补丁，要么在硬件升级时面临软件不兼容的风险。

对于这些机构来说，PG 重新支持 AIX，不只是多了一个版本，而是给了这些耗资数亿的 IT 资产一线生机。

二、 技术剖析：这是一场有条件的“政治妥协”

PG 社区从不吃亏。这次恢复支持，是建立在几个冷酷且理性的 “减负前提” 之上的：

1. IBM 的“入场券”

社区恢复支持的第一性原理是：“谁受益，谁维护。”
这一次，IBM 不再仅仅是旁观者，而是直接派出了 buildfarm 资源和核心工程师。没有 IBM 的人力和机器支撑，社区绝不会动一根手指。

2. 扔掉沉重的“历史包袱”

这次恢复是有代价的，社区采取了“外科手术式”的精简 ：

• 砍掉 32 位支持： 32 位 AIX 内存地址空间管理简直是开发者的噩梦，这次直接官宣“不伺候了”。
• 抛弃 xlc 编译器： 曾经为了支持 IBM 原生 xlc 编译器的各种 Bug，代码库里塞满了 Hack。现在统一改用 GCC，这意味着 PG 的通用性战胜了特定硬件的偏执。
• 版本隔离： 仅支持 AIX 7.2 及以上版本。因为 7.1 已经寿终正寝（EOL），社区拒绝为过时的系统续命。

3. 底层机制的重构

代码中引入了 POSIX 信号量 替代 SysV，优化了 /opt/freeware/lib 的库路径搜索。这些改进说明，PG 并不想做一个“能跑就行”的兼容，而是想让 PG 在 Power 架构上跑得更优雅。

三、 权威案例：为什么 AIX 依然重要？

1. 行业数据支撑

虽然 Linux 占据了 90% 以上的新增市场，但在 Fortune 500 公司的核心账务系统中，Power+AIX 的组合依然占据着不可动摇的份额。

案例： 某全球排名前十的零售银行，其核心联机交易数据库依然运行在 Power E1080 平台上。对他们而言，PG 的支持意味着可以利用 PG 作为 AIX 上的“轻量级备库”或“微服务适配层”，实现传统大机与云原生生态的对接。

2. 性能与可靠性的“护城河”

AIX 对内存的精细化控制和 Power 架构的极高单核性能，在处理超大型单实例数据库时依然具有优势。PG 的回归，让“稳如老狗”的硬件和“快如闪电”的开源数据库再次联姻。

四、 逻辑的崩塌：如果 IBM 再次缺席？

前提假设： 此次恢复的前提是 IBM 提供的 buildfarm（自动构建农场）能持续运行，且开发者活跃。
逻辑崩塌： 如果未来 IBM 再次缩减在 AIX 上的投入，或者 buildfarm 频繁挂掉且无人修复，PG 社区极有可能再次撤销支持。

引申观点： 开源项目的生命力不仅取决于代码，更取决于利益相关者的持久贡献。AIX 用户不能仅仅祈祷，更需要通过商业合同或技术贡献来维持这个生态的“供氧”。

结语

PostgreSQL 重新支持 AIX，是开源实用主义的一次重大胜利。它告诉我们：只要利益对等、分工明确，再老旧的“大象”也能跳起现代的舞步。

对 IBM 而言，这保住了 Power 硬件的生态吸引力；对 PG 社区而言，这进一步巩固了其“全平台、全场景”数据库霸主的地位；对用户而言，这代表着一种确定性。

那么问题来了：既然 AIX 上的 PG 已经重生，那些一直被调侃为“老古董”的传统行业，是不是也该加速你们的数据库现代化进程了？