2022 年 5 月 12 日，PostgreSQL 全球开发组 发布了其所有受支持版本 (10-14) 的定期季度更新，其中包含错误修复和针对CVE-2022-1552的安全修复。根据其版本政策，PostgreSQL 社区建议用户运行“可用于主要版本的最新可用次要版本”。这通常是正确的方法：更新版本使每个主要版本更加稳定，社区齐心协力避免引入重大更改。在将每个更新版本发布到生产环境之前，您应该始终对其进行测试。
但是，在决定升级时，您应该注意一些问题。一个问题会影响 PostgreSQL 14 到 14.3 的所有版本，一个问题限定于2022 年 5 月 12 日的版本，您确实需要权衡升级决定与合并 CVE-2022-1552 的修复和在这个版本中的其他可用的bug修复。
下面解释了每个问题是什么，它影响的 PostgreSQL 版本，升级和任何补救措施的权衡。
在 PostgreSQL 14 上 CREATE INDEX CONCURRENTLY/REINDEX CONCURRENTLY
清理是 PostgreSQL 维护的重要组成部分，它执行诸如从更新和删除的行中回收磁盘空间之类的操作。PostgreSQL 14 (14.0)的GA 版本引入了对 vacumm 的优化，当 CREATE INDEX CONCURRENTLY 或 REINDEX CONCURRENTLY 同时执行的时候。
在 PostgreSQL 14中有一些关于索引损坏的 bug 报告，在PostgreSQL 14.3 发布后不久，PostgreSQL 社区的一些成员能够始终如一地重现该问题。CREATE INDEX CONCURRENTLY 当使用或构建索引时，上一段中描述的优化可能会导致无提示索引损坏的情况,当索引是通过 CREATE INDEX CONCURRENTLY 或 REINDEX CONCURRENTLY 创建的时候。该问题自 PostgreSQL 14.0 起就存在：它不会影响任何其他受支持的 PostgreSQL 版本（即 PostgreSQL 10 - 13）。
经过一番讨论，PostgreSQL 社区决定暂时恢复 VACUUM 优化，直到可以实施不包含静默索引损坏风险的解决方案。社区已经讨论了如何使用 pg_amcheck 来检测这个损坏问题，特别是配合使用 --heapallindexed 标志。这将对每个表加一个共享锁，但不会阻塞 VACUUM 并且可以在备用数据库上运行。请注意，pg_amcheck 它只能检测 B-tree 索引上的损坏问题，社区不确定它是否可以检测到所有损坏情况。
如果您已运行 CREATE INDEX CONCURRENTLY 或 REINDEX CONCURRENTLY 在使用 PostgreSQL 14的时候，并需要立即修复，则可以通过运行运行 REINDEX 或删除并重新创建索引来修复索引，而不使用该 CONCURRENTLY 选项。一旦 PostgreSQL 14.4 可用，您就可以使用 CONCURRENTLY. reindexdb 命令行实用程序可以帮助处理该过程，因为该标志 --jobs 允许您 REINDEX 在整个数据库中同时执行多个操作。
CVE-2022-1552的简要说明
要了解另一个问题，首先需要了解 CVE-2022-1552 的影响。如前所述，CVE-2022-1552关闭了一个漏洞，在该漏洞中非特权用户可以制作恶意 SQL 并使用某些命令（Autovacuum, REINDEX, CREATE INDEX, REFRESH MATERIALIZED VIEW, CLUSTER 和 pg_amcheck)）升级为 PostgreSQL 超级用户。恶意用户仍然需要拥有 PostgreSQL 系统的帐户才能执行此攻击。
具有 SQL 注入风险的非特权 PostgreSQL 用户的系统（例如 Web 应用程序）或多租户系统可能会特别受到此CVE 的影响。同时升级到 14.3 等修复了该问题，社区提供了指导，如果您无法进行此升级，您仍然可以通过禁用 autovacuum（对性能权衡发出警告）、不运行上述命令以及不使用来自 pg_dump 的输出进行恢复.
此问题影响所有受支持的 PostgreSQL (10-14) 版本，但正如 CVE 所指出的，该问题已经很老了，并且未在不受支持的版本（例如 9.6 和更早版本）中修补。
使用来自不同模式的运算符类创建表达式索引
在 2022 年 5 月 12 日更新发布后不久，出现了一份基于PostgreSQL bug 邮件列表的报告，其中说明了用户无法以非特权用户的身份创建表达式索引，在使用来自不同用户创建的不同模式的运算符类时。具体来说，该案例使用 pg_trgm 索引中的 gist_trgm_ops 运算符类来允许文本相似性运算符可加索引的。虽然该问题最初是根据 pg_dump 的输出报告的，但可以使用一些命令以直接的方式重现该问题。可能还有其他几种情况，其他表达式索引可能会出现此问题，但上述情况一直在持续性的重现。
CVE-2022-1552的修复引入了此问题，并且仅影响 PostgreSQL 14.3、13.7、12.11、11.16 和 10.21。在撰写此博客文章时，仍没有可用的修复。对于补救措施，您可以将操作员类添加到您正在创建索引的同一架构中。确保任何更改都符合您为数据库实施的安全状况。
我应该升级到 14.3、13.7、12.11、11.16、10.21 吗？
如果您的数据库有一个单用户并且是 PostgreSQL 超级用户，那么您应该能够毫无问题地升级。请注意，如果您使用的是 PostgreSQL 14，您仍然会受到 CREATE INDEX CONCURRENTLY/REINDEX CONCURRENTLY 问题的影响，并且在修复到位之前，您不应使用这些命令。
对于所有其他情况，您需要权衡上述问题的权衡。如果您使用的是 PostgreSQL 14，那么无论您是否进行此更新，都会受到 CREATE INDEX CONCURRENTLY/REINDEX CONCURRENTLY 问题的影响。您应该意识到这个问题并且不要运行这些命令。如果有，您可能需要重新索引。索引损坏问题不应阻止您从 PostgreSQL 14.3 更新。
如果您正在运行一个包含非特权 PostgreSQL 用户的系统，您将需要权衡合并 CVE-2022-1552 的修复程序与您的应用程序的潜在破坏之间的权衡。该 bug 最有可能在执行“模式迁移”或从 pg_dump 恢复时显示出来，但仅限于您是否使用任何运算符类（例如用于索引）以及您如何构建模式。可能还有其他一些未报告的情况受到此问题的影响，因此请确保您测试从 pg_dump（例如pg_dump --schema-only）恢复您的架构。
正如 CVE 所提到的，您仍然可以在不升级的情况下修复漏洞，但这些步骤存在性能和潜在的稳定性风险。Vacuuming 是 PostgreSQL 维护的重要组成部分，如果您不使用它，您的系统最终可能会变慢。在更极端的情况下，系统可能会遇到事务 ID wraparound，这会将 PostgreSQL 数据库置于不可用状态。
如果您认为您的应用程序不受创建索引问题的影响，则应考虑升级。CVE-2022-1552 的修复比修复步骤更容易应用。修复存在系统性能下降和不稳定的风险，因此如果您认为升级是安全的，则应该这样做。
运行主要版本最新版本的PostgreSQL 社区指南是一个很好的最佳实践。您应该通读发布公告和发布说明以了解可用的修复程序，并在将应用程序部署到生产之前针对更新版本测试您的应用程序。
原文标题：NOTES ON UPDATING TO POSTGRESQL 14.3, 13.7, 12.11, 11.16, AND 10.21
原文作者：JONATHAN KATZ
原文地址：https://jkatz05.com/post/postgres/may-2022-release-should-i-update/
