PostgreSQL功能发布计划
2017-04-02 22:04:43 
阿炯
三百多个 PostgreSQL 插件清单任君选
Pigsty 创作者整理并在其主页上发布了 333 个 PostgreSQL 插件清单。
截止2024年8月，这 333 个扩展在 Pigsty 中都可用，其中 EL 可用 RPM 扩展 326 个，Debian系 可用 DEB 扩展 312 个。 除去 PostgreSQL 自带的 70 个 Contrib 扩展，共有 263 个第三方（PGDG，Pigsty）扩展插件。
PostgreSQL 12 首个版本说明草案发布
2019年05月16日，虽然 PostgreSQL 12 尚未发布，不过开发团队已公布其首个版本说明草案。据官方介绍，这是一个十分重要的版本；下面看看有哪些值得关注的变化。对于从任意旧版本迁移到 PostgreSQL 12 的用户，需要使用 pg_dumpall 或 pg_upgrade 进行 dump/restore(备份和恢复)操作。
PostgreSQL 12 还包含许多可能影响与旧版本之间的兼容性的变更：
删除系统列 OID 的某些特殊行为
旧版本中，在创建表时可以通过WITH OIDS指定正常情况下不可见(normally-invisible)的 OID 列；在新版本中该特性已被删除，不过列仍可以被显式地指定为OID类型。
删除数据类型abstime，reltime和tinterval
删除时间段扩展(timetravel extension)
将recovery.conf设置移动至postgresql.conf
recovery.conf将不再被使用，如果该文件仍存在，服务器将无法启动
不再允许多种不同的recovery_target* 规范
旧版本中，可指定多个不同的 recovery_target*变量，现在只能指定一个
导致需要恢复的情况将默认使用最新状态
具体来说，recovery_target_time现在的默认值为latest，而旧版本的默认值为current
重构几何函数和运算符
会使得结果更准确，但和旧版本相比略有不同
重构几何类型以更加一致地处理 NaN、下溢、上溢和除零情况
改进社区报告的针对行数据类型的行为和错误
分区方面也有不少的改进：
提高分区表上许多操作的性能
现在可以有效地对数以千计的分区进行修剪
允许外键引用分区表
提高COPY分区表的速度
允许将分区边界设置为任意表达式
允许CREATE TABLE分区表的表空间规范影响其子表空间
此外还有索引、认证、监控和功能优化等诸多变化
由于所涉及的内容较多，建议查看原文。
PostgreSQL 开始支持 Zstd
2022年2月下旬消息，PostgreSQL 现已通过其 TOAST 存储技术提供压缩支持，并且在过去的一年里构建了 LZ4 压缩支持——用于压缩 WAL、备份压缩以及其他用途，现在 PostgreSQL 开发者正准备通过 Zstd 支持进一步扩展其压缩能力。
Zstd (Zstandard) 是由 Facebook 开源的快速无损压缩算法，主要应用于 zlib 级别的实时压缩场景，并且具有更好的压缩比。Zstd 还可以以压缩速度为代价提供更强的压缩比，速度与压缩权衡可通过小增量进行配置。
上周 PostgreSQL 开发者讨论了是否添加 Zstd 作为支持的压缩算法。在讨论邮件中，开发者表示 Zstd 有一个显著的优点——被 Linux 内核以及其他知名开源项目等广泛使用。这意味着它不会轻易停止维护，并且降低了涉及法律问题的风险。在技术层面上，Zstd 提供了与 Gzip 相似或更好的压缩比，但压缩速度要快得多。此外，Zstd 库具有内置的多线程压缩，PostgreSQL 可以利用它获得更好的性能。讨论过程十分顺利，目前已创建了相对应的 PostgreSQL Git 仓库，用于构建引入 Zstd 的 PostgreSQL。虽然已增加了 --with-zstd 构建时选项，并允许使用 Zstd 压缩库进行构建，但目前这并没有在 PostgreSQL 中启用 Zstd 的任何实际使用。后续的提交预计很快就会开始允许 PostgreSQL 利用 Zstd 的压缩能力优势。等到 PostgreSQL 15 发布时，相信会提供 Zstd 支持，以补充目前 PostgreSQL 14 的 LZ4 支持。
2022年3月中旬，这一举措已经有了最新进展；近期落地的代码工作中增加了对 Zstd 基础备份的压缩支持。PostgreSQL 客户端和服务器端压缩现在都支持使用 Zstd。此外为了适应 -Fp 的使用，由服务器使用 Zstd 压缩的备份现在可以由客户端解压缩。还有一项 commit 提供了对 WAL 中 full-page writes 操作的 Zstd 压缩。wal_compression 获得了一个新的值"zstd"，以允许使用同名的压缩方法压缩 full-page images。
压缩是使用库推荐的默认级别进行的， 如 ZSTD_CLEVEL_DEFAULT = 3。一些基准测试表明，对 FPI 压缩使用一个较低的级别可能是有意义的，比如级别 1 或 2；因为压缩率并没有因为消耗的 CPU 少而有很大的变化，但任何测试都只涵盖少数情况，所以很难得出一个明确的结论。总之，没有理由不使用默认级别，这是库中推荐的级别，所以对大多数情况来说应该是不错的。
zstd 很容易超越 pglz，而且在希望以额外的 CPU 为代价获得更多压缩的情况下，zstd 比 LZ4 更好；但两者在各自的情况下都足够好，所以在其中一个或另一个之间的选择主要是研究工作负载模式和涉及的模式。预计在最终的 PostgreSQL 15 版本中，将会看到更多有关这个 Zstd 压缩工作的内容。
PostgreSQL 计划优化性能并降低内存管理开销
Postgres 的 David Rowley 于2022年8月下旬提交了一项重要的修改，旨在提升 PostgreSQL 性能并减少内存管理开销。此举将 chunk header 的大小从 16 字节减少到了 8 字节：
此处所做的更改将我们所有 3 种内存上下文类型的 chunk header 大小减少到仅 8 个字节。对于中小型分配，这显着增加了我们可以在给定 chunk 上放置的 chunk 数，从而更有效地使用内存。另外，此 commit 彻底改变了指向 palloc 内存的指针必须直接以指向拥有内存上下文的指针作为前缀的规则；相反，我们现在坚持它们直接以 8 字节值作为前缀，其中最不重要的 3 位被设置为一个值，以指示指针属于哪种类型的内存上下文。使用这 3 位作为索引（称为 MemoryContextMethodID）到存储每种内存上下文类型的方法的新数组，我们现在可以将给定函数的指针（例如 pfree () 和 repalloc () ）传递给特定于该上下文实现的函数，以允许他们设计自己的方法来查找拥有给定分配的内存块的内存上下文。更多细节可以在此查看此提交。
在早些时候围绕减少 PostgreSQL 内存开销的讨论中，Rowley 就曾在 Ryzen Threadripper workstation 上的只读简单工作负载中实现了 17% 的吞吐量性能提升。当这种内存开销的减少在稳定的 PostgreSQL 版本中首次出现时，看看它在现实世界中的帮助肯定是有趣的。但是，由于 PostgreSQL 15 已经在今年晚些时候发布之前进行了分支，预计这种变化要到 PostgreSQL 16 才会出现。
PostgreSQL正面临进程或线程模型的抉择
面向进程模型是一种数据库系统的架构模型，核心思想是将不同的数据库服务分配给不同的进程，每个进程独立运行，相互之间通过进程间通信（IPC）进行协作。这种模型被广泛应用于数据库系统中，例如 PostgreSQL 数据库系统。进程模型使得 PostgreSQL 可以将不同的服务分配给多个进程独立运行，每个进程负责不同的任务，例如查询处理、并发控制、锁管理等。进程模型还可以可以保证系统的稳定性和可靠性。当一个进程出现问题时，不会影响到其他进程的正常运行，从而提高了系统的可用性。这将使得 PostgreSQL 可以同时处理大量的并发请求，提高了系统的性能和响应速度；除此之外，PostgreSQL 还可以很容易地进行水平扩展，增加更多的节点以应对更高的负载。不过与此同时，也让 PostgreSQL 面对着管理和维护成本相对较高、需要较为复杂的进程间通信和协调机制、需要消耗更多的系统资源等缺点。
2023年6月初，Heikki Linnakangas 发布了将 PostgreSQL 转为线程模型的提案。
线程模型是一种数据库系统的架构模型，与面向进程模型类似，它是将不同的数据库服务分配给不同的线程，每个线程独立运行，相互之间通过线程间通信进行协作。线程模型在一些轻量级的数据库系统中得到广泛应用，例如 SQLite。此两者的最大区别在于，线程模型中所有的线程共享同一个进程的地址空间，每个线程有自己的堆栈，共享代码段和数据段。这意味着线程之间可以直接访问同一份内存，因此线程间通信的成本相对较低，不过这也意味着线程间的数据共享可能会带来安全性问题。从进程模型转换成线程模型的优缺点如下：
优点
1.更轻量级：线程模型相对于进程模型更加轻量级，可以更加高效地使用系统资源，尤其是在单机上运行多个实例时，线程模型可以将多个实例运行在同一个进程中，减少了系统调用和进程间通信带来的开销。
2.更高的响应速度：线程模型中线程之间的通信成本相对较低，因此在高并发场景下具有更高的响应速度。
3.更少的内存占用：线程模型中线程共享同一份地址空间，因此可以避免进程模型中同一份代码和数据被多个进程重复加载到内存的问题，节省了系统内存占用。
缺点
1.安全性问题：线程之间共享同一份内存，可能会带来安全性问题，例如数据竞争和锁竞争等。
2.可靠性问题：线程模型中一个线程崩溃可能会影响到整个进程的稳定性和可靠性。
3.多线程编程难度较大：线程之间的通信需要进行同步和互斥，编写多线程程序的难度相对较大。
PostgreSQL 开发者、EnterpriseDB 高级数据库架构师 Andres Freund 指出：我认为原有流程模型开始产生诸多限制，这个问题在大型设备上体现得尤其明显。跨进程上下文切换所带来的开销，原本就比在同一进程内的不同线程间切换要更高 —— 我估计这种开销还将持续提升。面对大量连接，整个体系最终一定会因 TLB 未命中而浪费大量时间。这是进程模型无法跨进程共享 TLB 的天然属性造成的必然结果。
目前这还仅仅只是一项提议，并且由于 PostgreSQL 被广泛用于生产环境，转换到线程模型的过程需要非常谨慎。开发团队需要在不影响现有生产环境的情况下测试新的线程模型，以确保其稳定性和可靠性。即便这个提议通过，这个转化过程肯定也是无法通过单一版本彻底完成，从网上的各方评价来看，目前大多数人都支持这项提议(截止6月下旬，支持者占到80%)。
内置增量备份 (Incremental Backups) 功能
PostgreSQL 的 Git 仓库在2023年12月合并了支持增量备份 (incremental backup) 的 commit。据该提交的描述：要进行增量备份，可使用新的复制命令 UPLOAD_MANIFEST 上传指定的 prior backup 的 manifest。这个制指定的备份可以是完整备份，也可以是另一个增量备份。然后使用包含 INCREMENTAL 选项的 BASE_BACKUP 命令进行备份。pg_basebackup 提供了 --incremental=PATH\_TO\_MANIFEST 选项来触发此行为。
增量备份与常规完整备份类似，只是某些关系文件被替换为名称如 INCRMENTAL.${ORIGINAL_NAME} 的文件，并且 backup_label 文件包含将其标识为增量备份的其他行。
新的 pg_combinebackup 工具可用于从完整备份和一系列增量备份重建数据目录。
将不再支持 MD5 密码
根据 PostgreSQL 代码仓库的2024年12月的动态，有维护者提交了 “弃用 MD5 密码支持” 的 commit。该维护者指出，MD5 被认为不适合用作加密散列算法已有一段时间。此外，PostgreSQL 中的 MD5 密码散列很容易受到传递散列攻击，即知道用户名和散列密码就足以进行身份验证。v10 中添加的 SCRAM-SHA-256 方法不存在这些问题，被认为优于 MD5。
根据讨论，本次 commit 将 PostgreSQL 中的 MD5 密码支持标记为弃用，并将在未来的版本中删除。现文档中包含了多个弃用通知，而 CREATE ROLE 和 ALTER ROLE 在设置 MD5 密码时也会发出弃用警告。用户可以通过将 md5_password_warnings 参数设置为 "off" 来禁用这些警告。这可能是 PostgreSQL 18 明确告知 MD5 密码支持已过时并将在未来移除的程度。PostgreSQL 19 将支持使用 MD5 密码升级，并允许使用它们进行身份验证，但禁止创建新密码。之后，PostgreSQL 20 将禁止使用 MD5 密码进行验证。
最后，在 PostgreSQL 21 中，将禁止使用 MD5 密码升级，并且 PostgreSQL 内部将不再提供 MD5 密码支持。因此，如果出于某种原因需要，PostgreSQL 中的 MD5 密码支持仍将存在数年，但现在已被正式弃用，移除路径也已启动。
Pigsty 创作者整理并在其主页上发布了 333 个 PostgreSQL 插件清单。
截止2024年8月，这 333 个扩展在 Pigsty 中都可用，其中 EL 可用 RPM 扩展 326 个，Debian系 可用 DEB 扩展 312 个。 除去 PostgreSQL 自带的 70 个 Contrib 扩展，共有 263 个第三方（PGDG，Pigsty）扩展插件。
PostgreSQL 12 首个版本说明草案发布
2019年05月16日，虽然 PostgreSQL 12 尚未发布，不过开发团队已公布其首个版本说明草案。据官方介绍，这是一个十分重要的版本；下面看看有哪些值得关注的变化。对于从任意旧版本迁移到 PostgreSQL 12 的用户，需要使用 pg_dumpall 或 pg_upgrade 进行 dump/restore(备份和恢复)操作。
PostgreSQL 12 还包含许多可能影响与旧版本之间的兼容性的变更：
删除系统列 OID 的某些特殊行为
旧版本中，在创建表时可以通过WITH OIDS指定正常情况下不可见(normally-invisible)的 OID 列；在新版本中该特性已被删除，不过列仍可以被显式地指定为OID类型。
删除数据类型abstime，reltime和tinterval
删除时间段扩展(timetravel extension)
将recovery.conf设置移动至postgresql.conf
recovery.conf将不再被使用，如果该文件仍存在，服务器将无法启动
不再允许多种不同的recovery_target* 规范
旧版本中，可指定多个不同的 recovery_target*变量，现在只能指定一个
导致需要恢复的情况将默认使用最新状态
具体来说，recovery_target_time现在的默认值为latest，而旧版本的默认值为current
重构几何函数和运算符
会使得结果更准确，但和旧版本相比略有不同
重构几何类型以更加一致地处理 NaN、下溢、上溢和除零情况
改进社区报告的针对行数据类型的行为和错误
分区方面也有不少的改进：
提高分区表上许多操作的性能
现在可以有效地对数以千计的分区进行修剪
允许外键引用分区表
提高COPY分区表的速度
允许将分区边界设置为任意表达式
允许CREATE TABLE分区表的表空间规范影响其子表空间
此外还有索引、认证、监控和功能优化等诸多变化
由于所涉及的内容较多，建议查看原文。
PostgreSQL 开始支持 Zstd
2022年2月下旬消息，PostgreSQL 现已通过其 TOAST 存储技术提供压缩支持，并且在过去的一年里构建了 LZ4 压缩支持——用于压缩 WAL、备份压缩以及其他用途，现在 PostgreSQL 开发者正准备通过 Zstd 支持进一步扩展其压缩能力。
Zstd (Zstandard) 是由 Facebook 开源的快速无损压缩算法，主要应用于 zlib 级别的实时压缩场景，并且具有更好的压缩比。Zstd 还可以以压缩速度为代价提供更强的压缩比，速度与压缩权衡可通过小增量进行配置。
上周 PostgreSQL 开发者讨论了是否添加 Zstd 作为支持的压缩算法。在讨论邮件中，开发者表示 Zstd 有一个显著的优点——被 Linux 内核以及其他知名开源项目等广泛使用。这意味着它不会轻易停止维护，并且降低了涉及法律问题的风险。在技术层面上，Zstd 提供了与 Gzip 相似或更好的压缩比，但压缩速度要快得多。此外，Zstd 库具有内置的多线程压缩，PostgreSQL 可以利用它获得更好的性能。讨论过程十分顺利，目前已创建了相对应的 PostgreSQL Git 仓库，用于构建引入 Zstd 的 PostgreSQL。虽然已增加了 --with-zstd 构建时选项，并允许使用 Zstd 压缩库进行构建，但目前这并没有在 PostgreSQL 中启用 Zstd 的任何实际使用。后续的提交预计很快就会开始允许 PostgreSQL 利用 Zstd 的压缩能力优势。等到 PostgreSQL 15 发布时，相信会提供 Zstd 支持，以补充目前 PostgreSQL 14 的 LZ4 支持。
2022年3月中旬，这一举措已经有了最新进展；近期落地的代码工作中增加了对 Zstd 基础备份的压缩支持。PostgreSQL 客户端和服务器端压缩现在都支持使用 Zstd。此外为了适应 -Fp 的使用，由服务器使用 Zstd 压缩的备份现在可以由客户端解压缩。还有一项 commit 提供了对 WAL 中 full-page writes 操作的 Zstd 压缩。wal_compression 获得了一个新的值"zstd"，以允许使用同名的压缩方法压缩 full-page images。
压缩是使用库推荐的默认级别进行的， 如 ZSTD_CLEVEL_DEFAULT = 3。一些基准测试表明，对 FPI 压缩使用一个较低的级别可能是有意义的，比如级别 1 或 2；因为压缩率并没有因为消耗的 CPU 少而有很大的变化，但任何测试都只涵盖少数情况，所以很难得出一个明确的结论。总之，没有理由不使用默认级别，这是库中推荐的级别，所以对大多数情况来说应该是不错的。
zstd 很容易超越 pglz，而且在希望以额外的 CPU 为代价获得更多压缩的情况下，zstd 比 LZ4 更好；但两者在各自的情况下都足够好，所以在其中一个或另一个之间的选择主要是研究工作负载模式和涉及的模式。预计在最终的 PostgreSQL 15 版本中，将会看到更多有关这个 Zstd 压缩工作的内容。
PostgreSQL 计划优化性能并降低内存管理开销
Postgres 的 David Rowley 于2022年8月下旬提交了一项重要的修改，旨在提升 PostgreSQL 性能并减少内存管理开销。此举将 chunk header 的大小从 16 字节减少到了 8 字节：
此处所做的更改将我们所有 3 种内存上下文类型的 chunk header 大小减少到仅 8 个字节。对于中小型分配，这显着增加了我们可以在给定 chunk 上放置的 chunk 数，从而更有效地使用内存。另外，此 commit 彻底改变了指向 palloc 内存的指针必须直接以指向拥有内存上下文的指针作为前缀的规则；相反，我们现在坚持它们直接以 8 字节值作为前缀，其中最不重要的 3 位被设置为一个值，以指示指针属于哪种类型的内存上下文。使用这 3 位作为索引（称为 MemoryContextMethodID）到存储每种内存上下文类型的方法的新数组，我们现在可以将给定函数的指针（例如 pfree () 和 repalloc () ）传递给特定于该上下文实现的函数，以允许他们设计自己的方法来查找拥有给定分配的内存块的内存上下文。更多细节可以在此查看此提交。
在早些时候围绕减少 PostgreSQL 内存开销的讨论中，Rowley 就曾在 Ryzen Threadripper workstation 上的只读简单工作负载中实现了 17% 的吞吐量性能提升。当这种内存开销的减少在稳定的 PostgreSQL 版本中首次出现时，看看它在现实世界中的帮助肯定是有趣的。但是，由于 PostgreSQL 15 已经在今年晚些时候发布之前进行了分支，预计这种变化要到 PostgreSQL 16 才会出现。
PostgreSQL正面临进程或线程模型的抉择
面向进程模型是一种数据库系统的架构模型，核心思想是将不同的数据库服务分配给不同的进程，每个进程独立运行，相互之间通过进程间通信（IPC）进行协作。这种模型被广泛应用于数据库系统中，例如 PostgreSQL 数据库系统。进程模型使得 PostgreSQL 可以将不同的服务分配给多个进程独立运行，每个进程负责不同的任务，例如查询处理、并发控制、锁管理等。进程模型还可以可以保证系统的稳定性和可靠性。当一个进程出现问题时，不会影响到其他进程的正常运行，从而提高了系统的可用性。这将使得 PostgreSQL 可以同时处理大量的并发请求，提高了系统的性能和响应速度；除此之外，PostgreSQL 还可以很容易地进行水平扩展，增加更多的节点以应对更高的负载。不过与此同时，也让 PostgreSQL 面对着管理和维护成本相对较高、需要较为复杂的进程间通信和协调机制、需要消耗更多的系统资源等缺点。
2023年6月初，Heikki Linnakangas 发布了将 PostgreSQL 转为线程模型的提案。
线程模型是一种数据库系统的架构模型，与面向进程模型类似，它是将不同的数据库服务分配给不同的线程，每个线程独立运行，相互之间通过线程间通信进行协作。线程模型在一些轻量级的数据库系统中得到广泛应用，例如 SQLite。此两者的最大区别在于，线程模型中所有的线程共享同一个进程的地址空间，每个线程有自己的堆栈，共享代码段和数据段。这意味着线程之间可以直接访问同一份内存，因此线程间通信的成本相对较低，不过这也意味着线程间的数据共享可能会带来安全性问题。从进程模型转换成线程模型的优缺点如下：
优点
1.更轻量级：线程模型相对于进程模型更加轻量级，可以更加高效地使用系统资源，尤其是在单机上运行多个实例时，线程模型可以将多个实例运行在同一个进程中，减少了系统调用和进程间通信带来的开销。
2.更高的响应速度：线程模型中线程之间的通信成本相对较低，因此在高并发场景下具有更高的响应速度。
3.更少的内存占用：线程模型中线程共享同一份地址空间，因此可以避免进程模型中同一份代码和数据被多个进程重复加载到内存的问题，节省了系统内存占用。
缺点
1.安全性问题：线程之间共享同一份内存，可能会带来安全性问题，例如数据竞争和锁竞争等。
2.可靠性问题：线程模型中一个线程崩溃可能会影响到整个进程的稳定性和可靠性。
3.多线程编程难度较大：线程之间的通信需要进行同步和互斥，编写多线程程序的难度相对较大。
PostgreSQL 开发者、EnterpriseDB 高级数据库架构师 Andres Freund 指出：我认为原有流程模型开始产生诸多限制，这个问题在大型设备上体现得尤其明显。跨进程上下文切换所带来的开销，原本就比在同一进程内的不同线程间切换要更高 —— 我估计这种开销还将持续提升。面对大量连接，整个体系最终一定会因 TLB 未命中而浪费大量时间。这是进程模型无法跨进程共享 TLB 的天然属性造成的必然结果。
目前这还仅仅只是一项提议，并且由于 PostgreSQL 被广泛用于生产环境，转换到线程模型的过程需要非常谨慎。开发团队需要在不影响现有生产环境的情况下测试新的线程模型，以确保其稳定性和可靠性。即便这个提议通过，这个转化过程肯定也是无法通过单一版本彻底完成，从网上的各方评价来看，目前大多数人都支持这项提议(截止6月下旬，支持者占到80%)。
内置增量备份 (Incremental Backups) 功能
PostgreSQL 的 Git 仓库在2023年12月合并了支持增量备份 (incremental backup) 的 commit。据该提交的描述：要进行增量备份，可使用新的复制命令 UPLOAD_MANIFEST 上传指定的 prior backup 的 manifest。这个制指定的备份可以是完整备份，也可以是另一个增量备份。然后使用包含 INCREMENTAL 选项的 BASE_BACKUP 命令进行备份。pg_basebackup 提供了 --incremental=PATH\_TO\_MANIFEST 选项来触发此行为。
增量备份与常规完整备份类似，只是某些关系文件被替换为名称如 INCRMENTAL.${ORIGINAL_NAME} 的文件，并且 backup_label 文件包含将其标识为增量备份的其他行。
新的 pg_combinebackup 工具可用于从完整备份和一系列增量备份重建数据目录。
将不再支持 MD5 密码
根据 PostgreSQL 代码仓库的2024年12月的动态，有维护者提交了 “弃用 MD5 密码支持” 的 commit。该维护者指出，MD5 被认为不适合用作加密散列算法已有一段时间。此外，PostgreSQL 中的 MD5 密码散列很容易受到传递散列攻击，即知道用户名和散列密码就足以进行身份验证。v10 中添加的 SCRAM-SHA-256 方法不存在这些问题，被认为优于 MD5。
根据讨论，本次 commit 将 PostgreSQL 中的 MD5 密码支持标记为弃用，并将在未来的版本中删除。现文档中包含了多个弃用通知，而 CREATE ROLE 和 ALTER ROLE 在设置 MD5 密码时也会发出弃用警告。用户可以通过将 md5_password_warnings 参数设置为 "off" 来禁用这些警告。这可能是 PostgreSQL 18 明确告知 MD5 密码支持已过时并将在未来移除的程度。PostgreSQL 19 将支持使用 MD5 密码升级，并允许使用它们进行身份验证，但禁止创建新密码。之后，PostgreSQL 20 将禁止使用 MD5 密码进行验证。
最后，在 PostgreSQL 21 中，将禁止使用 MD5 密码升级，并且 PostgreSQL 内部将不再提供 MD5 密码支持。因此，如果出于某种原因需要，PostgreSQL 中的 MD5 密码支持仍将存在数年，但现在已被正式弃用，移除路径也已启动。
该文章最后由 阿炯 于 2024-12-04 14:01:12 更新，目前是第 2 版。