PG18：生态与展望

学会了语法、性能、高可用与运维，最后一课是「格局」：PostgreSQL 之所以能在三十年后仍然是最具生命力的开源数据库，靠的不只是内核本身，而是环绕它的生态——可以热插拔的扩展体系、把内核打包成产品的发行版、覆盖所有主流语言的驱动、各司其职的运维工具链，以及一个以邮件列表和 Commitfest 为核心运转的开发社区。理解这个生态，才能在「用 PG」之外做到「用好 PG、并跟着它长期演进」。

本页同时承担另一个任务：收官。十八个阶段、上百个主题的旅程走到这里，我们把整条路线做一个回顾，并给出继续精进的地图。读完本页，你应当知道：一个需求出现时，先找扩展还是先改 schema；选发行版时比较什么维度；新版本发布前，去哪里看特性的「一手信息」而不是二手营销稿。

前置知识

建议先阅读：PG18：云原生与部署

基础概念

本系列三页快速导航

页面	主题	适合谁
核心新特性总览	异步 I/O、生成列、UUIDv7、OAuth、skip scan、EXPLAIN	所有使用者
云原生与部署	Docker、K8s、托管服务、备份与升级	运维与平台工程师
本页	扩展、发行版、驱动、社区与版本节奏	技术选型与长期规划

生态视角下的「云原生」

上一页给「云原生」开出了五条要求：数据可持久、实例可替换、配置可声明、故障可自愈、成本可伸缩。生态篇补上另一半答案——这五条的每一层，都对应着生态里的一类组件：持久化靠镜像的数据卷约定与存储驱动，可替换靠 Patroni/Operator 的拓扑管理，可声明靠配置参数体系与清单化，自愈靠 HA 工具与控制面，伸缩靠存算分离形态与分区/分片扩展。理解组件与诉求的对应关系，才能在选型时判断「我缺的是哪一层」，而不是把所有工具都堆上来。

生态分层图

层	内容	代表
内核	postgres/postgres 仓库里的那套代码	本教程十八阶段的主角
扩展	以 `.so` + 控制文件/SQL 脚本形式加载的能力包	PostGIS、TimescaleDB、Citus、pg_stat_statements
发行版	把内核 + 扩展 + 工具打包、验证、支持的产品	EDB、Percona Distribution、各云托管
客户端与驱动	各语言连接 PG 的库（多数基于 libpq 或纯协议实现）	JDBC、psycopg、node-postgres、Go pq/pgx
工具链	备份、监控、HA、开发管理工具	pgBackRest、Patroni、pgAdmin、pg_upgrade
社区	开发流程与治理	pgsql-hackers 邮件列表、Commitfest、GitHub

一张图记住这个分层的读写顺序：内核决定能力上限，扩展决定能力半径，发行版决定交付质量，驱动与工具链决定集成效率，社区决定长期演进速度。技术选型时逐层核对，比只看功能对比表可靠得多。

扩展为什么是 PG 生态的发动机

PostgreSQL 对扩展的定义极其克制：一个扩展就是「一个控制文件 + 一组 SQL 脚本 + 一个动态库」，通过 CREATE EXTENSION 装进数据库。内核提供稳定的 API（索引访问方法、钩子函数、后台 worker、FDW），扩展不必 fork 内核就能深度介入执行。这带来一个行业里罕见的良性循环：新能力先进扩展、在真实负载中打磨、成熟后再收编进内核（JSON、逻辑复制、并行查询都有这样的成长史）。PG18 延续了这条路：新增 pg_logicalinspect（检查逻辑快照）与 pg_overexplain（EXPLAIN 调试细节）两个内置扩展。

对使用者来说，扩展机制的实用推论是：扩展与内核是独立演进的版本线。扩展升级通常不需要重启实例，但扩展二进制与内核大版本是绑定的——这正是「升级内核前先盘点扩展」这条最佳实践的由来（见本章注意事项）。

发行版与「官方版本」的关系

官方源码只保证「内核 + 自带扩展」。EDB、Percona Distribution、云托管这类发行版的价值在于打包与责任：把它们验证过的内核版本、扩展组合、备份工具与支持合同绑定在一起交付。本教程的立场是：先理解原生生态，再评估发行版——因为发行版的差异主要体现在运维与支持层，而数据库能力本身（SQL、性能、高可用）仍由内核版本决定。

语法与用法

扩展的安装与管理（完整机制见 CREATE EXTENSION 与扩展机制）：

sql

-- 查看系统里可用（已安装文件）的扩展
SELECT name, default_version, installed_version
FROM pg_available_extensions
WHERE name IN ('postgis', 'timescaledb', 'pg_stat_statements', 'pgvector')
ORDER BY name;

-- 安装与卸载
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
DROP EXTENSION IF EXISTS pg_stat_statements CASCADE;

PG18 新增的扩展相关能力：

sql

-- extension_control_path：让扩展控制文件可以放在自定义目录（PG18 新增 GUC）
ALTER SYSTEM SET extension_control_path = '/opt/my_extensions:$extension_control_path';
SELECT pg_reload_conf();

-- pg_get_loaded_modules()：报告已加载动态库的名称与版本（PG18 新增）
SELECT * FROM pg_get_loaded_modules();

版本与环境自查（任何生态问题排查的第一步）：

sql

SELECT version();                     -- 内核版本
SHOW server_version;
SHOW server_version_num;
SHOW max_identifier_length;

bash

# 编译期信息：扩展与工具的开发者视角
pg_config --version
pg_config --pkglibdir
pg_config --sharedir

PG18 观测扩展的使用：

sql

-- pg_stat_statements 的 PG18 新列：并行 worker 计数与 WAL 缓冲写满
SELECT query,
       parallel_workers_to_launch,
       parallel_workers_launched,
       wal_buffers_full
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 5;

详细说明

扩展生态：PG18 的增量

PG18 在扩展基础设施上有四个值得记住的改动：

extension_control_path：新的服务端 GUC，允许指定扩展控制文件的搜索路径。从此扩展不必都挤在系统 share/extension 目录里，自研扩展可以放在独立目录树中，随应用一起交付。
PG_MODULE_MAGIC_EXT 与 pg_get_loaded_modules()：动态库可以自报名称与版本，管理员用一条 SELECT 就能看到当前加载了哪些扩展的二进制模块——排查「so 文件版本与 SQL 定义不匹配」这类问题不再靠猜。
扩展可注册自定义 EXPLAIN 选项：为「扩展执行的计划也要可解释」打开了门，复杂扩展（FDW、向量化引擎类）可以输出自己的计划细节。
扩展可使用服务端的累积统计 API：扩展的统计信息可以纳入与 pg_stat_* 同一套的归集与清零机制，而不是各自为政。

领域扩展的深度内容本教程已有专页，按需取用：空间数据见 PostGIS，时序场景见 TimescaleDB，分布式与水平扩展见 Citus。

pg_stat_statements：观测生态的中枢

几乎所有性能问题的第一站都是 pg_stat_statements，PG18 给它补了四块拼图（全部见于 release notes）：

CREATE TABLE AS 与 DECLARE CURSOR 的查询语句也被跟踪并分配 query id；
SET 语句的值被参数化归并——过去成百上千条「SET work_mem = '64MB'」「SET work_mem = '128MB'」各自占一行，现在归并为一类，统计质量显著提升；
新增并行活动列 parallel_workers_to_launch / parallel_workers_launched，与 pg_stat_database 的同名列呼应；
新增 wal_buffers_full 列，定位「WAL 缓冲写满导致的额外落盘」。

配合 PG18 内核侧的 query id 改进（常量列表只取首尾参与 jumble、按关系名归并查询），重复语句的归并更稳定了——这直接影响「基于 pg_stat_statements 做 Top SQL 告警」类实践的准确率。

FDW 与数据集成生态

跨库访问在 PG 里由 FDW（外部数据封装器）家族承担，PG18 给这一层补了几块实用拼图：

postgres_fdw / dblink 的 SCRAM 透传：postgres_fdw 新增 use_scram_passthrough 连接选项，把客户端的 SCRAM 认证「透传」到远端服务器，本地不再需要存储远端密码（配合 libpq 新增的 scram_client_key / scram_server_key 连接参数）；dblink 同样支持。「跨库凭据落库」这个长期安全负担有了官方解法。
postgres_fdw_get_connections() 新输出列：used_in_xact（当前事务是否在使用）、closed、user_name、remote_backend_pid——远端连接的观测粒度明显提升。
file_fdw 的容错导入：新增 on_error 与 log_verbosity 选项控制坏行的处理与报告方式，reject_limit 在 ON_ERROR = 'ignore' 时限制可忽略的坏行数量——批量导入「脏数据」终于不用整批失败。

安全类扩展与密码策略

安全向的扩展在 PG18 也有一批增量（均见于 release notes）：

pgcrypto：新增 sha256crypt / sha512crypt 算法、CFB 加解密模式、fips_mode() 函数报告服务端 FIPS 状态，以及 builtin_crypto_enabled 参数允许关闭内置非 FIPS 模式的加密函数——FIPS 合规场景的关键拼图；
passwordcheck：新增 min_password_length 变量控制最小密码长度；
权限查询：内核新增 pg_get_acl() 检索对象的 ACL、has_largeobject_privilege() 检查大对象权限，ALTER DEFAULT PRIVILEGES 支持大对象默认权限；预定义角色新增 pg_signal_autovacuum_worker（允许向 autovacuum worker 发信号）。

周边工具与扩展的小改进

一批「小而准」的生态改进（全部为 release notes 原文条目）：

工具 / 扩展	PG18 新增
pgbench	按脚本报告失败、重试、跳过的事务计数
pg_buffercache	新增 `pg_buffercache_evict_relation()` / `pg_buffercache_evict_all()`，可按关系或全量驱逐未固定的共享缓冲
amcheck	新增 `gin_index_check()` 校验 GIN 索引
btree_gist	构建索引前对值排序以加速
isn	新增 `weak` 服务端变量控制无效校验位的接受

逻辑复制生态的补充工具

PG16/17 把逻辑复制打磨成了迁移主力，PG18 把配套工具补齐：

pg_createsubscriber 新增 --all（为所有数据库创建逻辑副本）、--clean（清理发布）、--enable-two-phase；
pg_recvlogical 新增 --enable-failover 指定故障转移槽，--enable-two-phase 成为 --two-phase 的推荐拼写（后者弃用），且 --drop-slot 不再强制 --dbname；
新扩展 pg_logicalinspect 可以检查逻辑快照内容。

这些与内核侧的 max_active_replication_origins（原点数量与槽数量解耦）一起，让「物理副本转逻辑副本」「多源汇聚」的工程路径更顺。

发行版概览

以下只做定位描述，不评性能、不报版本号——发行版的能力随时间变化，以各家官方文档为准：

EDB（EnterpriseDB）：老牌商业发行版与支持商，围绕 PG 内核提供企业级支持与工具集，长期是社区代码的重要贡献方。
Percona Distribution for PostgreSQL：把内核与一组经过 Percona 验证的扩展、备份与监控工具打包发行，附 Percona 的支持服务，风格与其 MySQL 发行版一致。
云发行版：AWS RDS/Aurora、阿里云 RDS、GCP Cloud SQL、Supabase、Neon 等，把发行版进一步做成服务（部署、备份、监控、failover 全托管）。选型要点见上一页「云托管服务选型考量」。

一个务实的判断顺序：先明确你的团队要自己承担多少运维责任——全自建（官方源码/Docker 镜像 + 自组工具链）、半托管（发行版 + 支持合同）、全托管（DBaaS），责任边界从左到右逐级让渡，成本与灵活性反向变化。

客户端与驱动生态

本教程在十八阶段的客户端部分按语言写了六页驱动实战，覆盖了连接、事务、COPY、监听等主题：

语言	页面	底层路线
PHP	PHP 与 PostgreSQL	PDO / libpq
Go	Go 与 PostgreSQL	lib/pq 与 pgx（纯协议）
Python	Python 与 PostgreSQL	psycopg（libpq 与纯协议两种实现）
Java	Java 与 PostgreSQL	JDBC（纯协议）
Node.js	Node.js 与 PostgreSQL	node-postgres（纯协议）
Rust	Rust 与 PostgreSQL	tokio-postgres / sqlx（纯协议）

这些驱动的底层分两类：基于 libpq（复用官方 C 库的连接、认证、COPY 能力）与纯协议实现（自己实现前端协议，性能与异步模型更灵活）。

PG18 的协议与 libpq 变化直接影响驱动生态，值得客户端工程师了解：

线协议 3.2：取消请求密钥提升到 256 位（需要服务端与客户端都支持 3.2 才生效）；
libpq 新增 PQfullProtocolVersion() 与连接参数，可指定可接受的最小/最大协议版本；
search_path 变更会通知客户端：连接池与 ORM 场景下，「改了 search_path 但客户端缓存失效不及时」这类隐患有了协议层解法；
PQtrace() 输出覆盖全部消息类型（含认证），驱动调试体验更好。

驱动侧的对应支持节奏由各项目决定，升级服务端前查一下所用驱动的 changelog 即可。

扩展从哪里找

知道了扩展机制，还需要知道去哪里发现扩展：

内核自带扩展：contrib 目录随发行包提供，pg_available_extensions 一查便知——pg_stat_statements、pg_buffercache、amcheck、pgcrypto 都在这里；
PGXN（pgxn.org）：PostgreSQL Extension Network，社区扩展的公共仓库与分发网络，检索、评分、源码一应俱全；
扩展官方站点：PostGIS（postgis.net）、TimescaleDB（docs.timescale.com）、Citus（citusdata.com）等均独立维护文档与安装渠道；
发行版/云厂商目录：商业发行版会列出其验证过的扩展清单，托管服务则提供「可直接启用」的扩展列表——可用性以厂商文档为准；
自研扩展：借 PG18 的 extension_control_path 与 API/ABI 兼容性文档，内部扩展可以走独立的目录树与发布流程。

选型时的核对顺序：先确认目标环境「装得上」（镜像/发行版是否提供），再确认「用得好」（版本是否足够新、是否与你的 PG 版本兼容），最后才看功能契合度。

工具链：pgAdmin、pgBackRest、Patroni

工具	定位	本教程相关页
pgAdmin	图形化管理与开发客户端	—
pgBackRest	物理备份与 PITR 的事实标准之一	备份与恢复阶段
Patroni	基于 DCS 的高可用组件	Patroni 高可用

三个工具的分工值得一句话说清：pgAdmin 服务「开发与管理」（写 SQL、看执行计划、管理对象），pgBackRest 服务「数据安全」（并行物理备份、压缩加密、PITR、异地副本），Patroni 服务「可用性」（DCS 共识、自动 failover、拓扑管理）。三者互不替代——一个成熟的 PG 部署几乎总是三者（或同类替代品）齐备。选型时还有一个容易被忽略的维度：工具对大版本的支持节奏。PG18 发布后，备份工具、HA 组件、管理客户端各自需要时间适配；把「工具链对新大版本的支持矩阵」纳入升级核对表，可以避免升级日才发现工具不兼容。

PG18 给服务端工具也补了一批能力，升级后值得用起来：

pg_dump --statistics、--statistics-only / --no-statistics：统计信息可以独立迁移；
pg_upgrade --swap / --jobs：升级更快（见上一页）；
pg_createsubscriber --all / --clean / --enable-two-phase：把物理副本转逻辑副本的工具更完整；
pg_verifybackup 支持 tar 格式备份校验；
pg_combinebackup -k/--link：合并增量备份时可硬链接省空间；
vacuumdb --missing-stats-only：只补缺失统计；
pg_recvlogical --enable-failover：命令行直接创建故障转移槽。

psql 侧同样有一批新玩具：管道（pipeline）命令 \startpipeline / \syncpipeline / \sendpipeline / \endpipeline / \flushrequest / \flush / \getresults，命名预处理语句命令 \parse / \bind_named / \close_prepared，以及 WATCH_INTERVAL、扩展模式列表命令（\dx 显示 default_version）等。

监控与巡检工具生态

围绕 PG 统计视图长出了完整的监控工具生态，按「离内核多远」排一层：

内核统计视图：一切的原料。pg_stat_statements（Top SQL）、pg_stat_io（I/O）、pg_stat_activity（会话）与 PG18 的每后端 I/O/WAL 函数；
采集器：postgres_exporter（Prometheus 系事实标准，自定义 SQL 查询文件是它的灵魂）与各类轻量 agent，把视图变成时序指标——方案见 Prometheus 监控方案；
面板与告警：Grafana 上有大量成熟的 PG 看板模板，采用前先按 PG18 的视图变化校对每条查询；
商业可观测产品：在归并与诊断上更进一步（如按 wait event 聚合），按团队规模与预算选配；
wait event 采样类扩展：pg_stat_activity 只给瞬时快照，pg_wait_sampling 等社区扩展把等待事件变成时序分布，与内核视图互补。

一条通用规则：监控查询是「代码」，要随版本演进。每次大版本升级，把巡检 SQL 的回归测试列进升级清单。

阅读内核文档的正确姿势

PostgreSQL 官方文档（postgresql.org/docs）的结构值得花十分钟熟悉，它是所有二手资料的最终上游：

Part I~VIII 按用户旅程组织：教程（I/II）、SQL 语言（II~V）、服务端管理（VII）、扩展开发（VIII）；
Reference 部分是 SQL 命令、函数与工具的手册页，写脚本时对齐对应版本查阅；
Appendix E 是历代 release notes——本系列三页的主要信源；
每个「Supported Versions」标签页（18/17/16…）内容不同，跨版本写文档或脚本时，先切换到目标版本文档再核对。

PG16 → PG17 → PG18：三个版本的对照

把本教程覆盖的三个大版本并排看，演化脉络一目了然：

维度	PG16（2023-09）	PG17（2024-09）	PG18（2025-09）
关键词	查询与复制的精细化	运维能力的体系化	架构级升级
代表特性	SQL/JSON 增强等	VACUUM 内存重构、复制槽失效	异步 I/O、虚拟生成列、OAuth
本教程页	SQL/JSON 与新语法、逻辑复制增强	EXPLAIN 与维护、复制槽与故障转移	本系列三页
延伸阅读	聚合与统计、VACUUM 改进	大表导入、VACUUM 内存	云原生部署

规律可循：每一年，一批特性在「查询与写入路径」上打磨（16），一批在「运维与自愈」上补课（17），攒够的架构级债则用一个大版本偿还（18 的 AIO）。理解这个节奏，有助于你判断「这个能力会不会很快进内核」——也让「要不要等下一个版本再升级」这类问题有了可量化的答案：等的是特性合入与 beta 稳定，而不是发布日期本身。

给扩展开发者的一瞥

如果你不只「用」扩展还想「写」扩展，PG18 的内核为扩展作者准备了这些（release notes 原文条目）：

API/ABI 兼容性文档：官方文档新增了关于扩展 API 与 ABI 兼容性的章节，扩展作者的「支持矩阵」从此有章可循；
索引访问方法 API 新增：amgettreeheight、amconsistentequality、amconsistentordering 回调，自定义索引方法的表达能力增强；
累积统计 API 开放：扩展可以接入服务端统一的统计归集与清零机制；
自定义 EXPLAIN 选项：扩展可注册自己的 EXPLAIN 输出选项；
PG_MODULE_MAGIC_EXT 宏与 pg_get_loaded_modules()：动态库自报名称与版本，模块管理可观测。

另外，内核新扩展的源码本身就是最好的开发教材：pg_overexplain、pg_logicalinspect 的实现都很精悍，读一遍胜过十篇二手教程。

社区参与：从用户到贡献者

PostgreSQL 的治理结构非常独特：没有单一公司掌控，核心决策在 PostgreSQL Core Team 与开发者社区手中，日常开发在公开的邮件列表上完成。想跟进或参与，有三个入口：

入口	地址 / 形式	适合谁
GitHub	github.com/postgres/postgres	看代码、提 issue、体验现代化协作流程
pgsql-hackers	postgresql.org 邮件列表	内核开发的主战场，特性设计与补丁评审的公开记录
Commitfest	commitfest.postgresql.org	补丁的排队与评审看板，每个开发周期一个

注意 PG 的传统评审场所仍是邮件列表，GitHub 更多是镜像与便捷入口；即使不发言，只读 pgsql-hackers 也是学习内核演进最好的教材。Commitfest 上的补丁会经历「进入评审、修改、提交或退回」的完整生命周期——想了解「PG19 会有什么」，现在去翻开放条目，就能看到所有候选特性，这比任何自媒体的「新版本预览」都更早、更准。

作为使用者的最低限度参与也有价值：遇到 bug 按 bug 报告模板提交、在 release notes 页面用「Submit correction」表单反馈文档问题、给扩展仓库报 issue——开源生态的运转依赖这些小块头贡献。

三种典型技术栈参考

把生态层的内容收敛成三套「开箱组合」，供选型时对号入座（均为定性参考）：

组成	自建虚拟机栈	K8s Operator 栈	全托管栈
内核	官方源码/包仓库	Operator 提供的镜像	厂商维护
高可用	Patroni + etcd	Operator 内置拓扑管理	厂商内置
备份	pgBackRest / WAL-G	Operator 集成的对象存储备份	厂商快照 + PITR
监控	postgres_exporter + Grafana	同左（导出自定义查询）	厂商面板 + 指标导出
驱动	任选，自管版本	任选，自管版本	受厂商网络模型约束
你的责任	全部	应用与部分运维	应用与数据
适用起点	有 DBA 团队、合规要求高的组织	云原生基础设施成熟、追求自动化	小团队、快速起步、峰值弹性明显

三套栈没有优劣，只有责任边界的差异——选型时先画清楚这条边界。

术语中英对照

中文	英文
扩展	extension
发行版	distribution
外部数据封装器	FDW (Foreign Data Wrapper)
累积统计	cumulative statistics
提交节	Commitfest
邮件列表	mailing list
生命周期终止	EOL (End of Life)
线协议	wire protocol
查询标识	query identifier (query id)
物化视图	materialized view
外部表	foreign table

术语的英文原文值得记住——检索官方文档、邮件列表与 issue 时，英文关键词就是你的检索词。

版本发布节奏

官方版本政策（postgresql.org/support/versioning）很简洁：每年发布一个大版本，通常在 9 到 11 月之间；每个大版本获得 5 年支持（第 5 年的最后一个 minor 版本后 EOL）。minor 版本按季度左右发布，只含修复、不引入新特性，升级 minor 是零风险操作（pg_upgrade 都不需要）。

对节奏的实操理解：

时间点	社区动作	你该做什么
每年 3 月 / 7 月 / 11 月左右	Commitfest 流转，新特性陆续合入	关注感兴趣的特性进展
每年春末夏初	大版本进入 beta	在测试环境尝鲜、给扩展作者留适配时间
每年 9~11 月	大版本 GA（PG18 为 2025-09-25）	评估升级路径，通常等 `.1` minor 后再上生产
GA 后每季度	minor 版本	及时跟进（安全修复为主）
5 年后	该版本 EOL	必须在此之前完成升级

minor 升级（如 18.0 → 18.1）替换二进制后重启即可，数据目录完全兼容；major 升级则必须走 pg_upgrade、pg_dumpall 或逻辑复制三者之一。把这两条规则写进运维手册，可以避免绝大多数「要不要停机」的争论。

关于下一个版本 PG19 的当下状态与观察方式，见下文「展望：走向 PG19」。

展望：走向 PG19

按官方年度节奏，下一个大版本 PG19 将于 2026 年秋季发布。截至本教程写作时可以从官方渠道确认的事实是：PostgreSQL 19 已进入 beta 阶段（官方站点 2026-09-24 公告 Beta 4）。这意味着它已经「特性冻结」，剩余工作是修复与打磨，最终特性清单以届时发布的官方 release notes 为准。

在 beta 阶段，一个负责任的学习姿势是：

去 Commitfest 与 pgsql-hackers 看已经合入的补丁，形成自己的预期清单，但对外不做承诺；
在测试环境装 beta 版跑回归，尤其验证你依赖的扩展是否已适配；
关注 Migration 章节——它通常在 RC 前后才完整，是不兼容变化的唯一权威来源。

本教程对 PG19 的所有「展望」到此为止：不列特性、不猜日期、不下结论。十八个阶段的训练希望你带走的是方法——「官方文档核实、演练验证、灰度上线」，而不是背特性清单。

最后，用一句话给整部教程收尾：PostgreSQL 的每一步演进都在降低「把数据用对」的门槛，而生态与社区保证这条降低门槛的路会一直修下去。愿你在十八阶段之后，成为这条路的修路者，而不仅仅是赶路人。

十八阶段学习回顾

本教程以十八个阶段走完了 PostgreSQL 的「从入门到生产」。回头看，这条路线刻意遵循了「先会用、再懂原理、后能运维」的递进：

阶段	主题	关键词
一	入门指引	安装、psql、第一条 SQL
二	架构与核心概念	进程模型、目录结构、MVCM
三	数据类型	数值、文本、时间、JSON、数组
四	SQL 基础	DDL/DML、JOIN、聚合
五	高级查询	窗口函数、CTE、子查询
六	函数与操作符	内置函数、自定义函数
七	约束与索引	主键外键、B-tree/GIN/GiST
八	表设计与分区	范式、分区、继承
九	事务与并发控制	ACID、隔离级别、锁、两阶段提交
十	视图与规则系统	视图、物化视图、规则
十一	存储过程与触发器	PL/pgSQL、触发器、事件触发器
十二	配置与性能优化	参数体系、计划调优、EXPLAIN
十三	全文搜索与高级特性	FTS、扩展机制
十四	备份与恢复	pg_dump、PITR、灾备
十五	高可用与复制	流复制、逻辑复制、Patroni
十六	安全与权限	角色、RLS、加密、审计
十七	监控与运维	统计视图、慢查询、容量与升级
十八	客户端、实战与新特性	驱动、模式、PG16/17/18

如果按「阶段十八」的三组内容再压缩一次：PG16 的关键词是查询与复制的精细化（SQL/JSON 增强见 PG16 新特性、逻辑复制见 PG16 逻辑复制）；PG17 的关键词是运维能力（EXPLAIN 与维护见 PG17 新特性、复制槽失效与故障转移见 PG17 复制槽）；PG18 的关键词是架构升级（异步 I/O、虚拟生成列、OAuth，见 PG18 总览）。

三个版本的能力是叠加而非替代：PG17 的复制槽故障转移仍是 PG18 逻辑复制高可用的底座，PG16 的 SQL/JSON 增强仍是今天写应用层查询的日常。阅读新版本 release notes 的正确心态不是「旧版本白学了」，而是「新版本又垫高了一层地基」。

后续学习建议

回炉按需重读。遇到真实问题时按主题回查：性能问题先去十二与十七阶段，复制问题去十五阶段，本阶段三页是「版本地图」。
选定一条深耕线。应用侧选一门驱动深挖（含连接池与 pipeline），数据侧选一个领域扩展（GIS/时序/搜索/向量）做出真实项目。
建立版本跟进习惯。订阅官方 announce 邮件列表，每年 beta 期读一遍 Overview 与 Migration 两节，minor 版本按季跟进。
把演练制度化。备份恢复、failover、大版本升级三类演练每季度至少一次，比读十篇文章都有效。
留下自己的笔记。把你所在团队对每个版本的「踩坑记录」写进内部知识库——十八阶段的下一轮读者可能就是未来的你。

实战示例

示例一：盘点一套实例的扩展生态

sql

-- 已安装的扩展及其版本
SELECT extname, extversion
FROM pg_extension
ORDER BY extname;

-- 系统里可用但未安装的扩展
SELECT name, default_version
FROM pg_available_extensions
WHERE installed_version IS NULL
ORDER BY name;

text

      extname       | extversion
--------------------+------------
 pg_stat_statements | 1.12
 plpgsql            | 1.0
 ...

sql

-- PG18：看当前加载了哪些动态库模块（自报家门）
SELECT * FROM pg_get_loaded_modules();

示例二：用 pg_stat_statements 的 PG18 新列找「并行失效」的查询

sql

SELECT query,
       calls,
       parallel_workers_to_launch,
       parallel_workers_launched,
       total_exec_time
FROM pg_stat_statements
WHERE parallel_workers_to_launch > 0
  AND parallel_workers_launched < parallel_workers_to_launch
ORDER BY total_exec_time DESC
LIMIT 10;

「想启动的 worker 数 > 实际启动数」意味着并行度被资源上限（worker 池、内存）卡住——PG18 把这个差值直接变成了可查询的列。修复方向通常不是调大上限，而是确认是否有长事务占用 worker 池、或该查询本身不值得并行。

示例三：验证 SET 语句的参数化归并

sql

-- 两个会话分别执行
SET work_mem = '64MB';
SET work_mem = '128MB';

-- pg_stat_statements 中两条 SET 归并为一行（PG18 起）
SELECT query, calls FROM pg_stat_statements WHERE query LIKE 'SET work_mem%';

text

         query          | calls
------------------------+-------
 SET work_mem = $1      |     2

示例四：用 psql 管道命令体验协议能力

bash

psql "host=localhost dbname=app user=app" <<'PSQL'
\startpipeline
SELECT 1;
SELECT 2;
\endpipeline
\getresults
PSQL

text

 ?column?
----------
        1
(1 row)

 ?column?
----------
        2
(1 row)

pipeline 把多条语句一次性发出、减少往返——这正是 PG18 把 pipeline 能力下放到 psql 的意义：驱动与脚本终于能用同一套官方工具验证流水线行为。在为应用选型「要不要开 pipeline 模式」之前，先用 psql 验证服务端行为，是一种成本极低的尽职调查。

示例五：file_fdw 的容错导入

sql

CREATE EXTENSION IF NOT EXISTS file_fdw;
CREATE SERVER local_file FOREIGN DATA WRAPPER file_fdw;

-- PG18 新增 on_error / log_verbosity / reject_limit 选项（示意）
CREATE FOREIGN TABLE f_orders (
    id        bigint,
    amount    numeric(10,2)
) SERVER local_file
  OPTIONS (filename '/tmp/orders.csv', format 'csv', header 'true',
           on_error 'ignore', reject_limit '100', log_verbosity 'verbose');

SELECT count(*) FROM f_orders;   -- 坏行被忽略并记录，好行正常可查

过去 file_fdw 遇到一行脏数据就整批失败，只能「导前预清洗」；PG18 之后，「允许少量坏行的导入」有了内置开关。

示例六：pg_buffercache 的驱逐能力

sql

CREATE EXTENSION IF NOT EXISTS pg_buffercache;

-- 驱逐某个关系占用的未固定缓冲（PG18 新增），便于缓存相关的对照实验
SELECT pg_buffercache_evict_relation('orders'::regclass);

-- 或全量驱逐未固定缓冲
SELECT count(*) FROM pg_buffercache_evict_all();

做「冷缓存」性能实验时，这比重启实例优雅得多——过去只能重启或等自然淘汰。同理，pg_buffercache 的观测函数配合驱逐函数，可以精确回答「这张表占了多少缓存、驱逐后对延迟的影响有多大」——缓存相关的容量规划从估算变成了实验。

示例七：巡检一个「陌生」实例的生态画像

接手一套不熟悉的 PG 实例时，下面几条查询可以快速画出它的生态画像：

sql

-- 1) 内核版本与构建信息
SELECT version();

-- 2) 已装扩展及版本
SELECT extname, extversion FROM pg_extension ORDER BY 1;

-- 3) PG18：已加载的动态库模块（自报名称与版本）
SELECT * FROM pg_get_loaded_modules();

-- 4) 自定义配置从哪来（ALTER SYSTEM 写入 postgresql.auto.conf）
SELECT name, setting, source, sourcefile
FROM pg_settings
WHERE source = 'configuration file'
ORDER BY sourcefile, name;

-- 5) 参数覆盖了哪些默认值（升级时的变更面）
SELECT count(*) FILTER (WHERE source <> 'default') AS non_default_settings
FROM pg_settings;

几分钟内回答「这是什么版本、装了什么、谁改过配置」——这是接手任何生态的第一步。把这份巡检输出存档，还能为下一次大版本升级提供「基线快照」：升级前后各跑一遍，差异一目了然。

注意事项

扩展版本与服务端大版本要一起规划。 升级 PG18 前，逐个确认所用扩展在新大版本下的可用版本；扩展的 .so 是按大版本编译的，pg_upgrade 后必须使用与 PG18 匹配的扩展二进制。PG18 全文搜索还改用了集簇默认 collation provider 读取词典，非 libc 集群升级后官方建议重建全文/pg_trgm 相关索引。

pg_stat_io 与 pg_stat_wal 的口径变化会「弄坏」现有脚本。 op_bytes 被移除、pg_stat_wal 四列被删——依赖这些列的监控模板、报表要同步迁移，别等升级日才发现。

GENERATED ALWAYS AS 的默认语义在 PG18 变了。 这条注意事项值得出现在每一页 PG18 内容里：不写 STORED 的生成列 DDL 在 PG18 下是 VIRTUAL，行为不同。

扩展控制路径放开后要管好来源。 extension_control_path 方便了自研扩展分发，但也意味着「谁能写这个目录」成为新的安全边界；生产环境的路径配置应纳入配置管理并限制写权限。

Commitfest 上的特性不是承诺。 在 Commitfest 看到的补丁随时可能被退回或推迟；对外沟通「PG19 会有 XX」之前，等它真的出现在 release notes 里。

发行版/托管服务的能力滞后于内核。 PG18 发布不等于你用的托管服务当天可开 PG18，也不等于所有参数都能设置；以服务商的发布公告为准，不要按开源节奏倒逼供应商承诺。

生态工具的版本适配也要排期。 扩展、驱动、监控模板、备份工具各自有独立的发布节奏；内核升级日当天，「内核已就绪、周边没跟上」是常态——升级窗口的排期要把周边工具的适配验证算进去。

PGXN 与发行版仓库不互通。 PGXN 上的扩展未必进了你所用发行版或云厂商的目录；「能从 PGXN 下载」不等于「生产环境能安装」，安装渠道要提前验证。

社区渠道有各自的礼仪。 邮件列表偏好「先搜索归档再提问」、issue 偏好「可复现的最小案例」；违反社区规范的提问通常会得到礼貌但低效的回应。

最佳实践

把扩展当依赖管理。 用 pg_available_extensions 与版本清单记录每个环境「装了什么、什么版本」，升级大版本前先生成一张扩展兼容性核对表，逐项确认后再动内核。
优先扩展、慎重自研。 遇到「PG 好像做不了」的需求，先查扩展生态（本教程覆盖的 PostGIS、TimescaleDB、Citus 只是冰山一角），绝大多数轮子已经有人造好并且经过了更多负载的检验。
性能排查永远从 pg_stat_statements 开始。 用好 PG18 的新列（并行差值、wal_buffers_full、SET 参数化），它比任何 APM 都更贴近数据库真相。
统计信息纳入迁移与备份策略。 PG18 起统计可以用 pg_dump --statistics 独立迁移，升级与重建流程里把「统计恢复」当成显式步骤，别赌 autovacuum 的运气。
驱动升级与服务端升级绑排期。 协议 3.2、search_path 通知等能力需要客户端配合才能兑现；升级内核前查驱动的兼容公告，升级后回归连接池行为。
用官方渠道获取版本信息。 release notes、版本政策页、announce 邮件列表是一手信源；「PG19 惊天特性」类二手文章一律等官方确认。
每年一次「版本体检」：当前版本距 EOL 还剩多久、下个大版本的 Migration 有哪些条目影响自己、监控与巡检脚本是否引用了被移除的列。
从使用者升级为参与者。 从「给 release notes 提勘误」「给扩展报可复现的 issue」开始；有内核兴趣就直接读 pgsql-hackers 与 Commitfest，PG 社区对新人补丁的评审是出了名的认真。
发行版/托管服务的选择写进架构决策记录。 明确「自建 vs 发行版 vs 托管」的责任边界、理由与回退路径，一年后复盘时你会感谢这份文档。
保持十八阶段的循环：教程会过时，方法不会——「理解原理 → 官方文档核实 → 演练验证 → 生产灰度」这四步，是应对任何一个未来版本的方法论。
给扩展留出「降级方案」。核心业务若依赖某个第三方扩展，必须预先回答「扩展不可用时怎么办」——用原生功能降级实现，还是接受功能缺失；答案写进部署文档。
警惕「生态孤岛」。自研扩展、私有 fork、长期未跟上游的补丁集合会让升级成本随时间指数增长；每季度评估一次「能不能回归主线」。

继续学习：返回教程总览重新查阅或按路线复习

PG18：生态与展望 ​

基础概念 ​

本系列三页快速导航 ​

生态视角下的「云原生」 ​

生态分层图 ​

扩展为什么是 PG 生态的发动机 ​

发行版与「官方版本」的关系 ​

语法与用法 ​

详细说明 ​

扩展生态：PG18 的增量 ​

pg_stat_statements：观测生态的中枢 ​

FDW 与数据集成生态 ​

安全类扩展与密码策略 ​

周边工具与扩展的小改进 ​

逻辑复制生态的补充工具 ​

发行版概览 ​

客户端与驱动生态 ​

扩展从哪里找 ​

工具链：pgAdmin、pgBackRest、Patroni ​

监控与巡检工具生态 ​

阅读内核文档的正确姿势 ​

PG16 → PG17 → PG18：三个版本的对照 ​

给扩展开发者的一瞥 ​

PG18：生态与展望

基础概念

本系列三页快速导航

生态视角下的「云原生」

生态分层图

扩展为什么是 PG 生态的发动机

发行版与「官方版本」的关系

语法与用法

详细说明

扩展生态：PG18 的增量

pg_stat_statements：观测生态的中枢

FDW 与数据集成生态

安全类扩展与密码策略

周边工具与扩展的小改进

逻辑复制生态的补充工具

发行版概览

客户端与驱动生态

扩展从哪里找

工具链：pgAdmin、pgBackRest、Patroni

监控与巡检工具生态

阅读内核文档的正确姿势

PG16 → PG17 → PG18：三个版本的对照

给扩展开发者的一瞥