---
title: "PostgreSQL 19 RC2 将于 11 月 12 日与 14 的最后一个版本同日发布"
date: 2026-11-10
slug: postgresql-19-rc2-and-14-eol
canonical: https://kernelranch.com/blog/2026/11/postgresql-19-rc2-and-14-eol
markdown_url: https://kernelranch.com/blog/2026/11/postgresql-19-rc2-and-14-eol.md
tags: ["PostgreSQL", "release", "eol", "版本升级"]
---PostgreSQL 全球开发组在 2026 年 10 月 15 日发布了 19 的第一个候选版本 RC1，并给出一个不太常见的安排：RC2 将和 11 月 12 日的例行更新同天发布。

## 1. 为什么会有 RC2

官方公告的解释是：11 月 12 日这次对受支持版本的例行更新包含大量修复，发布组决定把这些修复也带进 19，在其正式发布之前完成。

这个决定意味着 19 的 GA 会略晚于原计划，但换来一个更干净的初始版本。对使用者来说，这比"GA 之后再补一堆 minor"要好。

## 2. 同一天还发生什么

| 时间 | 事件 |
|---|---|
| 2026-10-15 | PostgreSQL 19 RC1 发布 |
| 2026-11-12 | 例行更新（包含大量修复）+ PostgreSQL 19 RC2 |
| 2026-11-12 | PostgreSQL 14 的最后一个 minor 版本 |
| 之后 | PostgreSQL 19 GA（按官方路线图） |

四件事挤在同一天，对运维来说是个提醒：如果你维护着 14，这个日期之后它就进入不再支持状态；如果你在评估 19，RC2 才是更接近 GA 的版本。

## 3. 对两类人的建议

还在 14 上的人。最后一个 minor 之后不会再有安全修复。升级路径有两条：`pg_upgrade` 停机升级，或者逻辑复制的近零停机迁移。前者简单，后者要看库的大小和 schema 复杂度。

准备上 19 的人。RC1 与 RC2 之间并入了大量修复，评估时用 RC2，不要再用 RC1 的测试结论。另外 19 的异步 I/O 参数名有变化（`io_workers` 拆成 `io_min_workers` / `io_max_workers`），从 18 迁移过来的配置需要改。

## 小结

这次发布节奏值得记一笔：发布组为了把例行修复并入大版本，宁可多做一个 RC。这种"宁可晚一点"的选择，在数据库这种长周期软件上是合理的。

对个人来说，11 月 12 日是这一轮的分水岭：14 到此为止，19 进入候选版本的最后阶段。

## 数据来源与检索时间

检索时间 2026-11-10。

| 来源 | URL | 对应数据 |
|---|---|---|
| PostgreSQL 官方新闻《PostgreSQL 19 RC 1 Released!》 | https://www.postgresql.org/about/news/postgresql-19-rc-1-released-3409/ | RC1 发布于 2026-10-15；11-12 的例行更新包含大量修复；RC2 与更新同天发布；把修复提前并入 19 的原因 |
| PostgreSQL 版本支持政策 | https://www.postgresql.org/support/versioning/ | 每个大版本 5 年支持期，14 的最后一个 minor 落在 2026-11-12 |

## 核验说明

- RC1 日期、RC2 与更新同日发布的安排，均直接取自官方新闻。
- 未做：没有在本机安装 19 RC2 验证；"GA 之后"没有写具体日期，因为公告原文的 GA 日期在抓取到的片段里被截断，不做推测。