前言
PostgreSQL遵循小版本的发布规律，这一个季度的小版本又发布了。可以算作是2024年第一个季度的版本发布。如果总结其规律：大概就是2月、5月、8月、11月的样子。通常因为11月配合大版本的发布，它是起点，也有可能就是终点。起点可能是*.0，也有可能是*.1 。于是你在标题里头，可以看到14.11这样的版本号。（正常情况，应该是14.8)。但是总体来说应该是每个季度一次小版本的发布更新。
详情介绍
1、重大安全补丁
CVE-2024-0985: PostgreSQL non-owner REFRESH MATERIALIZED VIEW CONCURRENTLY executes arbitrary SQL
CVSS v3 Base Score 分数达到8.0分。超过7/7.5分的，一般都属于高等级的安全问题了。基于此，那基本上这个升级就成了强制性需求了。
One step of a concurrent refresh command was run under weak security restrictions. If a materialized view's owner could persuade a superuser or other high-privileged user to perform a concurrent refresh on that view, the view's owner could control code executed with the privileges of the user running
REFRESH. The fix for the vulnerability makes is so that all user-determined code is run as the view's owner, as expected.The PostgreSQL project thanks Pedro Gallegos for reporting this problem.
所以有些同学问，什么时候需要做小版本升级，这里我可以有给出肯定的答复，遇到重大安全补丁的修复时，这类升级基本上就是强制型的升级了，基本上没有余地。
2、BUG修复及相关改进
此更新修复了过去几个月报告的超过65个错误。下面列出的问题会影响PostgreSQL 16。其中一些问题也可能影响其他受支持的PostgreSQL版本。
-
修复在执行JIT内联时可能导致内存不足的内存泄漏。
-
修复了查询规划器中的几个问题。
-
在更新分区键列时，将MERGE行为与UPDATE保持一致，并跳过触发AFTER UPDATE ROW触发器和其他更新后的操作。
-
修复在ALTER TEXT SEARCH CONFIGURATION … MAPPING命令中重复令牌名称的问题。
-
修复DROP ROLE中角色名重复的问题。
-
在DROP STATISTICS期间正确地锁定关联表，以防止在并发运行ANALYZE时出现错误。
-
修复了生成和默认表达式的函数波动性(volatility)检查。
-
在将现有索引与新的分区索引进行匹配时，确保排序规则完全匹配。
-
避免子索引与分区索引上的REINDEX index同时并发进行删除时出现的错误。
-
修复了清理GIN索引期间的加锁问题。对于这种情况，如果多个进程试图清理相同的GIN索引页，则有可能导致索引损坏。如果您认为您受到此问题的影响，请在安装此更新后重新索引您的GIN索引。
-
避免分区SP-GiST索引出现失败。
-
几个大对象的所有权问题的修复。
-
在EXPLAIN (BUFFERS)中修改I/O计时统计(timing)数据“shared/local”的名称为“shared”。
-
如果在执行期间或执行后不久发生系统崩溃，请确保CREATE DATABASE命令的持久性。
-
在开始和结束从备份恢复时添加更多的日志记录消息。
-
回退了一个使walreceiver进程在等待建立复制连接时对SIGTERM无响应的更改。
-
对逻辑复制进行了几个修复。
-
修复与OpenSSL 3.2的不兼容性。
-
修正PL/pgSQL，以允许使用SQL标准函数体的CREATE FUNCTION/CREATE PROCEDURE SQL命令。
-
修复了libpq管道模式下的错误处理。
-
确保initdb总是取消对lc_*系列参数的postgresql.conf条目的注释。
-
在pg_dump中，不再转储扩展成员对象的RLS策略或安全标签。
此版本还更新了时区数据文件到tzdata版本2024a，其中包括格陵兰、哈萨克斯坦和巴勒斯坦的夏令时法律变化，以及南极站Casey和Vostok的更正。还有越南、多伦多和密克隆岛的历史修正。
注意一项：如果使用GIN索引，则在更新到此版本后可能需要重新索引。
所以呢，小版本升级，也并不是说直接升级Binary文件就了事了。该读的文档还是要读一读的，以防止一些步骤的疏漏。
SAP BTP云中HyperScaler PG的自动升级
SAP BTP Cloud针对GCP, AWS, Azure甚至Ali中的PG做了自己的定制扩展，很多工作都是自动完成的。比如这次小版本升级，通过pipeline自动执行，结合生产环境中的Multi-AZ (HA的一种体现或增强体现），可以在1分钟以内完成自动切换，而不影响实际业务的运行。
当然这个Multi-AZ的节点切换过程，对DNS cache以及CF（Cloud Foundry)上的health-check时间响应也都是提出了一些要求。DNS Cache的过期时间，减至15秒（默认的很多环境都是30秒或以上）。health-check的频率及周期需要能覆盖住上边1分钟的边界。
小版本的自动升级确实能大大减轻DBA及相关团队的工作量。唯一升下的就是有效的监控……。最终的目的都是为了高质量的SLA。这才是客户需要的。
每年将有可能的维护时间（可能要停服一小段时间），全部节省下来，让给PostgreSQL的大版本升级。
参考:
https://www.postgresql.org/about/news/postgresql-162-156-1411-1314-and-1218-released-2807/: https://www.postgresql.org/about/news/postgresql-162-156-1411-1314-and-1218-released-2807/
