PostgreSQL生产环境发布关键更新:禁用调试断言以提升性能与稳定性

Percona发布重要公告,由于其部分PostgreSQL RPM包被错误地启用了调试断言,可能导致生产环境性能严重下降、意外崩溃等问题。本文详细解释了调试断言在生产环境中的危害、受影响版本以及立即升级的解决步骤。

更新请求!发布新的PostgreSQL RPM包以禁用调试断言

我们最近发现,我们的一批Percona Server for PostgreSQL RPM软件包在编译时无意中启用了调试断言标志(--enable-cassert)。虽然这些断言对我们的开发人员在测试阶段非常宝贵,但它们并非为生产环境设计。我们已重新构建了软件包,并强烈建议所有受影响版本的用户立即更新到最新版本。

为什么断言不属于生产环境

“断言”是嵌入代码中的健全性检查。它意味着:“开发人员假设在此确切点,条件X必须为真。如果不为真,则存在根本性错误。”当你在生产环境中启用这些断言时,会出现几个关键问题:

  1. 严重的性能下降 PostgreSQL每秒执行数百万次操作。启用断言后,CPU必须不断停止并验证数据库的内部状态。 结果:你可能会经历CPU使用率显著增加和事务吞吐量相应下降。在许多情况下,根据工作负载的不同,性能可能会下降20%到50%。

  2. “快速失败”问题(意外停机) 在标准的生产构建中,如果发生非关键的不一致,PostgreSQL可能会记录警告或尝试优雅地恢复。 结果:启用断言后,指令是立即中止。如果断言失败,整个后端进程会尽可能快地崩溃,以便核心转储/调试器能尽可能接近原始问题。虽然这在实验室中捕获错误是有益的,但在实际生产环境中,它可能导致潜在的服务重启、连接中断以及历史上的误报。

  3. 二进制文件大小和内存开销增加 调试符号和断言逻辑的包含会增加PostgreSQL二进制文件的大小。这可能导致指令缓存的使用效率降低,以及每个进程的内存消耗略有增加。

发生了什么?

在我们构建流水线的一次更新中,用于内部测试的配置标志被错误地应用于生产RPM构建脚本。这导致编译器包含了通常在性能和稳定性考虑下会被剥离的代码路径。

建议操作:

  • 检查你的版本:如果你在过去4个月内安装或更新,很可能受到影响。
    • 受影响版本
      • 18.1
      • 17.6 & 17.7
      • 16.10 & 16.11
      • 15.14 & 15.15
      • 14.19 & 14.20
      • 13.22 & 13.23
    • 手动检查pg_config --configure
      • 如果在输出中看到--enable-cassert,则表示你受到影响!
  • 立即更新到最新发布的RPM包或镜像
    • 作为重新构建的一部分,软件包编号已更改,而非PostgreSQL版本号。请再次检查pg_config以确保你不受影响。

我们对此疏忽表示歉意,并正在我们的CI/CD流水线中实施额外的自动化检查,以防止未来调试标志进入我们的生产仓库。

如果你有任何疑问或需要进一步帮助,请随时联系我们。

最新已修复的主要版本

关于作者

Kai Wagner 我是Kai,在Percona担任PostgreSQL的高级工程经理。我热衷于开源、透明度和言论自由。积极参与并为许多开源项目(如Ceph、openATTIC、Linux内核以及现在的PostgreSQL)进行公开演讲。我相信开放的世界更美好。当我不坐在电脑前时,我要么与家人共度时光,要么打理我们的房子。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计