谷歌云:投资于PostgreSQL的未来

在数据库技术的演进中，开源社区的协作是创新的核心引擎。作为这一生态的重要参与者，谷歌云始终将PostgreSQL视为其托管数据库服务（如Cloud SQL和AlloyDB）的基石，并持续投入资源回馈上游项目。过去半年，团队的工作重心清晰聚焦于几个关键领域：提升逻辑复制的成熟度、增强数据库升级的韧性，以及修复影响稳定性的底层问题。这些努力并非孤立的技术迭代，而是为了构建一个更可靠、更易用的基础，最终惠及全球范围内依赖PostgreSQL的每一位开发者和企业。

技术贡献：2025年7月 – 2025年12月

从2025年7月到12月，谷歌云工程师在PostgreSQL开源项目中的贡献，主要围绕逻辑复制、升级流程和系统稳定性三大方向展开。具体的技术改进和修复如下。

逻辑复制增强

逻辑复制堪称PostgreSQL的“瑞士军刀”，它能实现近乎零停机的版本升级、数据选择性同步，乃至构建主动-主动式架构。然而，一些长期存在的功能缺口限制了其潜力。近期社区的几项关键工作，正是为了填补这些空白。

自动冲突检测

构建主动-主动式PostgreSQL集群，最大的挑战之一就是处理行级数据冲突。当两个节点同时修改同一行数据时，传统的逻辑复制会因此卡住，不得不等待人工干预。这无疑成了高可用架构的绊脚石。好消息是，社区现已实现了自动冲突检测的基础框架——这是迈向自动化冲突解决的第一步。该机制使得复制工作进程能够自动识别出传入的数据变更（插入、更新或删除）与本地数据状态存在冲突，为后续的自动化处理铺平了道路。目前，相关工作正推进至第二阶段，旨在将冲突记录写入专用的日志表，为更智能的解决策略提供数据基础。

序列的逻辑复制

长期以来，PostgreSQL的逻辑复制只“关心”表数据，却将序列（Sequence）置之度外。这导致在迁移或大版本升级时，数据库管理员必须手动同步序列的当前值，否则极易在新主库上引发“重复键值”错误。考虑到序列在生成主键等场景中的普遍应用，这无疑是一个重大的使用障碍。现在，社区正在攻克这一难题，致力于让序列也能通过逻辑复制自动同步，从而消除这一手动操作风险，使逻辑复制方案更加完整。

修复DROP SUBSCRIPTION订阅僵局

此前，执行DROP SUBSCRIPTION命令删除订阅时，它会持有一个访问发布者的排他锁，以清理对应的复制槽。但如果发布者恰好位于同一台服务器的另一个数据库中，就可能引发一个有趣的“自我僵局”：该命令在等待自己持有的另一把锁，导致进程挂起。这个缺陷已被分析并修复，消除了这一潜在的运维陷阱。

升级韧性

平滑、无忧的升级体验，是数据库产品成熟度的试金石。为了提升PostgreSQL的升级韧性，团队针对几个关键痛点进行了优化。

大型对象的pg_upgrade优化

对于存储了大量大型对象（如图片、文档）的数据库，使用pg_upgrade进行跨版本升级可能耗时数天，令人难以忍受。性能瓶颈在于旧版本逐个处理大对象的低效方式。通过优化，改为直接导出底层数据表，升级速度得到了数量级的提升，将漫长的等待变成了分钟级的操作。

防止升级过程中的逻辑复制槽失效

在升级至PostgreSQL 17时，如果max_slot_wal_keep_size参数未设置为-1，升级过程可能会失败。这个修复增强了pg_upgrade的健壮性，用户无需再手动调整参数。服务器现在会自动保留逻辑复制槽所需的WAL日志数据，简化了升级流程，降低了因配置疏忽而导致失败的风险。

修复pg_upgrade中与NULL约束相关的错误

在从PostgreSQL 17或更新版本进行升级时，pg_dump工具中存在一个漏洞，导致继承列上的非继承式NULL约束无法被正确保留。修复方案更新了底层查询逻辑，确保在升级过程中，这类特定的表结构约束能够被准确识别和迁移，保障了数据模型的完整性。

错误修复

除了功能增强，持续修复影响稳定性的底层错误也同样重要。以下是此周期内解决的几个典型问题。

提升pgstattuple扩展对异常索引页的健壮性

pgstattuple扩展常用于分析表和索引的物理存储状况，以判断是否需要执行VACUUM或REINDEX等维护操作。然而，它在处理哈希索引和GiST索引中的空白或无效页面时，会引发错误。此次修复使其能够妥善处理这些异常页面，增强了工具的可靠性。

修复从嵌套路径加载扩展的问题

动态加载共享库（扩展）时存在一个错误：当库文件位于嵌套子目录时，系统错误地剥离了路径前缀，导致无法找到并加载这些扩展。修复后，系统仅对简单的文件名执行前缀剥离，从而确保能够正确加载位于复杂路径下的扩展模块。

硬化WAL刷新逻辑

XLogFlush()和XLogNeedsFlush()是PostgreSQL内部确保预写式日志（WAL）持久化的关键函数。但在某些边缘场景下（如恢复结束时的检查点），这些函数依赖的判断条件存在不一致性，可能导致选择错误的代码路径。这个问题不仅影响当前版本的稳定性，更对后续计划引入的异步I/O等新功能构成了潜在风险。此次修复硬化了相关逻辑，为未来更高级的I/O优化打下了坚实基础。