跳转到主要内容

这是本节的多页打印视图。 .

返回本页常规视图.

PIG 博客

文章、设计注记、发布注记与项目动态

PIG 的文章、设计注记、发布注记与项目动态 —— Pigsty 出品的 PostgreSQL 扩展包管理器。

1 - 文章

关于 PIG、PostgreSQL 扩展交付、Linux 打包与软件仓库供应链的长文。

这里收录 PIG 所要解决的问题：怎样发现 PostgreSQL 扩展，怎样把它们构建成原生 RPM/DEB 软件包，怎样发布可信的软件仓库，以及怎样通过实用的命令行工具把这些能力交给用户。

文章保留原始发表日期、当时的软件包数量、截图与上下文。当前行为请以 PIG 文档、 实时扩展目录与发布注记为准。

建议按以下线索阅读：

1.1 - SOW：论母猪的产后护理

维护一个 PostgreSQL 发行版，真正让人头大的是十万级制品背后的去重、索引、快照、原子切换与增量发布。SOW 用一个自包含二进制，把 RPM / DEB 仓库从目录脚本变成可恢复、可审计的状态系统。

今天老冯来和大家聊一聊《母猪的产后护理》。俺做的新开源项目 SOW，翻译成中文就是“老母猪”。

做一个 PostgreSQL 发行版，最折磨人的往往不是把软件编译出来，而是收拾编译出来的东西。

Pigsty 要为多个 Linux 发行版、多个 CPU 架构、多个 PostgreSQL 大版本维护成百上千个组件。不同组合一路展开，最终落到仓库里的制品超过十万个：RPM、DEB、索引、签名、校验和、快照，还有一堆为了兼容包管理器而存在的元数据。

用户看到的只是 apt install 或 dnf install。维护者看到的却是另一幅画面：你只更新了一个包，却必须保证另外九万九千九百九十九个对象没被误删；你只改了一份索引，却必须保证全球用户不会在切换瞬间读到一半新、一半旧的仓库。当仓库小的时候，这些事都像脚本题。仓库大到十万个制品之后，它突然变成了一道数据库题、分布式系统题，还是一道供应链安全题。

所以我写了 SOW —— 一个用 Go 编写的自包含 APT / YUM 软件仓库管理器。

SOW 中文项目主页

如果你只是想把一个目录里的 RPM / DEB 变成可用仓库，一条命令就够了：

sow create /www/pigsty

如果你要长期维护仓库，SOW 还提供 Managed 模式：一份包体投影成多个发行视图，记录期望状态与已构建状态，生成不可变快照，计算精确变更集，再增量发布到文件系统或对象存储。

一句话概括：SOW 把“生成软件仓库索引”这件小事，和“治理一个长期运行的软件仓库”这件大事，装进了同一个单文件工具里。

这个工具纯粹是为了解决老冯自己的问题。但如果你也在维护大型、跨 Linux 发行版的软件仓库，它应该也能帮到你——虽然有这类需求的用户大概不会很多就是了。

为什么叫 SOW？

这个名字值得单独讲讲。此前，我们做过另一个配套开源项目：Pig —— PostgreSQL Install Genius；它是 PostgreSQL 生态的包管理器。既然有小猪负责装包，那么制作这些包、承载、组织与分发软件制品的仓库工具，自然就是“母猪” SOW 了。

母猪造型的 USB 集线器

它还可以展开为 Software Object Warehouse —— “软件对象仓库”。这个来自工业史的词，正好严丝合缝地落进软件供应链；更妙的是，它还有另一层双关：在传统铸铁场里，铁水先流入一条主槽，再分流到两侧的小槽里，冷却成一块块铁锭。那些铁锭叫 Pig，承载和分配铁水的主槽叫 Sow。从上方看，一条大槽带着一排小铁锭，正像一头母猪带着一窝小猪。

Pig iron 与母猪、小猪命名的历史渊源

为什么要再造一个仓库工具？

最直接的诱因来自 Pigsty 的离线安装。Pigsty 会先把安装所需的 RPM / DEB 下载到本地，再生成一个离线软件仓库。过去，RPM 系统依赖 createrepo_c，Debian / Ubuntu 依赖 dpkg-dev。真正要生成的不过是几份 XML、Packages 与压缩索引，准备工具链却要装进几百 MB 的依赖。

这在 Linux 上已经够啰嗦；到了 macOS 上更难看。你得启动不同的 Linux 容器，挂载同一份目录，分别跑 RPM 与 DEB 工具，再把结果搬回来。为了生成几 MB 元数据，先请来几百 MB 工具链和一支容器车队，怎么看都不优雅。

Pigsty 使用 SOW 替换 RPM 与 DEB 仓库工具链

到了 Pigsty 4.5，我把这套冗余清掉了。SOW 是一个几 MB 级的自包含二进制，在 Linux 和 macOS 上都能直接运行，同时理解 RPM / DEB 包格式与 APT / DNF 仓库规范。它没有守护进程，也不需要额外的语言运行时。

但“少装几个工具”只是表面问题。真正让我决定把 SOW 做下去的，是仓库规模扩大后暴露出的四个痛点。

第一，硬链接救不了对象存储

同一个 noarch RPM 可能同时出现在多个架构仓库里，同一份包也可能进入 beta、latest、stable 等多个视图。放在本地磁盘上，可以用硬链接让许多路径共用一份 inode；上传到 Cloudflare R2、OSS 或其他对象存储后，每个 object key 都会变成一份实打实的存储与上传成本。文件内容相同，不代表云端知道它们应该共享所有权。

第二，十万个文件让“比较一下”都变得昂贵

仓库更新通常只变动几十个包，但传统同步工具为了确认这一点，往往要把十几万个文件重新遍历、比较、校验一遍。全量检查一次花十几分钟并不稀奇；真正的数据传输可能只有几秒，时间全耗在“什么都没变”的证明上。

传统仓库同步需要花费大量时间遍历和比较文件

第三，在线仓库不应该露出半成品

一个 RPM 仓库不只是 .rpm 文件；客户端先读 repomd.xml，再沿着它找到 primary、filelists 和包体。APT 同理：Release、InRelease、Packages 与 by-hash 文件之间有严格引用关系。

如果更新顺序错了，客户端就可能先看到新指针，却找不到新指针引用的对象。对维护者来说只是几秒钟的上传窗口，对全球随机到访的用户来说，就是一次无法复现的 404、校验失败或安装中断。

SOW 的自包含二进制与增量发布能力

第四，目录没有版本，发行版需要版本

最核心的问题是：当老冯想进一步改进仓库、提供 Channel 能力时，之前的维护模型就会遇到这些问题：如何同时维护 beta、latest、stable 仓库？如何每月保存一个快照？如何回答“上周三到底加了哪些包”？如何安全回退？哪些旧对象已经没有任何快照引用，可以删除？

这些需求单独看都能用脚本拼出来；组合到一起，脚本就会长成一套没有事务、没有模式、没有审计的影子数据库。市面上当然有 createrepo_c、dpkg-scanpackages、reprepro、aptly，也有通用同步与对象存储工具。但我没有找到一个足够轻、同时把 RPM 与 DEB、单份包池、不可变快照、原子发布和增量交付放进同一套清晰模型里的开源工具。

幸运的是，自己做工具的成本从来没有像现在这样低过。

两种复杂度，两种模式

SOW 并不假定所有仓库都需要同样的治理强度。它把问题切成 Plain 与 Managed 两层：小问题保持小，大问题才使用完整状态机。

Plain：包目录就是事实

Plain 模式只有一个核心命令：

sow create /srv/repo

# Pigsty 离线仓库兼容模式
sow create /srv/repo --pigsty

目录里的 RPM / DEB 是唯一权威事实，repodata/、Packages 与 Packages.gz 都是可以随时丢弃重建的投影。SOW 会并行扫描顶层软件包，每个包在默认路径上只打开一次，在同一遍里完成 SHA-256、解析和渲染所需事实的提取，再生成两种仓库元数据。

生成结果先进入同文件系统的私有 staging 区，经过 SOW 自己的解析器校验后再替换公开文件。最后，它只重新比较文件集合与 stat 快照，确认构建期间没有包被新增、删除或替换；不会为了“再放心一次”把所有大包重新哈希一遍。

SOW Plain 平面仓库文档

Plain 不保存操作日志，也不做沉重的事务恢复。进程中断了，就重新执行同一条 sow create：包目录还在，索引只是派生状态，重建比恢复更便宜。

--pigsty 模式还会最后写入 repo_complete 完成标记。只要这个标记不存在，消费方就知道这份仓库还没准备好。这是一个很小、但非常实用的提交协议。

这套模式解决了 Pigsty 最初的痛点：用一个小二进制替代两套工具链与多个容器，快速得到能被真实 APT / DNF / YUM 客户端消费的仓库。

Managed：仓库不是目录，而是状态机

长期运行的仓库不能只看“目录里现在有什么”。它还必须知道你 想要什么、上一次成功发布了什么，以及两者为什么不同。

SOW 的 Managed 模型分成四层：

SOW Managed 模式的四层结构

Workspace 是配置与发现边界；Repository 是所有权边界；Dist 是一个具名的 RPM 或 DEB 成员集合；Architecture View 只是渲染结果，不再拥有一份软件包。这里最重要的不变式是：在一个 Repository 内，每个软件包只有一份正典包体，不留副本。

repo/pool/...                              唯一包体
repo/dists/el9/x86_64/repodata/...         RPM 元数据视图
repo/dists/trixie/main/binary-amd64/...    APT 元数据视图

noarch RPM 或 all DEB 可以被投影进多个架构索引，却不会复制包体。beta 与 stable 也可以引用同一个软件包对象，而不制造第二份云端 object key。而且更妙的是，APT 和 DNF 仓库可以在同一套目录体系下管理。

SOW 的包池与 RPM、APT 元数据视图

“只存一份”的边界必须说准确：它是一个 Repository 或一个发布前缀，不是整个 Workspace、bucket 或全世界。不同 Repository 之间不做隐式去重，因为去重不能以破坏所有权为代价。删掉一个仓库，绝不能顺手删掉另一个仓库依赖的共享对象。

Desired、Built 与 Generation

Managed 模式把仓库状态拆成三个概念：

状态 含义
Desired 配置、加包、删包操作想要得到的成员集合
Built 上一次完整渲染、校验并提交成功的公共视图
Generation 对某个 Built 状态的不可变清单

这个区分看似学院派，实际上专门解决失败场景。

假设你一次加入五千个包，Desired 已经改变，但构建在中途被 SIGKILL。没有这层区分，系统只能面对一棵“不知道改到哪儿”的目录；有了它，SOW 可以诚实地说：意图已经更新，上一个 Built Generation 仍完整对外服务，新操作处于待恢复状态。

Generation 不是把整个仓库再复制一遍。它保存的是不可变 manifest、元数据与包体引用集合；多个快照可以引用同一份 Pool 对象。两代 Generation 之间的精确差异就是 Changeset：新增哪些包体、替换哪些元数据、切换哪些指针、哪些旧对象在保留期后可以删除，一目了然。

sow status  -r pigsty
sow changes -r pigsty
sow log     -r pigsty

所以增量同步不再从“重新扫描十万个文件”开始，而是从“比较两个已知 Generation”开始。

SOW 的 Plain 与 Managed 能力矩阵

原子切换的秘密：最后才动指针

软件仓库没有一个跨文件、跨对象的全局事务。SOW 的做法不是假装它存在，而是把发布顺序设计成可证明的协议：

payload  →  metadata  →  pointer  →  delete
 包体          元数据          指针          删除旧对象

先放入不可变包体；再写以 checksum 命名的元数据与 by-hash 索引；全部就位之后，最后才切换 repomd.xml、Release / InRelease 这些客户端入口。只有旧指针已经不再引用旧文件，并且保留期与证据门禁都满足，旧对象才允许删除。

因此，客户端沿着一个生效指针往下走时，它引用的内容一定已经存在。对单个协议视图来说，读者看到的要么是完整旧代，要么是完整新代，不会看到一棵被撕裂的树。

在本地 POSIX 文件系统上，这套过程依赖同盘 staging、fsync、原子 rename、稳定路径锁和持久操作日志。每条 Managed 写命令都会先检查并恢复上一次未完成操作，再开始自己的工作。恢复只根据已经落盘的证据判断该回滚还是前滚；证据矛盾时宁可中止并保持关闭状态，也不提供一个可能猜错的 repair --force。

对象存储不支持跨多个 Key 的原子提交，SOW 就先持久化 commit intent，再按确定顺序前滚协议指针，并为每个 target 单独保存 Applied Checkpoint。当前文件系统与 R2 发布各有自己的证据，前者成功绝不会被误认为后者也成功。R2 端如果缺少足够安全的条件删除证据，垃圾回收就只报告候选，不冒险远程删对象。

这也是 SOW 与一条 rclone sync 命令最本质的区别：传输文件不难，困难的是知道 哪些能传、何时算提交、失败后往哪边恢复，以及哪些真的可以删。

十万个对象，性能不能靠信仰

SOW 0.3 的主要工作，不是继续堆功能，而是把已经成立的模型推到真实仓库规模。

Plain 路径现在每个包只做一遍内容读取、哈希与解析，并通过 --jobs 使用有界并发。输入相同时，生成的元数据逐字节一致；无须更新时返回 no-op，也不会为了“更新一下时间戳”替换公开 inode。

Managed 路径则把解析后的“软件包事实”按不可变 SHA-256 缓存在 SQLite 中。新包入库时完整认证并解析一次；后续构建批量载入事实，在内存里完成成员投影。暖构建仍会遍历公开命名空间，但对未变化的 Pool 文件只检查 device、inode、size、mtime、ctime 指纹，不再把所有包体重新读一遍。指纹漂移时才回退到一次权威 SHA-256，并自动修复缓存；需要全量密码学审计时，显式运行 sow check。

这类优化的价值，必须落在数字上。

在项目基准中，一个包含 5,000 个对象的 Dist，成员展开从约 4.1 秒降到 33 毫秒；50,000 个对象原先十分钟仍跑不完，现在约 300 毫秒 完成。载荷提升也改成了有界单写入者组提交，每批最多 512 个对象或 1 GiB，既减少 fsync 风暴，也保证文件描述符和恢复状态不会随着仓库规模无限增长。

这些数字不是为了做一张跑分海报。它们只是说明：当仓库真的有十万个制品时，“状态模型正确”只是及格线，“日常小改动仍然足够便宜”才决定工具能不能被长期使用。

推倒第一版，再从最小闭环长回来

SOW 的开发时间不短，中间还经历过一次相当彻底的推倒重来。

最初那一版后来以 v0.1.0 留档。它野心很大：用 Git ref 管理仓库视图，用 SHA-256 CAS 保存制品，同时处理上游同步、多目标云发布、校验、修复、垃圾回收、Cloudflare Worker、CDN purge、边缘验证和生产迁移。

这些功能很多都已经做出来了，部分路径也通过了真实 APT / DNF 客户端与非生产 R2 环境的验收。但它的问题同样明显：仓库模型、云厂商、CDN、边缘运行时与迁移流程耦合得太紧。一项功能的正确性，要靠另外半套系统才能证明；任何小改动都会拖着一长串验收矩阵一起移动。

我最后决定把它封存。

推倒的不是目标，而是抵达目标的方式。一个基础设施工具最怕“什么都有一点，但没有哪一层能单独说清楚”。所以第二版先把最小闭环重新切出来：

  • P0 / Plain Create： 一个目录进去，一个可用仓库出来；
  • P1 / Managed Control Plane： Workspace、Repository、Dist、Membership、Build、Generation、Check、Changes 与 Operation Log；
  • 更复杂的同步、远端发布、CDN 与供应商控制面，逐项回到独立验收队列。

v0.2.0 建立了今天的 Plain + Managed 主体：单份包池、元数据视图、确定性构建、锁、日志、崩溃恢复、Generation、文件系统与 R2 发布。

v0.3.0 没有再造一层概念，而是集中清理旧 V1 运行时，收敛云端传输边界，并解决 Plain 与 Managed 在大仓库上的重复读取、逐对象查询、载荷提交和可观察性问题。当前正式二进制只依赖新的 V2 核心，旧实现留在 Git 历史与 v0.1.0 / v0.2.0 标签里，作为经验，而不是第二套事实来源。

这条路看上去比“一次憋个大的”慢，其实更快。每一层都有独立契约、失败语义和真实客户端验收，下一层建立在已经站稳的地基上，而不是建立在一份越来越难读的愿望清单上。

SOW 命令索引

接下来的 Roadmap

SOW 0.3 已经能创建仓库、管理成员与快照、计算变更集，并发布到文件系统和 R2；但它离我脑子里完整的软件制品控制面还有距离。

接下来主要有四条线：

  1. 上游仓库同步。 直接消费 APT / YUM 上游索引，验证签名与摘要，只拉取缺失制品，并把镜像结果纳入同一套 Package Object、Membership 与 Generation 模型。
  2. 更完整的增量交付。 现在 changes 与 target checkpoint 已经能描述、复用并只发布差异；下一步是扩展对象存储与同步供应商覆盖，把大规模远端 inventory、断点恢复、条件写入和安全删除证据做成稳定闭环。
  3. CDN 与缓存控制。 CDN purge 不是“调一下 API”这么简单，还要绑定精确 Generation、缓存 TTL、回执与失败恢复。V1 已经证明这条路可行，但它会以独立、可验收的模块重新进入，而不是重新和仓库核心焊死。
  4. 版本与保留策略。 beta、latest、stable、月度快照这些需求，现在已经可以用 Dist、Generation、retain 与 target 组合表达；后续还会补上更高层的策略编排，让常见发布节奏不必由外部脚本手工串联。

这些能力在第一版里大多已经有过实现。我不打算把旧代码整块搬回来，而会像 0.2、0.3 一样，一次只拿回一个边界清楚、能独立验收的能力。

不再憋大招，持续交付小而完整的闭环。

猪猪家族还在继续长大

SOW 是 Pigsty “猪圈宇宙”的一部分，而且这个命名体系已经越来越离谱，也越来越完整：

  • Pigsty：猪圈，负责安装和管理 PostgreSQL 生态；
  • SOW：母猪，负责组织、构建和发布软件仓库；
  • Boar：公猪，开发中的 PIGSTY GUI 管控平台；
  • Silo：筒仓，负责 S3 兼容对象存储；
  • Oink：猪叫，负责文档与网站框架；
  • Snort：猪拱，负责收集日志与监控指标。

这当然首先是一套命名梗，但它背后也慢慢长出了一条完整链路：SOW 整理制品，Silo 存放制品，Pigsty 把它们安装成系统，Snort 观察系统，Oink 把一切讲清楚。而 SOW 填上的，正是过去最容易被忽视的那一段。

软件仓库看起来只是一个能被 Nginx 托管的目录，但当它承载十万个对象、多个操作系统、多个架构与无数用户之后，它其实是一台没有界面的数据库：有对象、有关系、有版本、有事务、有日志、有垃圾回收，还有绝不能写错的提交指针。

SOW 做的事情，就是把这些隐含规则变成显式模型，把一堆“祖传脚本应该没问题”的侥幸，变成可以检查、恢复和审计的工程契约。如果你只想建一个离线仓库，可以从一条命令开始：

sow create /srv/repo

如果你也在维护一套长期运行的软件发行版，欢迎访问 SOW 项目主页，或直接阅读 使用文档，看看它更深的一面。

SOW 采用 Apache-2.0 许可证。当前 v0.3.0 提供 Linux / macOS 的 amd64、arm64 归档，以及 Linux RPM / DEB 安装包；可以从 下载页获取，也可以直接查看 源代码。

十万个包并不可怕。可怕的是，它们还只是十万个文件。

归档说明（2026-08-30）： 本文原载 vonng.com。文中的软件包数量、截图与上下文以原始发表日期为准；当前行为请以 PIG 文档和实时扩展目录为准。

1.2 - 上游没有的 Bug，为什么会出现在官方包里？

祖传 BUG 奇闻：一行打包补丁从 Debian Redis 传到 Debian Valkey，又被 Valkey 官方发布流水线整体搬了回来。上游源码本身没有这个 Bug，用户下载的官方 DEB 却有。

老冯最近在 Pigsty 里面更新了 Redis 模块，把 Valkey 也打包进来作为一个可选引擎，结果在打包的过程中发现了一个上游的 BUG。 我给 Valkey 和 Debian 上游提交了修复，本文记录了这个过程。

内存炸裂

先看一个天文数字：18446744073709518664。

如果你的 Valkey 某天在 INFO memory 里报出这么一个数字，别怀疑服务器突然长出了 18 EB 内存。 这是一个 64 位无符号整数从零以下减穿之后，绕回来的结果。

在修复前发布的 Valkey 官方 DEB 包中，如果一次同步 SAVE 因为磁盘满、权限错误或者只读文件系统而失败，实例记录的 used_memory 就会悄悄减少一点。 失败次数足够多，计数器便会从零以下回绕到接近 2^64 的天文数字。

此时只要配置了 maxmemory，那些受内存上限检查约束的写命令就会开始返回 OOM。进程的实际 RSS 可能完全正常，日志里也没有什么明显线索，但 Valkey 坚信自己已经用掉了十几艾字节内存，直到重启才会恢复。

同一份补丁如果用在内置私有 jemalloc 的构建上，后果更干脆：第一次失败的同步存盘，就可能直接把进程打崩。

在 这个修复前，Valkey 7.2、8.0、8.1、9.0、9.1 五条官方 DEB 产品线，在 Debian 12、Debian 13、Ubuntu 22.04、Ubuntu 24.04 和两种 CPU 架构上都能复现。 RPM 没带这份补丁，所以不受影响；原始的 Valkey 上游源码也没有这个问题。

触发条件并不算宽。持久污染主要发生在主进程执行同步 SAVE 时；BGSAVE 和周期性存盘发生在子进程中，错误不会把主进程的内存一并改坏。 但这反而让它更阴险：它专挑你已经出事的时候，在旁边再点一把火。磁盘已经满了，快照已经失败了，监控或者备份脚本又在那里不断重试。 原本只是一次存储故障，最后却变成了内存统计穿越、业务写入 OOM，或者进程直接崩溃。

有趣的是：这不是 Valkey 内核里的 Bug —— 它是打包环节制造出来的。

雷不在上游源码里

Valkey 在 RDB 落盘失败时，会把当前工作目录打印到日志里。上游原版使用栈上的固定缓冲区，不需要做任何动态内存管理。

Debian 的打包补丁把它改成了堆分配：

char *cwdp = get_current_dir_name();
serverLog(LL_WARNING, "... in server root dir %s ...", cwdp, ...);
zfree(cwdp);   /* 问题在这里 */

动机非常正常：不要在栈上放一个固定大小的 4 KB 数组，也不要依赖 PATH_MAX。

问题在最后一行。

get_current_dir_name() 返回的内存遵循普通的 malloc() / free() 语义；zfree() 却是 Valkey 自己的内存释放接口。它并不是给 free() 换了个名字，而是会先向分配器查询这块内存有多大，再从 Valkey 自己的 used_memory 账本里扣掉这笔数字，最后才执行实际释放。

这块内存从来没有通过 Valkey 的 zmalloc() 分配，进账时没有记在 used_memory 里，出账时却照扣不误。

这不是一次普通的释放器错配，而是一笔 只出不进的假账。

至于它是静默记错账，还是当场崩溃，取决于 Packaging 阶段选择了哪套 jemalloc。

Valkey 官方 DEB 使用操作系统发行版提供的 jemalloc。它接管了全局的 malloc() 和 free()，所以这块指针至少仍然落在同一个实际分配器中，错误释放通常不会立即崩溃；但 zfree() 仍然会错误修改 Valkey 的内存统计。如果你选择直接从源码编译，、或者链接了内置 jemalloc 的版本，那更干脆：一次失败的 SAVE 直接段错误挂掉。

同一份补丁，因为链接方式不同，一个表现为悄悄腐蚀计数器，另一个表现为第一次失败就段错误。

这就是很多人容易忽略的一件事：用户实际运行的软件，并不只由上游源码决定。编译参数、依赖库和分配器选择，同样会改变程序的行为。Packaging 从来不是把源码塞进一个 .deb 文件那么简单。

它是对软件做的最后一次改写。

一条补丁绕了九年

顺着这份补丁的历史往回翻，它的血脉可以追到 2017 年。那一年，Debian 开发者 Chris Lamb 给 Debian 的 Redis 包写了一份补丁，用动态分配的 get_current_dir_name() 替代固定大小的工作目录缓冲区。

这是一项很正常的打包改进，最初也没有那行有问题的 zfree()。

2020 年，Redis 的这份补丁中出现了相同的释放器错配，并触发了崩溃。Redis Issue #7927 和 Debian Bug #972683 记录了几乎一样的调用栈，Debian 随后删除了那几处错误释放。

后来，Debian 从 Redis 的打包体系中派生出了 Valkey 打包，这份补丁也跟着迁了过去。在后续演化中，zfree(cwdp) 又一次出现在 Valkey 的补丁里。同一个错误，沿着同一条补丁血脉，隔了几年重新活了过来。

2025 年 3 月，Valkey 维护者 zuiderkwast 在研究系统 jemalloc 支持时，已经当场看出了问题：前面走的是普通 malloc()，后面却用 zfree()，这会搞乱 Valkey 的内存统计。这个判断完全正确。只是当时他的注意力放在 system jemalloc 上，所以结论停留在 “统计会出错”，没有继续发现：如果启用这个补丁换成内置私有 jemalloc 后，这条路径会直接 Seg Fault。

到了 2026 年 4 月，Valkey 建立了一套官方自动打包流水线，覆盖多条版本线、RPM 与 DEB，以及 40 个操作系统和架构组合。为了快速获得成熟的 DEB 打包能力，官方仓库把 Debian 的打包文件和补丁栈搬运了进来。于是，一个原本只存在于下游发行版中的补丁 Bug，沿着下面这条路线走了一圈：

Redis 上游 → Debian Redis → Debian Valkey → Valkey 官方发布仓库。

Valkey 官方不是从自己的主仓库中引入了一个 Bug，而是从 Debian 那里把自己原本没有的 Bug 搬了回来。官方发布的 DEB 包因此获得了一项上游源码并不具备的 “特色功能”。这是整件事最有黑色幽默感的地方。

开源世界通常是下游从上游拿源码，再打上一些自己的补丁。到了这里，官方项目为了发布 DEB，又反过来从下游把补丁整体抄回来。它复制了 Debian 多年积累的打包经验，也复制了 Debian 补丁栈里遗留的错误。

后来 zuiderkwast 在我的 PR 下面直接问了一句：

Why did we copy Debian’s patches?

这个问题比那一行 zfree() 更重要，因为真正需要解释的，已经不再是“这一行为什么写错”，而是：

为什么一份脱离上游主干、缺少原始上下文的下游补丁，会未经完整功能回归，重新进入官方发布链路？

测试一直在，只是测错了层

这颗雷最终能被翻出来，不靠什么高深的静态分析。

靠的是跑测试，而且是 codex 去跑测试。

我在给 Pigsty 重新梳理 Valkey 的 DEB 打包时，例行跑了一遍上游自带的 runtest。unit/shutdown 当场挂了三个用例，服务端留下了一份崩溃报告。Pigsty 的包使用内置 jemalloc，所以我们正好落在“第一次失败便直接崩溃”的分支上。症状比官方 DEB 剧烈得多，反而更容易定位。

顺着调用栈往上翻，最后就翻到了 debian/patches 下面那行 zfree(cwdp)。

而那个失败的测试，写得非常有针对性：它故意创建一个名为 dump.rdb 的目录，让最后的 rename(2) 必然失败，从而进入这条冷门错误路径。这个测试早就写好了。只要运行，就能抓住问题。

为了确认不是偶然现象，我又让 Codex 把不同 Valkey 版本、不同补丁状态、不同分配器和两种 CPU 架构组合起来，做了一轮交叉构建与复现。原始上游源码测试全过；应用错误补丁后稳定崩溃；把释放函数改正确后，测试再次全过。

问题在于，Valkey 官方的打包流水线没有运行这套上游测试。这里需要说得更准确一点：官方流水线并非“完全没有测试”。它会检查软件包能不能安装，二进制是否存在，systemd 服务能不能启动，安全加固、兼容符号链接和卸载流程是否正常。这些都是合格的 Packaging 测试，也很有必要。

但 Debian 打包规则中的 override_dh_auto_test 是一个空目标，真正运行 Valkey 上游回归测试的命令被注释掉了；那些被注释的命令后面，甚至还跟着一个吞掉错误的 || true。它测了包装盒是否完整，测了开箱后机器能不能通电，却没有运行机器自己的自检程序。于是出现了一个非常典型的质量接缝：

上游没有测到，因为上游源码里根本没有这份补丁；打包流水线没有测到，因为它没有运行上游功能测试。

这个 Bug 正好活在两套质量体系之间。上游 CI 是绿的，打包 CI 也是绿的，官方包照常发布。三件事可以同时成立，因为两边测试的根本不是同一份东西。

修复只有一行，问题不止一行

技术上的最小修复非常简单：把 zfree(cwdp) 换成 zlibc_free(cwdp)。

Valkey 专门提供了 zlibc_free()，用于释放不属于 Valkey 自己内存账本的分配。直接调用 free() 反而编译不过，因为 Valkey 有意把 free() 标记成 deprecated，构建又开启了 -Werror。

这也很可能解释了当初为什么有人会写出 zfree()：作者试图修复一个真实的内存泄漏，先写 free()，被编译器挡了回来，于是换成了一个看起来最接近、又能通过编译的函数。

一个原本为了防止开发者绕过内存统计而设计的安全护栏，反过来把人推向了错误答案。

事情牵涉 Debian 和 Valkey 两边，我分别提交了 Bug 报告和上游 PR。给 Debian 报告时还被 Apple Mail 的富文本格式坑了一次：正文里的伪邮件头没有被 BTS 识别，第一封报告被系统整个忽略，切成纯文本才成功拿到 Bug 编号。

PR 很快获得批准，但 zuiderkwast 随后追问：既然这份补丁只是在一条冷门错误日志里避免使用 4 KB 栈数组，为什么还要保留它？这个问题问得对。我随后在 Pigsty 的 Valkey 和 Redis 包中直接删除了整份 Debian 打包补丁，重新构建并运行测试。用户可见行为没有变化，错误日志照常打印，测试全部通过，问题也随着补丁一起消失了。

这比把错误的 zfree() 换成正确的 zlibc_free() 更彻底。最安全的补丁，往往是根本不需要维护的补丁。

2026 年 8 月 7 日，修复 PR 被合并，五条版本线中的补丁副本全部得到修正。随后，维护者开始重新审视官方发布仓库中整套从 Debian 搬来的补丁。

但写到这里，这篇文章真正想讲的已经不只是 Valkey 了。

打包不是装箱

做 Pigsty 发行版越久，我越确信一件事：

打包不是把别人写好的软件装进纸箱，而是软件工程的最后一道生产工序。

用户最终运行的，从来不是 GitHub 上的那棵源码，而是下面这些东西共同组成的产物：

上游源码、下游补丁、编译器与编译参数、系统依赖、链接方式、默认配置、目录与权限、服务脚本、升级规则，以及最终到底跑了哪些测试。

一个软件包，实际上冻结了维护者对这些问题的全部判断。

好的打包可以弥补上游的不足：回补尚未进入稳定版本的修复，处理不同操作系统和依赖版本的兼容性，选择更稳妥的编译参数，修正默认配置，补齐服务管理、升级、回滚和安全加固。

坏的打包也可以反过来制造上游根本不存在的问题：补丁写错、编译参数改变语义、分配器换了一套、依赖库版本不匹配，或者干脆把最关键的测试跳了过去。

打包封装是最后一道质量防线

这起 Valkey 事故几乎把 Packaging 的作用演示得不能再清楚：

  • 上游源码本身没有问题；
  • 下游补丁引入了错误；
  • 编译时选择哪种 jemalloc，决定错误是静默腐蚀还是直接崩溃；
  • 官方发布流水线又把下游补丁复制到自己的包里；
  • 包级安装测试通过了，上游功能测试却没有运行。

同一个项目、同一个版本号，仅仅因为打包方式不同，用户得到的就可能是三种完全不同的行为。

这也是发行版存在的意义。

Pigsty 现在维护着几百个扩展和组件，打包仓库中的 patch 有一百多个。它们有些用于修复上游缺陷，有些处理不同 PostgreSQL 版本、操作系统、编译器和系统库之间的兼容问题，还有一些只是为了让软件真正符合生产环境的目录、权限和运维约定。

我坐在同一个火山口上。

所以这件事对我不是一则可以站在旁边点评的开源趣闻，而是一次非常直接的警告：每一份 patch 都应该被当成生产代码来审查；每一个最终生成的软件包，都应该在真实目标环境中重新运行上游测试；每一种编译参数和依赖组合，都可能产生不同的行为。

我愿意把话说得更难听一点：

没有测试最终交付的软件包，就谈不上真正支持这个软件。最多只是把一个二进制文件放进了仓库。

发行版的质量，也不应该用“收录了多少组件”来衡量。

更重要的问题是：这些组件到底有没有在目标系统上被正确构建，有没有运行完整的回归测试，升级和降级是否安全，默认配置是否合理，出错时能不能恢复，维护者是否清楚每一份补丁为什么存在、何时可以删除。

上游项目提供的是原材料。发行版交付的才是用户真正运行的产品。

所有人都做对了自己的那一步

复盘整条链路，会发现这件事里没有一个特别愚蠢的反派。

2017 年写补丁的人，是想避免固定栈缓冲区；后来加释放的人，是想修复真实的内存泄漏；free() 被禁止，是为了防止开发者绕开 Valkey 的内存统计；2025 年的维护者一眼就看出了错配，只是低估了不同构建方式下的后果；官方发布流水线复用 Debian 补丁，也是因为 Debian 长期以来以打包质量著称。

每个人都在解决自己眼前的问题。每一步单独看，都有合理解释。凑在一起，却变成了一颗进入五条官方产品线的雷。

这种事故最麻烦的地方，就在于它不属于某一个明确的责任域。补丁不在上游主仓库的日常 Code Review 中，不在上游 CI 测试的源码树里，也不容易出现在普通用户查看的 git log 中。它从 Redis 复制到 Valkey，从 Debian 复制到 Valkey 官方，每复制一次，原始背景就少一点。

上游认为这是发行版自己的改动；发行版认为这是一份继承已久的成熟补丁；官方打包认为 Debian 已经替自己做过质量把关；用户最终拿到的是编译好的二进制，压根看不到里面打过什么 patch。

三方都默认有人看过。结果是谁也没有完整地看。所以真正的问题不在某一个人，而在那个没人完整负责的交界面。而 Packaging，恰恰长期处在这样的交界面上。

Agent 最该干的，不是再写一堆数据库

今年 PGConf 上，我做完 Extension for Everyone 的主题演讲之后，PGDG APT 仓库维护者 Christoph Berg 问了我一个非常实际的问题：这么多包，你都是怎么测试的？

这确实是发行版维护中最难回答的问题。

一个人不可能手工检查几百个组件、多个 PostgreSQL 大版本、多个 Linux 发行版和两种 CPU 架构，更不可能把每个软件的冷门错误路径、升级路径和异常场景全部走一遍。

我的回答是：除了项目自带的构建与回归测试，我会让 Codex 对最终软件包再做一轮冒烟和场景测试。按照用户真实使用这个软件的方式去安装、启动、连接、执行操作、制造错误，再观察它会不会在某个不起眼的地方露出问题。

这次的 Valkey Bug，就是这样翻出来的。测试是 Agent 跑的，交叉构建矩阵是它搭的，历史补丁是它追的，Debian 报告和 GitHub PR 是它起草的。后来我又让另一个 Agent 对调查结论做对抗性审查，它又找出了几处过度概括和事实错误。

这并不意味着 Agent 可以自动给出正确答案。恰恰相反，它第一次经常也不对。真正的价值在于：让它反复验证、推翻自己、重新编译、重新复现的成本，已经低到了人类很难做到的程度。

还有一个颇有黑色幽默感的细节：Valkey 官方打包流水线在合并之前，也使用 Claude 做过代码审查，找出了不少 GitHub Actions、安全性和构建稳健性问题；但那颗藏在补丁里的 allocator Bug 依然漏了过去。

这不说明 Claude 不行，也不说明 Codex更聪明。区别在于任务。一个 Agent 在看流水线代码，另一个 Agent 把最终软件包真的构建出来、安装起来、运行起来，然后故意把它弄坏。前者做的是 Review，后者做的是实验。

而软件工程最终相信的，应该是实验。

现在 AI 圈最热闹的用法，是让 Agent 去 vibe coding，或者宣布要重写 PostgreSQL、重写 Redis、重写操作系统。这样的故事听起来宏大，也很容易吸引眼球。但在基础设施领域，真正稀缺的往往不是更多代码。

缺的是验证。

让 Agent 再写一套数据库，最后只会给世界增加一套新的代码、补丁、依赖和供应链风险；让它把现有数据库在几个发行版、多个版本、两种架构上，把正常路径、错误路径、升级路径和边界条件一遍遍跑完，没那么性感，却更接近真实的工程价值。

人类不愿意为一个内存计数器搭十几份编译环境，不愿意跑几十遍崩溃复现，不愿意翻九年的补丁历史，也不愿意为了确认搜索结果可靠，再专门设计一组对照实验。

Agent 不嫌烦。

你只要给它一个清楚的目标，它可以把这些过去性价比极低、因此长期无人问津的质量工作做到底。

这才是 Agent 在测试和发行版工程中最值得期待的用途：

不是帮我们生产更多未经验证的代码，而是把已经准备交付给用户的代码，验证得更彻底。

与其让 Agent 再写一个数据库，不如先让它把你准备发出去的每一个包，认真跑一遍。

现在，至少不再缺有耐心的测试者了。

《AGI 里程碑：不会放弃的机器》

归档说明（2026-08-30）： 本文原载 vonng.com。文中的软件包数量、截图与上下文以原始发表日期为准；当前行为请以 PIG 文档和实时扩展目录为准。

1.3 - 瞬间克隆 PostgreSQL 数据库，无需黑魔法

pig v1.5 新增 pig pg clone 与 pig pg fork，把 PostgreSQL 18 的瞬间克隆能力封装成 Agent Native CLI。

老冯在半年前（2026-01-08）写过一篇文章《Git for Data：瞬间克隆 PG 数据库与实例》，介绍了 PostgreSQL 18 和 Pigsty v4.0 的一个新特性：瞬间克隆新数据库。利用文件系统 CoW 机制，以及 PG 18 的 file_copy_method = clone 新参数，可以在秒级克隆一个非常大的数据库，而且不占用额外的存储。

这玩意儿其实非常适合 AI Agent 使用。我在《Agent 需要什么样的数据库》里提到过：极低成本的数据库克隆对于反事实推演至关重要。所以当时趁着 4.0 上线的时候，给 Pigsty 里 PG 数据库 Provisioning 的地方加上了这个功能。

《Git for Data》旧文截图

今天看到阿里云数据库 发了篇文章说，他们在阿里云 RDS for PostgreSQL 上支持这个功能了。老冯看了直想笑：这个动作也太慢了。说起来其实这个功能不复杂，不需要改内核，只要在 PG 18 上启用一个参数，在创建数据库的时候加一个 STRATEGY 参数就可以实现。说是不复杂，但想做好，还是有几个边界条件要处理。

一些改进

之前要克隆数据库的时候，在 Pigsty 的 IaC 式操作里还是有些繁琐：首先你要定义一个数据库，把另一个数据库作为模板，然后执行数据库创建。

所以这次我趁着 pig v1.5 发布的机会，把数据库克隆做成了一个简单易用的命令：pig pg clone。简单地说，现在你有个数据库 meta，只要执行 pig pg clone meta，它就会自动生成一个克隆。

执行 pig pg clone

当然，你可以使用参数来定制行为，比如指定分支的名字；如果不指定，就按下划线后加数字的方式依次自动起名。

克隆结果列表

命令会自动检测是否启用并支持瞬间克隆（目前用 Pigsty + XFS 就满足前提）。如果满足，就执行瞬间克隆；不满足，就警告、等待确认，并执行普通克隆。-y 可以跳过确认。

只要底层用的是支持 CoW 的文件系统（比如 XFS），那么克隆一个数据库基本是常数时间耗时，通常几百毫秒，而且占用空间不会变大；只有后续真实写脏的数据块，才会真正开始占用新的空间。

Agent Native CLI

当然，这个命令行工具的特点不一样：这是专门给 DBA 和 DBA Agent 设计的。之前你也可以用 Ansible Playbook，或者 Pigsty 提供的 Shell 脚本 /pg/bin/pg-clone 来执行克隆，但很显然都没有直接使用 pig 命令行工具方便。

Pigsty 克隆副本文档

比如，在执行操作之前，你可以使用 --plan 打印计划。它会告诉你会做什么事情、有什么风险。你还可以用 -o json 和 -o yaml 让它输出 JSON 和 YAML 格式的结果。

pig pg clone 计划输出

顺便一提，命令本体和 Help 输出也都可以使用 text、JSON、YAML 格式，因此 Agent 用起来会非常方便。因为它可以很轻松地用探索式方式，拿到所需的结构化帮助信息。pig 里所有命令都有这个功能。

pig pg clone 结构化帮助

这个设计，我之前称之为 Agent Native CLI，之前写了篇文章介绍过。

实例级 Fork

当然，除了 Database Clone，还有一个新的相关功能也值得一提。我在《Git for Data：瞬间克隆 PG 数据库与实例》里也提到过，就是实例级瞬间克隆，我将其称作 “fork”。

执行 pig pg fork

这里，你只要执行 pig pg fork dev，就能从当前实例创建一个名为 dev 的实例，随机分配一个新的端口号。这个功能在误删处理的时候非常实用：你可以先临时分支一个实例（不占用额外存储），然后快速用增量 PITR 回滚验证；验证无误之后，再在主实例上执行。

顺便一提，现在使用 pig 做 PITR 也非常方便。比如下面，一条龙傻瓜式执行时间点恢复到特定时间点，把时间点恢复的门槛压到了地板。当然，你也可以使用 pig pgbackrest 精准控制每一个操作。

执行 pig pitr

这次 pig 命令行工具发布，新增了很多管理功能，包括对 PostgreSQL、Patroni、pgBackRest 组件的各种管理。现在它们都封装成上面 pg clone 与 pg fork 这类 Agent Native CLI，同时方便人类 DBA 与 AI Agent 使用。过几天会专门写篇文章详细介绍一下。

PIG 瞬间克隆 PostgreSQL 工作流

参考阅读

归档说明（2026-08-30）： 本文原载 vonng.com。文中的软件包数量、截图与上下文以原始发表日期为准；当前行为请以 PIG 文档和实时扩展目录为准。

1.4 - 什么是 PostgreSQL 发行版？

从 Linux 发行版出发，聊一聊 “PostgreSQL 发行版“ 到底是个什么东西：三层工作、两条路线，以及一个核心。

经常有人问我：Pigsty 到底是什么？我通常回答：PostgreSQL 发行版。

通常下一个问题就是：那 “PostgreSQL 发行版” 又是什么？

这是个好问题。而要把它讲清楚，最好的切入点不是数据库，而是操作系统。

一、从 Linux 与操作系统发行版说起

说起 Distribution（发行版），绝大多数人第一反应都是 Linux 发行版 —— Red Hat、Debian、Ubuntu、SUSE、Arch…… 但问题是：既然已经有 Linux，为什么还需要 Linux 发行版？两者到底是什么关系？

答案很简单：Linus Torvalds 只写内核。

你把 Linux Kernel 编译出来，得到的不是一台能用的机器。你没有 Shell，没有 init 系统，没有 C 标准库，没有 coreutils，没有包管理器，没有网络工具，没有用户空间，也没有安全更新策略。内核负责调度硬件和提供系统调用，但它和 “一台能用的操作系统” 之间，隔着一整条工业化鸿沟。

这条鸿沟必须有人来填，而填的方式有无数种。用 glibc 还是 musl？用 systemd 还是 OpenRC？用 apt、dnf 还是 pacman？半年一版还是滚动更新？默认安全策略是什么？包怎么签名？漏洞怎么修？版本怎么维护？哪些服务默认启用 —— 这些选择叠在一起，才构成一个发行版。

Linux 内核与发行版组成关系

所以，发行版交付的不是内核。发行版交付的是一整套集成决策，以及对这套决策长期负责的信用。

没有人会说 Debian、Red Hat、Ubuntu 是在和 Linus 竞争谁更会写内核。它们竞争的是另一件事：谁能把共享内核变成更可靠、更一致、更容易交付的系统。

内核是公地，发行版是工业化交付。真正的价值与竞争不在内核，而在发行版上。没有人去和 Linus 竞争 “谁写的内核更好”，但 Red Hat、Debian、Ubuntu 在 “如何把内核集成为一套可用系统” 这件事上，打了整整三十年。

这正是理解 PostgreSQL 发行版的钥匙。

二、搬到 PostgreSQL：相似，但不相同

PostgreSQL 可以说是数据库世界的 Linux 内核，但如果直接把 Linux 这套逻辑搬到 PostgreSQL 上，第一步就会撞墙。

PostgreSQL 不是 Linux Kernel。PostgreSQL 源码编译出来之后 initdb 一下就能跑。SQL 引擎、事务、MVCC、WAL、复制协议、psql、客户端库，核心能力都在。 PGDG 官方仓库也直接交付构建好的二进制制成品，用户直接安装拉起来就能用。

Linux 内核不能直接用，但 PostgreSQL 的内核是可以独立运行的。这就带来一个尖锐问题：既然 PostgreSQL 自己已经能跑，PG 发行版到底还要解决什么问题？

Linux 与 PostgreSQL 从内核到发行版的类比

单机 PostgreSQL 是一个优秀的数据库内核。但生产系统要的不只是 “它能跑起来”，而是：主库挂了谁接管？备份坏了谁发现？误删数据能不能恢复到某个时间点？ 连接池怎么切流量？证书怎么轮换？监控指标怎么采？告警怎么判定？扩展版本怎么管？参数漂移怎么拉回来？升级怎么做？新副本怎么补？故障恢复之后谁把系统收口？ 这些都不是 initdb 和 yum install postgresql 能解决的问题。

PG 发行版的价值，就在这里。它不是把 PostgreSQL 变成可用的数据库系统（它本来就能用），而是把 PostgreSQL 内核集成为一套可生产运行的数据服务。

三、PG 发行版的三层工作

一个像样的 PG 发行版，至少要做好三件事：选择与集成、构建与分发、编排与管控。

这三层都重要，但它们的边际价值并不一样。越往后，越接近真正的战场。

1. 选择与集成：替用户做决定

生产 PostgreSQL 不是一个裸 postgres 进程。你要备份，要高可用，要连接池，要监控，要日志，要告警，要对象存储，要扩展，要权限模型，要默认参数 —— 每一个位置都有一堆选项。

备份可以用 pgBackRest、Barman、WAL-G，也可以用 pg_basebackup，甚至用 PG 备份原语手搓脚本。 高可用可以用 Patroni、repmgr、Pacemaker，甚至有人拿 PgPool 做主从切换。监控可以是 Prometheus、VictoriaMetrics、Grafana、Zabbix，随便排列组合都能拼出一套东西。

将 PostgreSQL 组成发行版的各个组件

所以这里考验的是发行版作者的品味、经验和责任感。 所谓 opinionated，不是拍脑袋替用户做主，而是你踩过足够多的坑，知道哪些路是正确的、更优的。

不过平心而论，这一层的价值正在收敛。好东西用久了，社区会形成共识：高可用越来越绕不开 Patroni，备份越来越绕不开 pgBackRest，监控越来越绕不开 Prometheus / Grafana 这类组合。 选型仍然重要，但单靠 “我选了正确组件” 已经很难形成护城河。

光会选型还不够，还要能可靠地交付。

2. 构建与分发：供应链是信任，不是噱头

第二层是构建与分发。这层经常被低估，因为用户只看到一个包名，很少看见后面那堆脏活：多系统、多架构、多版本、多扩展、依赖解析、ABI 兼容、GPG 签名、CVE 响应、仓库可用性、版本生命周期。

PGDG 已经做了一块很强的公共基础设施。PGDG 提供了 YUM 和 APT 仓库，提供预制的 PostgreSQL 内核、一百多个扩展，和一些关键的生态组件 —— 这是一块极好的公地。

也正因为这块公地已经很好，你要在构建分发层做出差异，就必须提供额外增量。比如 Pigsty 自己的仓库补齐了大量 PostgreSQL 扩展（额外的 300 个）和基础设施软件包，在 16 个 Linux 操作系统上提供原生的 RPM / DEB 包，已经持续维护了快四年。

PGEXT.CLOUD 扩展目录与软件包覆盖

打包背后的长期可信、快速修补、稳定供应链，以及长时间维护积累的可靠性战绩与历史信用，确实是一种壁垒，而且随时间沉淀累积。但这是一种守成能力：它能让用户放心把生产系统放在你的仓库上，却很难单独解释为什么用户非你不可。

真正把发行版和 “装包脚本” 拉开差距的，是下一层 —— 编排与管控。

3. 编排与管控：把静态包变成活系统

发行版中真正的硬骨头，其实是编排与管控。选型品味在收敛，构建分发只能守成，而编排与管控，是所有玩家真刀真枪见高下的地方。它的难点，一句话就能说清：如何让这些 “静态的包”，变成 “动态运行的服务”？

打个比方：软件仓库只负责给你面粉、鸡蛋和黄油，但如何把它们烹饪成一个蛋糕，仓库是不管的。哪怕再随包附赠一份详尽的食谱（也就是文档），离一个真正出炉的成品蛋糕，也还差着十万八千里 —— 更别提有的生产系统其实要的甚至是自动生产蛋糕的流水线了。

许多老牌开源发行版和云上 RDS 之间的差距，恰恰就落在这最后一步。 前者给你一堆装好的包，后者卖给你一个开箱即用、自动运维、故障自愈的服务。中间隔着的，正是 “编排” 这道谁都替代不了的工序。

这个 “烹饪” 的动作，就是编排（Orchestrating）—— 把一个静态的、类似 DVD 光盘介质的东西，变成一个运行时的、动态的、活的系统。它要操心的，全是 initdb 之后 PG 内核撒手不管、仓库也从不负责的那些事：一堆组件按什么顺序拉起、谁依赖谁；主库挂了怎么自动检测、选主、切流量、让连接池重连、把新副本补齐 —— 这一整条故障自愈的闭环；以及最关键的，如何让整个系统始终维持在你声明的那个目标状态，一旦漂移就自动拉回来。

PostgreSQL 发行版的基础设施层次

编排与管控这一维之所以是护城河，恰恰因为它 没有公地。没人替你把 “面粉鸡蛋” 变成 “蛋糕”，这活儿只能各家自己干，干得好坏，差距高下立判。

四、编排的两条路：K8s 原生与 Linux 原生

既然关键是编排，那么问题就变成：你把这套控制平面放在哪一层？

主流的答案有两条，它们构成了今天 PG 发行版最主要的两条赛道。分野的实质是 你选择在哪一层实现编排与管控：一条基于 Kubernetes 提供的公共底座，一条回到 Linux 操作系统本身从头构建。这两条路没有绝对的优劣，只有不同的利弊权衡。

赛道一：Kubernetes（云原生）

这条路把数据库当作 Kubernetes 上的一等公民，用 Operator 模式来编排。你写一份声明式的 CRD，Operator 通过它的控制器循环（reconcile loop），持续地把集群的现实状态收敛到你声明的目标状态 —— 拉起、监控、故障切换、扩缩容，都在 K8s 这一层完成。

这是目前 最拥挤、也最热闹 的赛道，玩家云集：CloudNativePG（EDB 主导，约 8900 Star，如今最主流的 PG Operator）、Zalando Postgres Operator（约 5200 Star）、Crunchy PGO（约 4400 Star）、KubeBlocks（约 3100 Star），以及 StackGres、Kubegres、Tembo、KubeDB、Percona Operator 等一长串。

这条路的优点很清楚：统一控制平面，声明式 API，GitOps 友好，平台团队容易接入。对那些已经把 Kubernetes 作为组织级操作系统的团队来说，数据库上 K8s 是自然延伸。

但代价也同样清楚：你不只是引入一个 PG Operator，你是在引入 Kubernetes 这整套控制平面、存储抽象、网络抽象、调度模型、权限模型、故障模型和心智负担。这条路真正的门槛，不在 Operator 本身，而在你是否已经为 Kubernetes 付过了那笔学费。

CloudNativePG 项目首页

赛道二：Linux 原生（原生操作系统）

这条路不把数据库塞进 Kubernetes，而是回到操作系统本身：直接跑在 Linux 上，运行于物理机或虚拟机环境，安装 RPM / DEB 包，通过 systemd 管理服务，使用 Ansible 或者类似的 IaC 工具发起管理。

这条赛道的开源玩家要少一些：Pigsty（约 5200 Star）、Autobase（约 4300 Star）、pgEdge（约 700 Star）、EDB TPA（约 90 Star）。此外还站着一整排没有公开 Star、但在企业市场分量十足的 商业发行版：EDB Postgres Advanced Server（EDB 旗舰，堪称 PG 世界的 Red Hat）、Percona Distribution、CYBERTEC PGEE、ClusterControl 等等。

这条路的优点是路径短，依赖少，离数据库本体更近，中间没有额外的抽象层，故障域更小，行为更可预测，也更容易被 DBA 直接理解和接管。它的代价则是：没有 K8s 替你处理状态收敛、幂等执行、故障恢复、升级编排，你得自己想办法实现，还要直面十几种主流发行版大版本之间的差异 —— 这是一份持续的、并不性感的苦役。

Pigsty 的选择

两条路各有其合理性，选择哪条取决于你的团队已经站在哪里、把复杂度放在哪里更划算。Pigsty 选择了 Linux 原生这条道路，理由我在《数据库是否应该放入 K8S 中》和《容器化数据库是个好主意吗？》里已经充分阐述过了 —— 我认为对于数据库来说，这是一条更贴合本质、艰难但正确的道路。

也正是在这条艰难的路上 —— Pigsty 跑在了前沿。如果看开源影响力，它已经是 Linux 原生这一侧的第一名（5200 Star，领先于同赛道的 Autobase ~4300）；放到包含 K8s 赛道在内的整个 PG 发行版版图里，它是第二名，仅次于 EDB 发起的 CloudNativePG。

PostgreSQL 发行版的 GitHub Star 与属性对比

今天你若问主流 AI 模型 “我要在 Linux 上自建企业级 PostgreSQL 服务”，Pigsty 基本已是首选推荐。对一个由独立开发者主导、不依附任何云厂商的项目来说，能走到这一步，确实不容易。

五、再往前一步：Meta Distribution

到这里，故事本可以收尾了。但 Pigsty 还做了一件更有意思的事，触及了 “PG 发行版” 这个词的边界。

业界有一个默认假设：一个发行版围绕某一个固定内核来构建。 Debian / RedHat 围绕 Linux，传统 PG 发行版围绕原生 PostgreSQL 内核构建，发行版和它的内核几乎是绑定的。

但 PostgreSQL 世界里有一批特殊存在：OrioleDB 换了存储引擎，Babelfish 做 SQL Server 协议兼容，PolarDB PG 做了 RAC，IvorySQL 兼容 Oracle 语法，还有兼容 MySQL 的 openHalo、提供透明加密的 Percona TDE 等等。它们改了 PG 内核，严格说已不再是 “纯 PostgreSQL”，而是 PG 兼容家族里的不同物种与亚种。按传统做法，每一个亚种都得各自造一套运维体系。

Pigsty 选择的是另一条路：把编排与管控的底盘抽出来，让内核本身成为可替换层。 这其实是前面第三层工作做到一定程度后的自然结果 —— 一旦你的控制平面足够灵活，不再和某个具体内核绑死，给它换一颗内核，就只是换一份构建产物和配置模板的事。我们为这些不同风味的 PG Fork 构建了二进制包并提供配置模板，让用户在同一套底座上运行不同内核，目前支持的内核已达 12+。

在这个意义上，它已不只是一个 “PostgreSQL 发行版”。你可以用它裁剪出自己的发行版 —— IvorySQL 发行版、PolarDB 发行版、TDE 发行版；甚至通过组合模块，让它摇身变成 Redis、Etcd、MinIO 的发行版，或是 Prometheus / VictoriaMetrics 乃至 Claude Code 与 Codex 的发行版。

Pigsty 提供的 PostgreSQL 分支内核

所以，更准确地说，它是一个 Meta Distribution，发行版的发行版。而一套能被这样反复裁剪、复用、再分发的底盘，本身就是一种可以被传递出去的能力 —— 它不再属于某一个内核，也不再只属于某一个人。

./configure                     # 默认使用 meta.yml 配置模板
./configure -c meta             # 显式指定使用 meta.yml 单节点模板
./configure -c rich             # 使用包含全部扩展与 MinIO 的富功能模板
./configure -c slim             # 使用最小化的单节点模板，只有 PG 高可用集群

# 使用不同的数据库内核
./configure -c pgsql            # 原生 PostgreSQL 内核，可选 531 扩展 (14~18)
./configure -c mssql            # Babelfish 内核，兼容 SQL Server 协议 (17)
./configure -c polar            # PolarDB PG 内核，Aurora/RAC 风格 (17)
./configure -c ivory            # IvorySQL 内核，兼容 Oracle 语法 (18)
./configure -c mysql            # OpenHalo 内核，兼容 MySQL (14)
./configure -c pgtde            # Percona PostgreSQL Server 透明加密 (18)
./configure -c oriole           # OrioleDB 内核，OLTP 增强 (16~18)
./configure -c agens            # AgensGraph 图数据库内核 (16)
./configure -c pgedge           # pgEdge 分布式数据库内核 (18)
./configure -c ha/citus         # Citus 分布式高可用 PostgreSQL (14~18)
./configure -c supabase         # Supabase 自托管配置 (15~18)

# 使用多节点高可用模板
./configure -c ha/dual          # 使用 2 节点高可用模板
./configure -c ha/trio          # 使用 3 节点高可用模板
./configure -c ha/full          # 使用 4 节点高可用模板
./configure -c infra            # 只安装监控基础设施与 Nginx，用于监控 & 建站
./configure -c vibe             # 配置 Claude/Codex + PGFS/Code 开发环境

尾声：发行版是一条信任的供应链

绕回最初的问题：什么是 PostgreSQL 发行版？

如果只从技术上拆，它有三项核心工作：选型与集成替你做对了决定，构建与分发把这些决定的产物送到你面前，编排与管控再把静态的包变成一个活的、自愈的系统。

但一个发行版真正的灵魂，其实在这三层技术之下。

因为技术是可以被复制的。选型可以抄，包可以照着打，编排的思路，只要有人肯花时间，也总能复刻个七八分。真正无法被复制、也决定了一个发行版能否被长期托付的，是两样东西：一个持续使用它、维护它的社区，和由此一点点长出来的信任。

因为用户真正需要的，从来不只是 “我该装哪个包”，而是：我信谁的包？信谁的默认参数？信谁的扩展构建？信谁的高可用判断？信谁的备份恢复流程？信谁在 CVE 出来后第一时间修补？信谁在五年之后仍然维护这条路线？信谁在系统漂移、故障切换、版本升级、数据恢复这些最要命的时刻，仍然能把整个系统收回来？

这一连串问句的答案，指向的都不是某段代码，而是 代码背后那个持续负责的人和社区。所谓发行版的本质，就是把散落在源码、构建、签名、仓库、扩展、配置、编排、监控、升级、故障恢复之间的责任，收束成一条可验证、可复现、可审计、可长期托付的信任供应链 —— 而信任，正是从这条链上一次次兑现的承诺里，一点点沉淀出来的。它买不来，也抄不走，只能靠一个社区用时间去长。

PostgreSQL 发行版整合构建、签名、仓库、编排、测试与维护

云服务当然也提供信任，只不过它把整条链条藏进了黑盒。你买到的是托管信任，但同时也交出了透明度、可迁移性和最终控制权。你相信云厂商会替你选对组件、打好补丁、做好备份、处理故障、规划升级，也相信它不会反过来在价格、权限、生态、合规、可用性上卡住你。这是一种信任，只是它的代价，是你不再看得见、也不再能自己接管这条链。

Pigsty 选择的是另一条路：不把复杂度神秘化，不把责任外包给不可见的控制平面，而是把这条链摊开、固化、签名、编排，并尽可能交还给用户自己掌控。所以它不是一个 “装 PostgreSQL 的工具”，也不只是一个 “自建 RDS 脚本”。它想交付的，是一套 开放的 PostgreSQL 信任供应链：从上游内核到扩展制品，从 RPM / DEB 仓库到高可用编排，从监控告警到备份恢复，从单一 PG 内核到整个 PG 兼容内核家族 —— 每一环都可核验，每一环都可接管，背后都有一个愿意长期维护它的社区。

Linux 发行版当年真正沉淀下来的，从来不只是把内核集成成系统的技术，而是 Debian、Red Hat 这些名字背后，几十年如一日 “一直有人在” 所积累起来的信用。Pigsty 想在 PostgreSQL 世界里长出的，正是这样一份信任 —— 并且让它是开放的、可审计的、可以自己接管的。

真正的发行版，最后交付的从来不是软件，而是一条可以被审计、被复现、被迁移、被长期托付的信任供应链，以及背后那个为它负责的社区。

不租云，不拜神，不把复杂度 —— 也不把信任 —— 放进任何人的黑盒子里。

而是把运行顶级生产数据库服务的能力，连同那个愿意为它长期负责的社区，一起交还给愿意自己运行它的用户。

归档说明（2026-08-30）： 本文原载 vonng.com。文中的软件包数量、截图与上下文以原始发表日期为准；当前行为请以 PIG 文档和实时扩展目录为准。

1.5 - 人人可用的 PG 扩展

介绍 PostgreSQL 扩展生态，并讨论其交付问题 —— 一个共享的交付层，如何同时让用户、扩展作者、厂商和 PostgreSQL 内核开发者受益。

在线幻灯片：人人都能用上的 PostgreSQL 扩展

第一部分：引言

0. 人人都能用上的扩展

00. 人人都能用上的扩展

大家好，这次演讲的题目是「人人都能用上的扩展」。

它讨论的是 PostgreSQL 扩展的交付，以及一个共享的交付层，如何同时让用户、扩展作者、厂商和 PostgreSQL 内核开发者受益。

00. 人人都能用上的扩展

1. 我是谁

01. 我是谁

我是冯若航，Pigsty 的作者和维护者。Pigsty 是一个开源 PostgreSQL 发行版。

我也是 pgext.cloud 的建设者。pgext.cloud 是一个面向 PostgreSQL 扩展的开源交付层。

过去两年里，我一直在为数百个扩展做编目、构建、打包和测试，覆盖不同 PostgreSQL 版本和 Linux 平台。所以这次分享不是理论推演，而是一份一线报告。

01. 我是谁

2. 可扩展性很重要

02. 可扩展性很重要

可扩展性很重要。两年前，我写过一篇文章，说 PostgreSQL 正在吞噬数据库世界。

当时的论点很简单：PostgreSQL 的成功源自可扩展性。它允许生态快速前进，而不必把每一个新想法都塞进内核。这是 PostgreSQL 的超能力。但它也带来了一个很现实的问题。

如果 PostgreSQL 是通过扩展来成长的，那么扩展交付本身就成了系统的一部分。

只有可扩展性还不够。一个扩展只有在能被发现、能被安装、能被信任时，才真正有意义。

这就是我开始收集和打包扩展的原因。

02. 可扩展性很重要

3. 两年之后

03. 两年之后

两年之后，我已经搭建了一套面向 PG 扩展的开源基础设施，叫 pgext.cloud。

今天，它覆盖 16 个 Linux 目标平台和 5 个活跃的 PostgreSQL 大版本。加上 PGDG 和 contrib，可交付的扩展集合大约有 511 个。

这个仓库每月提供大约一百万次下载。现在已有几家 PostgreSQL 厂商通过它交付自己的扩展。但这次演讲的重点并不是这个仓库本身。

真正重要的是，我们在维护这张矩阵时学到了什么。这才是我今天想分享的内容。

03. 两年之后

4. 谁会受益？

04. 谁会受益？

我说「人人都能用上的扩展」时，指的是四类人。

第一类是用户和 DBA。他们想要的是包，而不是在生产服务器上编译代码。

第二类是扩展作者。他们需要触达用户，也不想被构建和交付这些琐事拖住。

第三类是厂商。他们需要可复用的组件。反复重建同一批包，是对工程时间的浪费。

第四类是 PostgreSQL 内核开发者。他们需要信号。当兼容性被破坏时，扩展往往是最早暴露问题的地方。

所以这件事本质上是一个共享交付层。它不只是为了方便，也提供了可见性。在谈交付之前，我们先看一下生态本身。我们需要先理解，我们到底要交付什么。

04. 谁会受益？

第二部分：生态全景

5. 星系

05. 星系

PostgreSQL 到底有多少扩展？社区里有一个很有名的、由大家共同维护的 GitHub 列表，里面有一千多个条目。我维护的目录目前跟踪了大约 1,617 个条目。

但这个数字需要放在上下文里看。

有些项目仍然活跃，有些已经废弃；有些只能在云上使用；有些依赖专门的 PostgreSQL 分叉；还有一些只是想法和示例。所以，1,617 并不意味着有 1,617 个可以直接安装的扩展。

它意味着生态的边界很大，而且很乱。

05. 星系

6. GitHub 星标

06. GitHub 星标

第一个公开信号是 GitHub 星标。星标不能衡量质量，也不能衡量生产使用情况，而且会漏掉那些根本不托管在 GitHub 上的项目，比如 postgres 和 postgis。

但星标仍然有用。它反映了关注度、声誉和大致的认知度。排在前面的都是熟悉的名字：TimescaleDB、pgvector、Citus、pg_search、pgml、pgai、pgmq，还有很多其他项目。

如果观察分布，会发现它极度倾斜。少数扩展拿走了大部分关注度，后面是一条长尾。这是一个对数分布。

06. GitHub 星标

7. 星标分层

07. 星标分层

按数量级给扩展分组，就会得到一个简单的分层模型。

第零层：四大天王。PostGIS、TimescaleDB、pgvector、Citus，每个都超过一万星。

第一层：44 个扩展，星标在一千到一万之间。

第二层：大约 152 个扩展，超过一百星。

第三层：大约 373 个扩展，超过十星。

然后是约 748 个低于十星的长尾扩展。

这不是质量排名。有些热门项目已经不再活跃，比如 pgml 或 zombodb。有些低星扩展反而非常有用。

但这些层级说明了一件事：可见的生态要比被发现的生态小得多。把第零层到第三层加起来，大约是 570 个超过十星的扩展，和实际可交付的规模很接近。

07. 星标分层

8. 扩展漏斗

08. 扩展漏斗

于是我们得到了一个漏斗。顶部有 1,600 个候选项。如果砍掉长尾，数量会迅速下降。

中间大约有 500 个已经被编目、打包和交付。

按来源拆开看，大约 330 个来自 Pigsty 仓库，160 个来自 PGDG，两边还有一些重叠。最底部，是 PostgreSQL 自带的 71 个 contrib 扩展。

关键在于这个形状。发现面很宽，交付范围窄一些，实际使用又更窄。

08. 扩展漏斗

9. 维度分析

09. 维度分析

这个目录还跟踪星标之外的很多维度：语言、许可证、分类、最近发布日期、仓库状态、打包状态、PG 版本支持、操作系统支持。这里可以浏览 32 个不同维度。

现在，我们从「存在什么」转向「什么真的可以被交付」。

09. 维度分析

第三部分：交付层

10. 现状

10. 现状

打包 PostgreSQL 扩展很难。难点不是包格式有多神秘，而是矩阵太大。我们面对的是 5 个活跃 PG 大版本乘以 16 个 Linux 平台，也就是每个扩展 80 个构建槽位。真正覆盖全部槽位的扩展只有少数。

Christoph 和 Devrim 维护的 PGDG YUM 与 APT 仓库已经完成了基础工作。它们承载了许多最重要的扩展，总共大约 150 个包。但缺口仍然存在，比如 Rust 扩展，以及一些没有被覆盖的操作系统和 PG 组合。

所以这个互补仓库的目标，就是补上这些缺口。在 PGDG 覆盖不到的地方，或者构建成本太高、难以维护的地方，额外交付包。总体上大约新增 300 个扩展包。

10. 现状

11. 取舍

11. 取舍

这背后有一个真实的取舍。C 扩展构建得很快，Rust 扩展则不是。一个 Rust 扩展的构建时间，可能比所有 C 扩展加起来还长。

但用户仍然需要它们。比如自托管的 Supabase 栈大约需要十几个扩展，其中三个是 Rust 扩展。所以问题不是这件事有没有必要，而是这项工作应该放在哪里完成。

11. 取舍

12. 为什么要做 Linux 原生包？

12. 为什么要做 Linux 原生包？

容器镜像可以减少一部分矩阵。这一点我非常认可。有了容器，每个扩展只需要构建 5 个 PG 大版本乘以 2 个架构，也就是 10 个槽位，规模缩小了 8 倍。

但 Linux 原生包仍然很重要。很多用户仍然通过系统原生包管理器安装 Postgres，也就是 APT 或 YUM。而且大多数 Postgres Docker 镜像本身，也是从 PGDG APT 仓库安装 Debian 包形式的扩展。

所以，这些打包工作总要有人来做。

12. 为什么要做 Linux 原生包？

13. 基础设施

13. 基础设施

为了把这些 RPM 和 DEB 扩展包交付给用户，我们围绕它搭建了一套开源基础设施。它有四个部分：用于发现的目录，用于交付的仓库，一个可选的 CLI，用来简化访问。

在它们背后，是构建矩阵。CLI 很简单，仓库很有用，但目录和构建矩阵才是大部分工程成本所在。

13. 基础设施

14. 扩展目录

14. 扩展目录

目录是事实来源。它不是一个营销页面，而是一个带结构化元数据的数据库，描述扩展的一切：维度、标签、依赖、可用性矩阵，以及如何安装、配置、构建和使用的备注。

这听起来像是枯燥的脏活。但正是这些枯燥的元数据，让系统的其他部分能够可预测地运行。有了这些数据，你甚至可以让 Codex 用一句提示词重新生成扩展星系图。

14. 扩展目录

15. 目录细节

15. 目录细节

目录是交付路径的一部分。网站和 CLI 工具都把它作为事实来源。

目前这些元数据会定期导出为几个 CSV 文件。它有两个版本：一个 universe 版本，收集 1,600 个扩展的通用元数据；一个详细版本，覆盖其中 511 个扩展。

如果有一天，这类信息能放到 postgresql.org 上，成为官方扩展目录，我会非常高兴。现在它暂时放在 pgext.cloud 和 GitHub 上。

15. 目录细节

16. 目录页访问量

16. 目录页访问量

目录网站也会给出页面访问量数据。它不等同于生产使用量，但能告诉我们用户在看什么。这很有用。它能告诉我们哪些扩展值得优先投入打包精力，哪些类别正在活跃起来。

这里是过去一个月的扩展页面访问量数据。

16. 目录页访问量

17. 仓库

17. 仓库

要把这些扩展交付给用户，只有目录还不够。还需要一个仓库。

从技术上说，这个仓库是一个 APT 与 YUM 仓库，提供签名的 Linux 原生包，托管在 Cloudflare 上，并带有区域镜像。

这个仓库的目标是增强 PGDG 的 YUM 和 APT 仓库。它完全兼容 PGDG，遵循同样的约定，使用用户已经理解和熟悉的包布局。

17. 仓库

18. 仓库下载统计

18. 仓库下载统计

这个仓库现在每月大约提供一百万次 RPM 和 DEB 下载。

但这些数字有局限。它们不包括 PGDG 那一侧的数据。而 Cloudflare 在企业版之外不提供详细访问日志，所以我们缺失了很多数据。

如果 PGDG 仓库能够共享访问日志，或者至少提供一些聚合统计，我会非常欢迎。那会成为扩展生态里非常有价值的信号。

18. 仓库下载统计

19. 我们仍然可以推断什么

19. 我们仍然可以推断什么

即便下载数据是局部的、有偏的，它仍然有用。它可以显示哪些 PG 大版本仍然活跃，哪些操作系统目标重要，也可以显示某个包组合是否有足够使用量，值得继续维护。

但要小心。下载量少的包仍然可能很重要。也许我们需要一个综合信号，把星标、页面访问量、可用性、构建失败和下载量结合起来，形成类似 DB-Engines 风格的 PostgreSQL 扩展评分。

19. 我们仍然可以推断什么

20. CLI：PIG

20. CLI：PIG

有了目录和仓库，扩展交付基本上就解决了。你可以直接使用系统包管理器，从 PGDG 和 PGEXT 仓库安装扩展，比如 dnf 或 apt。

我们还有一个专用但完全可选的命令行工具，叫 PIG。它用 Go 编写，只有 4 MB。这个名字的含义是「piggyback on the OS package manager」，也就是借力系统包管理器。它会隐藏所有复杂度，让用户直接完成安装。

有意思的是，它不只是能安装，也能构建和交付二进制包。如果你想要 pg_search 或 pg_duckdb，只要运行 pig build pkg pg_search，它就会帮你构建包。

这对供应链信任很重要。用户愿意的话，可以自行重建所有东西。

这就是交付层：目录、仓库、CLI，以及它们背后的构建矩阵。纸面上看起来很清晰。但在实践中，矩阵才是真正困难的地方。

20. CLI：PIG

第四部分：野外维护

21. 扩展矩阵

21. 扩展矩阵

上一章我们谈到了矩阵：每个扩展 80 个槽位。

但 5 个 PG 版本乘以 16 个 Linux 平台，只是一个过度简化的模型。真实情况要混乱得多。它包含的因素远不止行和列。

在操作系统侧，有发行版家族、架构、大版本，有时还有小版本。

在 PG 侧，有大版本，有时也有小版本。

在扩展侧，有扩展版本；对于 Rust 扩展，还有 pgrx 版本。

把这些因素相乘，组合数量会非常快地爆炸。

本部分接下来要讨论的，就是这种爆炸式复杂度撞上现实之后，我们学到了什么。

21. 扩展矩阵

22. PG 小版本 ABI 破坏

22. PG 小版本 ABI 破坏

去年我们遇到过一个案例。PG 17.1 在小版本升级中破坏了 ABI，导致包括 TimescaleDB 在内的一些扩展出问题。

作为回应，一些维护者转向为每一个 PG 小版本构建。但这又会制造新的问题。如果每个小版本都单独构建，原地升级就会变得困难得多。

更好的办法是把它当作例外情况处理。但当它真的发生时，我们必须做好准备。

22. PG 小版本 ABI 破坏

23. 操作系统小版本破坏

23. 操作系统小版本破坏

有时候，即使是操作系统的小版本也会破坏构建。

例如，EL 把 OpenSSL 版本从 3.2 升到 3.5，一些扩展会在链接阶段失败。

作为回应，PGDG YUM 仓库最近修改了打包策略，从按大版本构建改为按小版本构建。所以现在我们有了 EL 10.0、10.1、9.6、9.7 的独立构建，而不只是 EL 10 和 EL 9。这又给矩阵增加了一个子维度。

23. 操作系统小版本破坏

24. Rust 问题

24. Rust 问题

Rust 扩展正在增长。它们给生态带来了新的人和新的想法。Rust 社区使用一个叫 pgrx 的框架来编写这些扩展，而这又引入了几个新问题。

第一是构建成本。Rust 构建很慢，也很吃磁盘。一个 Rust 扩展的构建时间，可能比所有 C 扩展加起来还长。

第二是 pgrx 自身也有版本，比如 0.16、0.17、0.18，而且它们并不能互换。我花了很多时间把 Rust 扩展对齐到特定的 pgrx 版本上，但随着时间推移，版本漂移又会回来。

所以 Rust 不只是增加了一门语言。它还增加了一条兼容性维度。

24. Rust 问题

25. 臃肿的扩展

25. 臃肿的扩展

过去扩展通常很小，典型大小只有几百 KB。现在不总是这样了。

一些新的扩展，比如 pg_search 和 pg_duckdb，体积有几十 MB。源码归档和构建产物都会迅速膨胀。放到完整矩阵里，这会变成真实的存储和带宽成本。

25. 臃肿的扩展

26. 命名冲突

26. 命名冲突

矩阵是一类复杂性，扩展之间的冲突是另一类。

去年，我讲过 Citus 和 Hydra 争夺同一个名字 columnar 的问题。今年我们又有了一个新例子：bm25。现在有三个扩展暴露了名为 bm25 的访问方法：

  • ParadeDB 的 pg_search
  • Timescale 的 pg_textsearch
  • TensorChord 的 vchord_bm25

和 Citus 与 Hydra 不同，这三个扩展可以一起安装。但你不能在同一个数据库里把它们全都创建出来，因为访问方法名称会冲突。

这不只是一个打包问题，而是生态元数据问题。如果目录记录的不只是包名，还包括扩展对象、库和访问方法，作者就可以在发布前检查冲突。

26. 命名冲突

27. 库冲突

27. 库冲突

另一个例子是，三个基于 DuckDB 的扩展都想使用同一个共享库：libduckdb。

包管理器看到的是磁盘上的文件。PostgreSQL 看到的是共享库和 control 文件。用户看到的是 CREATE EXTENSION。这三层的理解可能互相不一致。

实际解决方案，是把其中两个扩展作为 pg_duckdb 下面的子扩展挂载起来。这个方案能工作，但协调和说服作者花了真实的精力。

教训很简单：名字也是兼容性的一部分，而且名字真的会冲突。

27. 库冲突

28. API 破坏

28. API 破坏

我们也修复了很多缺乏活跃维护的扩展。有些扩展距离上一次发布已经过去多年。但 PostgreSQL 大版本变化仍然会影响它们。

通常，原作者会编写不同版本分支来处理不同 PG 大版本。如果扩展已经不再维护，打包者就必须接手。

前面我们讲过，这项工作如何帮助前三类人：用户、作者和厂商。那它对 PostgreSQL 内核开发者是否也有用？

我认为，构建覆盖率是一种有用信号。当一个补丁破坏了 N 个扩展时，这个数字本身就是信息。它显示了生态影响。这时，交付基础设施就开始变成反馈基础设施。

28. API 破坏

29. PG 19 兼容性

29. PG 19 兼容性

一个具体案例是，我用 PostgreSQL 19 的开发快照跑了一遍构建流水线。大约 50 个扩展构建失败。

这些失败集中在少数几类：真正的 API 变化、过时的假设、缺少版本分支、依赖问题，以及原本就已经很脆弱的包。

去年有些内核开发者告诉我，这对影响面很广的补丁可能有用，比如线程化工作、重构、hook 变化。如果 CI 流水线能针对某个补丁系列运行扩展构建，那么结果就可以成为补丁评审过程中的有用输入。

我很想听听在座各位的反馈：这件事值不值得继续推进？目标是让生态影响更早可见。

29. PG 19 兼容性

30. 让它可维护

30. 让它可维护

一个现实问题是可维护性。所有这些工作都是一个人在做。我经营着一家一人公司，也维护着一个一人发行版 Pigsty。这件事我已经做了大约五年。

最近它变得容易了一些，原因是 AI 工具。去年，每一个构建 spec 都是手写的。积累了足够多的示例之后，添加新扩展已经变得很直接。上个月我在两天内新增了 50 个扩展。

我的朋友 Yurii Rashkovskii 曾经描述过一个叫 PGPM 的想法：URL in, RPM out。给一个 URL，吐出一个 RPM。有了 Codex 和 Claude Code，这个想法正在变成现实。

AI 也降低了测试成本。我们可以从扩展文档驱动冒烟检查，更早捕获行为回归。AI 可能还没准备好提交 Postgres 内核补丁。但它显然足够胜任这类工作。我维护了一个 MinIO 分叉，用来修复 CVE 和 bug，几乎完全依靠 Codex 和 Claude Code。它真的跑在生产环境里。

这是一个维护者让 511 个扩展组成的矩阵继续活下去的办法。

30. 让它可维护

31. 三个问题

31. 三个问题

最后，扩展是 Postgres 生态的共同财富。我希望这项工作能帮助用户、作者、厂商和 Postgres 内核开发者，一起建设更好的 Postgres。

我想带着三个问题离开这个房间：

第一，哪些目录指标真正有用？页面访问量、下载量、包可用性、构建失败、最近发布日期、对象冲突。哪些应该被公开展示，哪些只是噪音？

第二，扩展构建覆盖率能否帮助补丁评审？它是否能作为 API、ABI 和行为变化的早期预警信号？

第三，其中一些元数据是否应该更靠近 PostgreSQL 社区基础设施？放在 postgresql.org 下，和 PGDG 放在一起，还是放在别的地方？

扩展是共同基础设施。交付是可扩展性的一部分。如果我们改善交付，PostgreSQL 的超能力就能触达更多人。

31. 三个问题

32. 致谢

32. 致谢

谢谢大家。

如果有任何问题，欢迎联系我。

32. 致谢

归档说明（2026-08-30）： 本文原载 vonng.com。文中的软件包数量、截图与上下文以原始发表日期为准；当前行为请以 PIG 文档和实时扩展目录为准。

1.6 - 504 个扩展，PG 生态的天花板在哪？

一个 Issue ，引发扩展马拉松；32 个新扩展告诉你，PostgreSQL 正在变成什么；504 个扩展，PostgreSQL 生态的天花板在哪？

一个 Issue ，引发扩展马拉松；32 个新扩展告诉你，PostgreSQL 正在变成什么；504 个扩展，PostgreSQL 生态的天花板在哪？

从一个化学扩展说起

两天前，一位用户在 GitHub 上给我提了个 Issue：他在用 RDKit —— 化学信息学领域的事实标准库，能在 PostgreSQL 里做分子结构存储、子结构检索和相似性计算。 但他发现 PGDG 官方打包的版本缺了 InChI 功能，他自己折腾了半天，加上编译参数后总算跑通了，但还是希望 Pigsty 能原生支持。

用户在 GitHub Issue 中请求为 RDKit 软件包启用 InChI 支持

但 RDKit 确实是个硬骨头。大约两年前我就试过一次，想把它收进 Pigsty 的扩展仓库，从 Debian 移植到 EL。 结果依赖太多了：Boost、Eigen、RapidJSON、Cairo，外加 InChI、Avalon 等可选模块， 每个都有自己的编译开关和操作系统默认库版本兼容问题。折腾了一会没跑通，就先搁置了。

但这次不一样。有 Coding Agent 了。

用 Codex / Claude Code 处理这类"构建系统考古"任务简直是降维打击 —— 以前需要反复试错的东西，现在基本一两轮对话然后等着就行了。 这次发布，把 PGDG 打包到 InChI 支持的问题也一并解决了，本质上就是编译时多开一个标志位再带上 InChI 源码。一把过，用户也很满意。

维护者回复并重新构建已启用 InChI 的 RDKit 软件包

说实话，看到这种反馈挺开心的。做开源最爽的就是这个时候。

趁热打铁

既然手热了，我就顺便把积压已久的几个"历史疑难杂症"也一起清了。

plv8：V8 引擎的 PostgreSQL 绑定，之前在 EL10 上死活编译不过，这次打了好几个补丁终于搞定了稳定构建。

duckdb_fdw：允许从 PG 内部读写外部 DuckDB 文件，但之前会和 DuckDB 官方的 pg_duckdb 扩展争抢共享库，我只能忍痛临时隐藏。这次把 duckdb_fdw 挂成了 pg_duckdb 的子扩展，共享同一份 libduckdb，冲突问题优雅解决，俩扩展又能并存了。

然后我就想：既然工具链都热好了，不如把 PostgreSQL 生态里剩下那些值得收录但一直没啃的扩展也一并搞进来吧。 于是就有了这次的大更新 —— 新增 32 个扩展，更新 22 个，Pigsty 扩展仓库总数正式突破 500，达到 504 个。

扩展目录: pigsty.cc/ext

分类 All PGDG PIGSTY CONTRIB MISS PG18 PG17 PG16 PG15 PG14
全部 504 155 332 71 0 481 488 479 473 457
EL 499 150 332 71 5 472 482 474 468 452
Debian 489 107 311 71 15 466 474 464 458 442

这五百个扩展中，一部分是 PG 自带的扩展（70个），PGDG 官方打包的扩展（150 个），剩下的 330 个都是老冯自己收录，打包，维护构建的第三方扩展。 基本上，Pigsty 在这个赛道上已经做到了前无古人，后无来者了。

这是啥概念？一般 RDS PG 上也就是几十个扩展。比如最近火爆的 Supabase 上，去掉 PG 自带的的 35 个 Contrib 扩展，实际上也就提供了 30 个不到的第三方 PG 扩展。

新扩展

这批新增扩展的画风相当硬核。按大类可以分四组：

数据域扩展：把化学分子、RDF 三元组、BSON、Protobuf、循环日程这些"复杂对象"变成数据库一等公民；

查询能力扩展：稀疏线代与图算法、Datalog 图查询、全文检索、混合排序融合、递归 SQL 模板引擎；

生产工程扩展： 深度可观测性、查询遥测导出、CDC 到 MQTT、COPY 命令拦截、DDL 逻辑复制补全、轻量分布式锁、软告警式数据质量管理；

开发者体验扩展： 会话变量、伪自治事务日志、自然语言时间解析

这些扩展共同指向一个趋势：PostgreSQL 的扩展层正在把数据库推向应用与数据平台的中间地带。很多原本需要独立服务才能解决的问题，现在可以在一条 SQL 事务边界内搞定。

这就是 PostgreSQL 极致可扩展性的魅力所在。

新扩展大观园

这次新加入了 32 个新扩展，下面的部分是请 Claude/Codex/Gemini 三剑客进行研究汇总摘要，用于帮助读者快速了解每个扩展的核心功能、技术实现和适用场景。

1. rdkit: 把化学信息学搬进 PostgreSQL

rdkit | GitHub

RDKit 是开源化学信息学领域的事实标准库，由 Greg Landrum 发起（最初在 Novartis，现属 T5 Informatics），其 PostgreSQL cartridge 模块将分子结构存储、子结构检索和相似性计算直接带入关系数据库。对于制药公司和化学研究机构而言，这意味着可以用标准 SQL 查询数百万化合物，无需借助外部工具链。

RDKit cartridge 引入了两组核心数据类型：mol（分子）和 qmol（查询分子，即 SMARTS 模式），以及 bfp/sfp（位指纹/稀疏指纹）。操作符方面，@> 用于子结构匹配，% 用于 Tanimoto 相似性判断，<%> 作为距离运算符。所有这些操作都可以通过 GiST 索引 加速——索引内部基于指纹筛选进行快速预过滤，再做精确匹配。关键函数包括 mol_from_smiles()、morganbv_fp()（Morgan 指纹）、tanimoto_sml() 等，配合 rdkit.tanimoto_threshold 等 GUC 参数可以调节检索灵敏度。

以 ChEMBL 数据库（187 万化合物）为例：

-- 子结构检索：查找含有特定骨架的分子
SELECT count(*) FROM rdk.mols WHERE m @> 'c1cccc2c1nncc2';
-- 结果：461 个匹配，耗时约 108ms

-- Tanimoto 相似性搜索：基于 Morgan 指纹
SELECT molregno, tanimoto_sml(morganbv_fp(mol_from_smiles('c1ccccc1C(=O)NC'::cstring)), mfp2) AS similarity
FROM rdk.fps JOIN rdk.mols USING (molregno)
WHERE morganbv_fp(mol_from_smiles('c1ccccc1C(=O)NC'::cstring)) % mfp2
ORDER BY morganbv_fp(mol_from_smiles('c1ccccc1C(=O)NC'::cstring)) <%> mfp2;

-- SMARTS 模式匹配：查找噁二唑或噻二唑类化合物
SELECT * FROM rdk.mols WHERE m @> 'c1[o,s]ncn1'::qmol LIMIT 500;

应用场景集中在药物研发的几个关键环节：先导化合物骨架搜索（在百万级化合物库中做子结构匹配）、SAR 分析（通过相似性检索寻找活性类似物）、化合物注册系统（利用结构指纹做重复性检查）、以及 商业化合物目录检索（如 eMolecules 的 600 万+化合物数据集）。

工程落地时需要注意：cartridge 的重点不在"能不能算"，而在"能不能被索引、能不能被 planner 正确利用"。索引策略与查询模板需要提前固定下来，否则很容易写出正确但慢的结构过滤。在 187 万化合物上子结构检索耗时在 88ms 至 1900ms 之间，经过优化可以处理 600 万+化合物 规模的数据集。BSD 许可证，Docker 镜像（如 mcs07/postgres-rdkit）和 conda 安装均已就绪。

2. provsql: 半环溯源让查询结果"可追溯"

provsql | GitHub

ProvSQL 由巴黎高等师范学校教授 Pierre Senellart 和 INRIA Valda 团队开发，发表于 VLDB 2018。它为 PostgreSQL 添加 (m-)半环溯源（semiring provenance） 和不确定性管理——能自动追踪每个查询结果是由哪些基础元组"推导"出来的，并支持在不同代数结构（布尔、安全等级、计数、概率）下对溯源信息进行求值。

核心机制是通过 PostgreSQL hook 拦截查询执行，为每个表自动添加一个隐藏的 provsql 列，存储指向溯源电路（provenance circuit）的 UUID。支持的 SQL 子集相当广泛：SELECT-FROM-WHERE、JOIN、GROUP BY、DISTINCT、UNION/EXCEPT、聚合、HAVING，甚至在 PG 14+ 上支持 INSERT/DELETE/UPDATE 的溯源追踪。核心函数包括 add_provenance() 启用追踪、provenance_evaluate() 对溯源进行求值、formula() 输出布尔公式、probability_evaluate() 计算概率。概率求值支持多种算法：从朴素求值到 Monte-Carlo 采样，再到 d-DNNF 编译（借助 d4、c2d 等外部求解器）。

-- 安全等级传播：查询结果自动继承最高安全级别
SELECT create_provenance_mapping('personnel_level', 'personnel', 'classification');
SELECT p1.city, security(provenance(), 'personnel_level')
FROM personnel p1, personnel p2
WHERE p1.city = p2.city AND p1.id < p2.id
GROUP BY p1.city ORDER BY p1.city;

-- 布尔公式溯源：每个结果行显示其推导公式
SELECT *, formula(provenance(), 'witness_mapping') FROM s;

-- 概率查询：计算每条结果的可信度
SELECT city, probability_evaluate(provenance()) FROM result;

ProvSQL 适合四类场景：安全分级传播——查询结果自动继承源数据中最高的安全等级；概率数据库——当基础数据带有可信度评分时，计算查询结果的正确概率；数据血缘审计——精确追踪每个结果行来源于哪些源元组，并支持 PROV-XML 标准导出；可信度评估——例如在刑事调查场景中，通过溯源加权评估目击者陈述的可靠性。

ProvSQL 的价值往往体现在"可组合性"：溯源结果不是字符串日志，而是可以继续被函数处理的对象。建议用于关键链路（核心报表/模型特征/合规计算），而非全库无差别开启。C/C++ 实现（依赖 Boost 库），溯源电路存储在共享内存中。支持 PG 10–18，MIT 许可证。

3. one_sparse: 在 SQL 里跑十亿边级图算法

one_sparse | GitHub

OneSparse 将高性能稀疏线性代数带入 PostgreSQL，封装了 SuiteSparse:GraphBLAS 库。开发者 Michel Pelletier 是 GraphBLAS C API 委员会成员，顾问团队包括 SuiteSparse 作者 Timothy A. Davis 教授（SIAM/ACM/IEEE Fellow）。核心理念是 将图表示为稀疏矩阵，用矩阵乘法实现 BFS、PageRank、三角中心性等图算法——而这一切都在 SQL 中完成。

扩展引入了 matrix（稀疏矩阵）、vector（稀疏向量）、scalar、semiring、monoid 等数据类型，以及 @（矩阵乘法/plus_times 半环）等操作符。图算法方面内置了 BFS（层级和父节点两种模式）、PageRank、三角中心性、度中心性、单源最短路径等，均来自 LAGraph 库。技术上，它将 GraphBLAS 的不透明句柄封装在 PostgreSQL 的 Expanded Object Header 结构中，小图（<1GB）使用 TOAST 存储，大图支持 Large Object 或文件系统。内置 JIT 编译器支持 NVIDIA CUDA GPU 加速。

-- 从 Matrix Market 文件加载图
SELECT mmread('/home/postgres/onesparse/demo/karate.mtx') AS graph;

-- BFS 遍历
SELECT (bfs(graph, 1)).level FROM karate;

-- 度中心性（矩阵列归约）
SELECT reduce_cols(cast_to(graph, 'int32')) AS degree FROM karate;

-- PageRank
SELECT pagerank(graph) FROM karate;

在 GAP benchmark 上，对 43 亿边 的图执行 BFS 时达到了 每秒 70 亿+边 的吞吐量（48 核 AMD EPYC 服务器）。应用场景包括金融反欺诈（交易网络环检测）、社交网络分析、Graph RAG 等。不过，这类扩展是否"真好用"，取决于数据装载/序列化格式是否与现有管道匹配，以及算子能否与 SQL Planner/并行执行相处融洽——建议先用小规模样例把端到端链路跑通。

OneSparse 要求 PG 18 Beta 或更新版本，当前处于 Alpha 阶段。Apache 2.0 许可证。

4. pg_datasentinel: 容器时代的 PostgreSQL 深度可观测性

pg_datasentinel | GitHub

pg_datasentinel 由 Datasentinel 公司的 Christophe Reveillère 开发，于 2026 年 4 月 10 日发布 1.0 版本。它为 PostgreSQL 添加了四大可观测性能力，填补了原生监控视图在容器化环境和运维预警方面的空白。

第一，扩展活动监控：在 pg_stat_activity 基础上增加每个后端进程的内存使用量、实时临时文件字节数，以及在 PG 18+ 上显示当前执行计划 ID。第二，容器资源可见性：报告 CPU 配额、内存限制、当前内存使用和 CPU 压力，适用于 Docker、Kubernetes、OpenShift 或任何 cgroup 管理的环境。第三，事务回卷风险预估：追踪 XID 和 MXID 消耗速率，提供到 aggressive-vacuum 和回卷限制的 实时 ETA。第四，日志捕获视图：将 vacuum、analyze、临时文件、checkpoint 事件记录到共享内存环形缓冲区，解析为结构化计数和计时信息，支持实时 SQL 查询。

-- 查看每个后端的内存使用（扩展 pg_stat_activity）
SELECT pid, usename, query, backend_memory_bytes, temp_file_bytes
FROM pg_datasentinel_activity;

-- 容器资源监控
SELECT cpu_quota, memory_limit, memory_usage, cpu_pressure
FROM pg_datasentinel_container_resources;

-- 事务回卷风险预估
SELECT xid_current, xid_limit, xid_eta_aggressive_vacuum, xid_eta_wraparound
FROM pg_datasentinel_wraparound;

对于在 Kubernetes 上运行 PostgreSQL 的团队，pg_datasentinel 提供了无需外部监控代理即可获得的容器级资源可见性。XID 回卷预警 功能对运维尤为关键——众所周知，XID 回卷会导致数据库强制关闭，而 pg_datasentinel 通过追踪消耗速率提供预测性告警，将"救火"变为"防火"。3-Clause BSD 许可证，要求 PG 15+。

5. datasketches: Apache 出品的亿级近似分析利器

datasketches | GitHub

Apache DataSketches 是 Apache 基金会项目（源自 Yahoo/Verizon Media），其 PostgreSQL 扩展将多种 近似分析数据结构（Sketch） 引入 SQL 世界。核心问题很明确：在海量数据上做精确的 COUNT(DISTINCT)、分位数计算和频繁项统计太慢或太耗内存。

扩展提供七种 Sketch 类型：cpc_sketch（Compressed Probabilistic Counting）、hll_sketch（HyperLogLog）、theta_sketch（支持集合交并差运算的去重计数）、aod_sketch（Tuple sketch）、kll_float_sketch/kll_double_sketch（分位数估算）、req_float_sketch（尾部高精度分位数）、frequent_strings_sketch（频繁项）。每种 Sketch 都提供 *_sketch_build()、*_sketch_union()、*_sketch_get_estimate() 等标准接口。

关键点不是"有个函数返回估计值"，而是 Sketch 作为 可序列化对象可以被聚合合并，因此特别适合数据立方体式的近似指标：按维度切片预聚合 Sketch，查询时按任意维度组合做 union 即可得到去重数。Sketch 在内存中是 亚线性 的，且可跨语言（Java、C++、Python、Rust、Go）做二进制兼容序列化。

-- 近似去重计数：比精确 COUNT(DISTINCT) 快约 6 倍
SELECT cpc_sketch_distinct(id) FROM random_ints_100m;
-- 结果：63423695（精确值：63208457），耗时 ~20s vs 精确 ~2min

-- Theta Sketch 集合运算：计算两个用户群体的交集
SELECT theta_sketch_get_estimate(
  theta_sketch_intersection(sketch1, sketch2)
) FROM theta_set_op_test;

-- KLL 分位数估算：获取中位数
SELECT kll_float_sketch_get_quantile(sketch, 0.5) FROM kll_float_sketch_test;

-- 多维度聚合 + Sketch 合并
SELECT cpc_sketch_get_estimate(cpc_sketch_union(respondents_sketch)) AS num_respondents, flavor
FROM (
  SELECT cpc_sketch_build(respondent) AS respondents_sketch, flavor, country
  FROM (VALUES (1,'Vanilla','CH'),(1,'Chocolate','CH'),
               (2,'Chocolate','US'),(2,'Strawberry','US')) AS t(respondent, flavor, country)
  GROUP BY flavor, country
) bar GROUP BY flavor;

典型应用：实时 UV 统计——不存储用户 ID 即可跨时间窗口合并去重；分布分析——在数十亿事件上计算 p50/p95/p99 延迟而无需排序；受众重叠分析——用 Theta Sketch 的交集运算计算"看过广告 A 且访问过网站 B"的用户数。在 1 亿行数据上，CPC Sketch 的去重计数约 20 秒完成（精确 COUNT(DISTINCT) 约 2 分钟），相对误差在个位数百分比范围内。

6. pghydro: 巴西国家水务局的排水网络分析引擎

pghydro | GitHub

PgHydro 由巴西国家水务卫生局（ANA）的 GIS 专家 Alexandre de Amorim Teixeira 开发，构建在 PostGIS 之上，被 ANA 作为水资源管理的官方工具在全国范围内使用，也在 FOSS4G 2022 上做过展示。

核心能力围绕水文网络的完整工作流展开：从原始 GIS 数据的导入和一致性校验，到流向计算、Otto Pfafstetter 流域编码（一种国际通用的分层流域分类系统）、上下游分析、汇水面积计算、Strahler 河流分级等。架构上采用模块化设计，包含五个子扩展：pghydro（核心）、pgh_raster（DEM 栅格分析）、pgh_hgm（水文地貌特征）、pgh_consistency（拓扑一致性校验）和 pgh_output（数据导出）。

-- 导入排水线数据
SELECT pghydro.pghfn_input_data_drainage_line('public', 'input_drainage_line', 'geom', 'nome');

-- 计算流向并反转不一致的河段
SELECT pghydro.pghfn_CalculateFlowDirection();
SELECT pghydro.pghfn_ReverseDrainageLine();

-- 计算 Pfafstetter 流域编码
SELECT pghydro.pghfn_Calculate_Pfafstetter_Codification();

-- 计算上游汇水面积和到入海口距离
SELECT pghydro.pghfn_CalculateUpstreamArea();
SELECT pghydro.pghfn_CalculateDistanceToSea(0);

-- Strahler 河流分级
SELECT pghydro.pghfn_calculatestrahlernumber();

适用于国家级水文数据库管理、流域规划与编码、上下游污染影响分析（如确定某污染源上游的所有河段）、以及排水网络拓扑一致性验证。它更像一套专业领域的数据库内 ETL/分析流水线——数据在 PostGIS 中管理，分析过程可在 SQL 里自动化，当原始地形/河网数据更新时，按函数流水线重算比手动脚本更可靠。配合 QGIS 的 PgHydroTools 插件可实现可视化操作。完全用 PL/pgSQL 编写，GPLv2 许可证。

7. pg_stat_ch: ClickHouse 官方出品的 PostgreSQL 查询遥测

pg_stat_ch | GitHub

pg_stat_ch 由 ClickHouse 公司开发并开源（2025 年 2 月，“Postgres Week at ClickHouse"活动），作者是 Kaushik Iska。与 pg_stat_statements 在 PostgreSQL 内部做聚合统计不同，pg_stat_ch 将 每条查询的原始执行事件（包含 45 个字段、固定 4.6KB）实时流式导出到 ClickHouse，让所有聚合分析（p50/p95/p99、Top 查询、错误分析）在 ClickHouse 的分析引擎中完成。

数据管道架构为：PostgreSQL Hooks（前台）→ 共享内存环形缓冲区 → 后台 Worker → ClickHouse。45 个遥测字段覆盖查询计时、行数、缓冲区使用、WAL 使用、CPU 时间、JIT 指标（PG15+）、并行 Worker 统计（PG18+）、客户端上下文（应用名、IP）、错误捕获（SQLSTATE 码）等。扩展使用 ClickHouse 原生二进制协议加 LZ4 压缩，静态链接 clickhouse-cpp 库。为避免对 PostgreSQL 造成背压，队列溢出时丢弃事件（计数器记录丢弃数）而非减慢数据库——与 StatsD 的设计哲学一致。

-- PostgreSQL 侧：监控扩展健康状态
SELECT * FROM pg_stat_ch_stats();
-- 返回：enqueued, exported, dropped 计数，最后成功/失败时间戳

-- ClickHouse 侧：过去 1 小时按应用统计 p95/p99
SELECT query_id, count() AS calls,
       quantile(0.95)(duration_us) / 1000 AS p95_ms,
       quantile(0.99)(duration_us) / 1000 AS p99_ms
FROM pg_stat_ch.events_raw
WHERE app = 'myapp' AND ts_start > now() - INTERVAL 1 HOUR
GROUP BY query_id ORDER BY p99_ms DESC LIMIT 10;

ClickHouse 侧预置了四个物化视图：events_recent_1h（滚动 1 小时副本）、query_stats_5m（5 分钟桶 + TDigest 分位数）、db_app_user_1m（按数据库/应用/用户的负载归因）、errors_recent（7 天滚动错误窗口）。

性能令人印象深刻：p99 开销约 5μs/条，在 pgbench 32 客户端 36.6K TPS 下，30 秒内捕获 770 万事件且零丢弃，对 TPS 影响 <1%（36,658 vs 36,913 基线）。三层锁争用最小化策略：原子溢出检查 → 非阻塞 LWLock 尝试 → 每后端本地缓冲区（每事务刷新，减少约 5 倍锁获取次数）。把 PostgreSQL 做成"事务系统”，ClickHouse 做成"遥测仓库"，职责分离，比从日志文件逆向解析稳定得多。支持 PG 16–18，Apache 2.0 许可证。

8. pg_rrf: 一个函数搞定混合检索的排序融合

pg_rrf | GitHub

pg_rrf 由日本开发者 yuiseki 开发（2026 年 1 月发布），用 Rust（pgrx）实现。它将 Reciprocal Rank Fusion（RRF） 封装为原生 PostgreSQL 函数，解决混合检索场景中"分数不可比"的工程痛点：不同检索器输出尺度不同，直接加权不好调，而 RRF 只依赖 rank。公式为 score(d) = Σ 1/(k + rank_i(d))，k 默认 60（Cormack et al., SIGIR 2009）。

扩展提供四个函数：rrf(rank_a, rank_b, k) 计算两路融合分数、rrf3() 三路融合、rrfn(ranks[], k) N 路融合、以及最实用的 rrf_fuse(ids_a bigint[], ids_b bigint[], k)——接收两个排序后的 ID 数组，返回融合后的 (id, score) 表。NULL 安全：只在一路出现的 ID 仅使用该路的排名计算得分。

-- 使用 pg_rrf 的混合检索：pgvector + BM25
WITH fused AS (
  SELECT * FROM rrf_fuse(
    ARRAY(SELECT id FROM docs ORDER BY bm25_score DESC LIMIT 100),
    ARRAY(SELECT id FROM docs ORDER BY embedding <=> :qvec LIMIT 100),
    60
  )
)
SELECT d.*, fused.score
FROM fused JOIN docs d USING (id)
ORDER BY fused.score DESC LIMIT 20;

这将原本需要 FULL OUTER JOIN + COALESCE 链 + 手动评分公式的 20+ 行 CTE 压缩为一个函数调用。应用场景覆盖 RAG 混合检索（语义搜索 + 全文搜索融合）、电商产品搜索、多信号文档排序等。把融合逻辑移到数据库侧，尤其当结果要继续 JOIN 业务表时，减少了应用层拼接与排序的开销。当前 v0.0.3，MIT 许可证。

9. pg_kazsearch: 哈萨克语全文检索的"从无到有"

pg_kazsearch | GitHub

pg_kazsearch 是首个 PostgreSQL 哈萨克语全文检索扩展。哈萨克语是高度黏着语（agglutinative），一个词如 мектептерімізде 承载了复数、领属、位格等多层后缀，必须全部剥离才能到达词根 мектеп。现有的 PostgreSQL 或 Elasticsearch 分析器都无法处理这一点。

扩展用 Rust（pgrx）实现，提供 kazakh_cfg 文本搜索配置和 pg_kazsearch_dict 词典。词干提取算法采用 BFS 后缀剥离，配合元音和谐验证和基于 Apertium-kaz 的 21,863 个词性标注词根词典 防止过度词干化。运行时可通过 ALTER TEXT SEARCH DICTIONARY 调整权重参数。

-- 词干提取
SELECT ts_lexize('pg_kazsearch_dict', 'алмаларымыздағы');
-- {алма}

-- 构建带权重的 tsvector 并检索
SELECT title FROM articles
WHERE fts @@ websearch_to_tsquery('kazakh_cfg', 'президенттің жарлығы')
ORDER BY ts_rank_cd(fts, websearch_to_tsquery('kazakh_cfg', 'президенттің жарлығы')) DESC
LIMIT 10;

在 2,999 篇文章上的基准测试显示：查询延迟 0.5ms（比 pg_trgm 快 2.8 倍），nDCG@10 提升 25%，Recall@10 提升 23%。适用于哈萨克语新闻/政府文档检索、电商搜索等场景——在多语种系统里把"低资源语言"检索能力补齐，避免回退到粗糙的 trigram 模糊匹配。

10. pg_liquid: Datalog 风格的图查询

pg_liquid | GitHub

pg_liquid 由 Michael Golfi 开发，把 Liquid/Datalog 风格的声明式图查询带进 PostgreSQL。你可以用 liquid.query(...) 在一次调用里声明事实、定义规则并执行终止查询，不必单独搭图数据库。规则是 query-local（只在一次 liquid.query 中有效），支持事实断言、递归传递闭包、复合查询（compounds）和行规范化器。

SELECT target
FROM liquid.query($$
  Edge("a", "path", "b").
  Edge("b", "path", "c").
  Edge("c", "path", "d").

  Reach(x, y) :- Edge(x, "path", y).
  Reach(x, z) :- Reach(x, y), Reach(y, z).

  Reach("a", target)?
$$) AS t(target text)
ORDER BY 1;

它还支持把本体谓词定义（如 DefPred）与 compound（如 OntologyClaim@(...)）结合，用 compound 携带溯源/置信信息，靠规则做 subclass closure 等推理。适合知识图谱查询、层级数据遍历（组织架构、分类树）、基于规则的业务逻辑系统等场景——当你不想引入独立图引擎时，用扩展把最关键的递归查询补上。完全用 PL/pgSQL 实现，无外部依赖，项目处于早期阶段。

11. logical_ddl: 让逻辑复制也能同步 DDL

logical_ddl | GitHub

PostgreSQL 的逻辑复制只处理 DML（INSERT/UPDATE/DELETE），不处理 DDL（ALTER TABLE 等），这是运维中的一大痛点——表结构不同步会直接中断复制。logical_ddl 由 Samed Yildirim 开发，通过 事件触发器 拦截 DDL 命令，将其反解析并保存到可被逻辑复制传播的表中，订阅端接收后生成等效 SQL 并执行。

支持的 DDL 操作包括：ALTER TABLE RENAME TO/RENAME COLUMN/ADD COLUMN/ALTER COLUMN TYPE/DROP COLUMN。数据类型兼容性方面：内建类型、数组、复合/域/枚举类型可用，但这些类型的"定义复制"（如 CREATE TYPE）不在覆盖范围内。可通过 logical_ddl.publish_tablelist 按表和命令类型精细控制捕获范围。

-- 发布端配置
INSERT INTO logical_ddl.settings (publish, source) VALUES (true, 'publisher1');

-- 将逻辑复制中的所有表加入 DDL 追踪
INSERT INTO logical_ddl.publish_tablelist (relid)
SELECT prrelid FROM pg_catalog.pg_publication_rel;

-- 按表指定捕获的 DDL 类型
INSERT INTO logical_ddl.publish_tablelist (relid, cmd_list)
VALUES ('my_table'::regclass, ARRAY['ADD COLUMN', 'DROP COLUMN']);

适用于逻辑复制环境的自动化 DDL 同步、零停机迁移、多数据中心 PostgreSQL 架构等。把"DDL 同步"从流程管理变成可审计的数据流，降低复制事故概率。MIT 许可证，PGXN 可用。约束、索引、默认值等尚未实现。

12. rdf_fdw: 用 SQL 查询语义网

rdf_fdw | GitHub

rdf_fdw 由 Jim Jones 开发，是一个通过 SPARQL 端点访问 RDF 三元组存储的 Foreign Data Wrapper，架起关系型 SQL 世界与语义网/关联数据世界之间的桥梁。它引入 rdfnode 数据类型处理 RDF 术语（IRI、语言标签、数据类型），支持 WHERE/LIMIT/ORDER BY/DISTINCT 等条件的 SQL-to-SPARQL 下推，以及通过 SPARQL UPDATE 端点执行 INSERT/UPDATE/DELETE。

-- 创建指向 DBpedia 的外部服务器
CREATE SERVER dbpedia
  FOREIGN DATA WRAPPER rdf_fdw
  OPTIONS (endpoint 'https://dbpedia.org/sparql');

-- 创建外部表映射 SPARQL 查询
CREATE FOREIGN TABLE dbpedia_query (
    p rdfnode OPTIONS (variable '?p'),
    o rdfnode OPTIONS (variable '?o')
) SERVER dbpedia OPTIONS (
    sparql 'SELECT ?p ?o WHERE {<http://dbpedia.org/resource/Berlin> ?p ?o}'
);

-- 用标准 SQL 查询 RDF 数据
SELECT * FROM dbpedia_query WHERE o = 'some_value' LIMIT 10;

rdf_fdw_clone_table() 存储过程支持将外部表数据分批克隆到本地表。需要注意的是，实现层面会把拉取到的数据加载到内存再转换，面对大体量数据要谨慎评估内存与下推效果。适合关联数据集成（DBpedia、Wikidata）、用 SQL/BI 工具链直接消费 SPARQL 端点等场景。MIT 许可证，支持 PG 9.5–18。

13. pgbson: 比 JSONB 更精确的二进制文档类型

pgbson | GitHub

pgbson（postgresbson）由 buzzm 开发，为 PostgreSQL 引入原生 BSON（Binary JSON）数据类型。BSON 相比 JSON 提供了一等公民的 datetime、decimal128、int32/int64、binary 等类型，解决了 JSON 在分布式系统数据交换中的精度丢失和类型模糊问题，保证 二进制完美往返（BSON in = BSON out）。

核心 API 是两类访问方式：一类是高性能的 dotpath 函数——bson_get_string(bson, 'd.recordId')、bson_get_datetime()、bson_get_decimal128() 等，直接在底层结构上行走，只在终点分配内存；另一类是类似 JSON 的 -> / ->> 链式操作符，但每一步都要构造中间子结构，深层路径会放大成本。两者配合 B-Tree 和 HASH 索引，函数索引可实现 10,000 倍 的查询加速（相对于顺序扫描）。输入端支持 EJSON 格式。

-- 插入带丰富类型的 EJSON 文档
INSERT INTO data_collection (data) VALUES (
   '{"d":{"recordId":"R1","amt":{"$numberDecimal":"77777809838.97"},
          "ts":{"$date":"2022-03-03T12:13:14.789Z"}}}');

-- 函数索引 + dotpath 查询（推荐方式）
CREATE INDEX ON data_collection(bson_get_string(data, 'd.recordId'));
SELECT bson_get_decimal128(data, 'd.amt')
FROM data_collection WHERE bson_get_string(data, 'd.recordId') = 'R1';

-- 箭头链式访问（深层路径性能较差）
SELECT (data->'d'->'amt'->>'$numberDecimal')::numeric FROM data_collection;

典型场景包括跨语言事件/文档管道（Java → Kafka → Python → PostgreSQL）的精确类型保持、金融数据（decimal128 精确到分）、数字签名（BSON 的确定性二进制格式支持可靠哈希）等。MIT 许可证，支持 PG 14–18。

14. pg_when: 用自然语言描述时间

pg_when | GitHub

pg_when 由 frectonz 开发，把自然语言时间表达解析成 PostgreSQL 的 timestamptz 或 epoch。核心函数 when_is(text) 返回标准 timestamp，语法由三部分组成：日期 + at + 时间 + in + 时区。未指定时区时默认 UTC。

SELECT when_is('5 days ago at this hour in Asia/Tokyo');
SELECT when_is('next friday at 8:00 pm in America/New_York');
SELECT when_is('in 2 months at midnight in UTC-8');
SELECT when_is('December 31, 2026 at evening');

另有 seconds_at()、millis_at()、micros_at()、nanos_at() 返回 UNIX 时间戳的不同精度。这不是调度器，而是解析器。适用于面向运营/客服的"人类时间输入"落库、数据修复/回填脚本中用自然语言代替拼日期函数、以及统一时区处理等场景。MIT 许可证。

15. pgmqtt: 数据库变更直推 MQTT

pgmqtt | GitHub

pgmqtt 由 RayElg 开发（Rust 实现），把 PostgreSQL 的变更（INSERT/UPDATE/DELETE）通过 CDC 直接变成 MQTT 消息推给订阅者，同时也支持 MQTT 入站消息按映射写回表。它不是通用 MQTT 客户端，而是把"变更流"与"消息 broker"嵌到数据库侧，用 SQL 配置 topic 映射与 payload 模板。

-- 出站：表变更 → MQTT topic（支持模板化 topic 和 JSON payload）
SELECT pgmqtt_add_outbound_mapping(
  'public', 'my_table', 'topics/{{ op | lower }}', '{{ columns | tojson }}'
);

-- 入站：MQTT topic → 表（JSONPath 规则映射到列）
SELECT pgmqtt_add_inbound_mapping(
  'sensor/{site_id}/temperature', 'sensor_readings',
  '{"site_id": "{site_id}", "value": "$.temperature"}'::jsonb
);

IoT 场景尤其合适——无需外部中间件即可将数据库状态变化推送到边缘设备，或将传感器数据通过 MQTT 协议直接写入表。也适用于事件驱动架构中的轻量消息分发，减少应用层的 glue code。Elastic License 2.0。

16. pg_query_rewrite: 透明地偷梁换柱

pg_query_rewrite | GitHub

pg_query_rewrite 由 Pierre Forstmann 开发，利用 ProcessUtility hook 实现 SQL 语句的运行时透明替换。规则基于 精确字符串匹配（大小写和空格敏感）存储在共享内存中。

-- 添加重写规则
SELECT pgqr_add_rule('select 10;', 'select 11;');

-- 此后执行 "select 10;" 将返回 11
SELECT 10;  -- 返回 11

-- 查看所有规则及重写计数
SELECT pgqr_rules();

这是一个"很锋利"的工具：不支持带参数的语句、最大长度约 32KB、匹配对大小写/空格/分号敏感、规则不持久化（重启丢失，需借助启动 SQL 机制恢复）。适用于数据库迁移期间对历史系统发出的固定 SQL 做透明重定向、危险查询临时拦截、查询 A/B 测试等。默认最多 10 条规则，支持 PG 9.5–18。

17. pgclone: 一键克隆数据库对象

pgclone | GitHub

pgclone 由 valehdba 开发（PGXN 上发布 2.0.0 版），定位非常直给：不用 pg_dump/pg_restore、不用 shell 脚本，直接从 SQL 调用函数把表、schema、数据库、函数（甚至角色与权限）从源实例克隆到目标环境。

它使用 COPY 协议进行快速数据传输，支持异步操作与进度跟踪，支持选择性克隆（列/行过滤），DDL 也在覆盖范围内（索引、约束、触发器、视图、物化视图、序列等），还提供数据脱敏与敏感列自动发现能力。

-- 克隆远程表到本地（含数据）
SELECT pgclone_table(
  'host=source-server dbname=mydb user=postgres password=secret',
  'public', 'customers', true
);

-- 克隆整个远程数据库
SELECT pgclone_database(
  'host=source-server dbname=mydb user=postgres password=secret', true
);

适用于开发/测试环境快速搭建（含 DDL、索引）、生产到预发的"带脱敏克隆"、多库迁移与验证等。相比 pg_dump/pg_restore，它完全在数据库内部完成，简化了 DevOps 流程。

18. pgproto: 原生 Protobuf 支持

pgproto | GitHub

pgproto 由 Apaezmx 开发，为 PostgreSQL 提供原生 Protocol Buffers（proto3）存储、查询、修改和索引支持。核心机制是"运行时 Schema 注册 + 二进制遍历"：把 FileDescriptorSet 注册到 pb_schemas 后，protobuf 类型的列就能通过路径数组提取嵌套字段。引入 -> 字段导航、#> 嵌套路径访问、|| 消息合并等操作符，以及 pb_set()/pb_insert()/pb_delete()/pb_to_json() 等函数。

-- 嵌套字段提取
SELECT data #> '{Outer, inner, id}'::text[] FROM items;

-- 局部更新（返回新 protobuf 值）
UPDATE items SET data = pb_set(data, ARRAY['Outer', 'a'], '42');

-- B-Tree 表达式索引
CREATE INDEX idx_pb ON items ((data #> '{Outer, inner, id}'::text[]));

在 10 万行基准测试中，pgproto 存储仅 16 MB（JSONB 46 MB，原生关系 25 MB），全文档检索 5.9ms（关系模型 33.1ms 需多表 JOIN）。想保留 Protobuf 生态（RPC/消息）又希望数据库侧可索引可过滤时，这是一个有吸引力的选择。适合 IoT 数据存储、微服务事件仓库、gRPC 数据层等。PostgreSQL License。

19. pg_fsql: JSONB 驱动的递归 SQL 模板引擎

pg_fsql | GitHub

pg_fsql 由 yurc 开发，把"SQL 模板渲染 + 安全参数化执行 + 模板树递归组合"做成扩展。模板按 dot-path 组成树，子模板产出片段或 JSON，再注入父模板。支持占位符语法（{d[key]} 及不同转义 !r/!j/!i）、SPI plan cache（按模板可选缓存）、多种命令类型（exec/ref/if/exec_tpl/map/NULL），以及 fsql.run 执行、fsql.render dry-run、fsql.tree、fsql.explain 等公共 API。不需要 superuser。

-- 定义模板
INSERT INTO fsql.templates (path, cmd, body)
VALUES ('user_count','exec',
        'SELECT jsonb_build_object(''total'', count(*)) FROM users WHERE status = {d[status]!r}');

-- 执行模板
SELECT fsql.run('user_count', '{"status":"active"}');

-- 渲染但不执行（dry-run）
SELECT fsql.render('user_count', '{"status":"active"}');

这不是函数式 SQL，而是层次化模板引擎：目标是让你用 JSON 请求体驱动 SQL 生成，减少应用层代码分支。适用于动态报表生成、ETL 管道编排、多租户查询生成、以及把差异化 SQL 固化在模板表中配合权限管理等场景。

20. pg_dispatch: 基于 pg_cron 的异步 SQL 分发

pg_dispatch | GitHub

pg_dispatch 由 Snehil Shah 开发，是一个异步任务分发器，定位为 TLE 兼容的 pg_later 替代品，底层依赖 pg_cron。核心函数 pgdispatch.fire(command) 立即异步执行 SQL，pgdispatch.snooze(command, delay) 延迟执行。设计目标是解锁主事务——当 AFTER INSERT 触发器需要执行重操作时，将其卸载为后台任务。

SELECT pgdispatch.fire('SELECT pg_sleep(40);');
SELECT pgdispatch.snooze('SELECT pg_sleep(20);', '20 seconds');

TLE 兼容（纯 PL/pgSQL），可在 Supabase 和 AWS RDS 等沙盒环境使用。依赖 pg_cron >= 1.5。适合触发器/函数内的异步副作用（通知、异步汇总、写审计表等），避免长事务占用连接。

21. block_copy_command: 安全加固：阻止 COPY 命令

block_copy_command | GitHub

block_copy_command 由 rustwizard 开发（Rust/pgrx），通过 ProcessUtility hook 集群范围内拦截 COPY 命令。在安全敏感环境（PCI-DSS、HIPAA 合规）中防止通过 COPY TO 进行数据外泄或通过 COPY FROM 进行未授权数据导入。

它提供基于角色的 blocklist、方向控制（block_to/block_from），以及对 COPY ... TO PROGRAM 的强制阻断（默认对所有用户拦截）。blocked_roles 甚至能阻止 superuser。支持审计日志记录。

COPY my_table TO STDOUT;     -- 非 superuser：ERROR
COPY (SELECT 1) TO PROGRAM 'cat';  -- 默认：对所有用户阻断

-- 查看审计日志
SELECT ts, current_user_name, copy_direction, blocked, block_reason
FROM block_copy_command.audit_log
WHERE ts > now() - interval '1 hour'
ORDER BY ts DESC;

适用于托管/共享环境（防止租户用 COPY 导数据）、企业合规（统一拦截与审计）、ETL 权限收敛（通过 GUC/角色配置精确允许导入、阻断导出）。作者还维护了更全面的命令防火墙扩展 pg_command_fw。

22. pg_isok: 数据质量的"软告警"系统

pg_isok | Repo

pg_isok（Isok）由 Karl O. Pinc 开发，已在生产环境使用超过十年。它不是传统约束/触发器，而是"软触发器"式的数据完整性管理：你写一条能找出可疑数据模式的 SQL，Isok 负责记录/分类/延后这些发现，并报告"新增问题或已接受数据的变化"，避免你反复审阅同一批历史问题。

-- 一个典型 Isok 查询：找出"客户无订单"的可疑模式
INSERT INTO isok.isok_queries (query) VALUES (
  'SELECT customers.id::text,
          ''Customer '' || customers.id || '' has no related ORDERS'',
          NULL
   FROM customers
   WHERE NOT EXISTS (
     SELECT 1 FROM orders WHERE orders.customerid = customers.id
   )'
);

与硬约束（拒绝数据）不同，它允许存在可疑数据但持续追踪和管理——通过 isok_queries 和 isok_results 等表组织工作流，run_isok_queries 函数执行检查，逐行接受或延迟告警。适合"脏数据导入后逐步清理"“业务规则模糊、需要人工裁决"的场景。能写 SQL 就能上线一套"告警 + 去重 + 延期"机制。

23. external_file: PostgreSQL 版的 Oracle BFILE

external_file | GitHub

external_file 由 Gilles Darold（HexaCluster Corp）维护，提供与 Oracle BFILE 等效的功能：通过目录别名 + 文件名的 EFILE 类型引用服务器端外部文件，支持读取（readEfile()）、写入（writeEfile()）和复制（copyEfile()）。通过 lo_* 相关机制执行读写，并用目录别名表与权限表控制可访问范围。

-- 注册目录
INSERT INTO directories(directory_name, directory_path) VALUES ('MY_DIR', '/data/files/');

-- 读取外部文件
SELECT readEfile(efilename('MY_DIR', 'document.pdf'));

-- 将 bytea 列写入外部文件
SELECT writeEfile(my_bytea_column, efilename('MY_DIR', 'output.bin')) FROM my_table;

为 Ora2Pg 迁移场景量身定制，也适合"文件在库外、元数据在库内"的遗留系统，以及数据库侧管理外部大对象的批处理导入导出。

24. pg_byteamagic: 检测 bytea 的文件类型

pg_byteamagic | GitHub

byteamagic 由 Nico Mandery 开发，封装 libmagic（Unix file 命令背后的库），提供两个函数：byteamagic_mime(bytea) 返回 MIME 类型，byteamagic_text(bytea) 返回人类可读的文件描述。

SELECT byteamagic_mime(file_data) FROM file_storage WHERE id = 1;
-- 'image/png'

SELECT byteamagic_mime(data) AS mime_type, count(*)
FROM uploads GROUP BY 1 ORDER BY 2 DESC;

当你不得不在表里存 bytea/BLOB 时，可以在 SQL 里识别这段二进制到底是 PDF、PNG 还是其它格式。适合附件/上传内容治理（识别真实类型、防止伪装）、Content-Type 自动识别、历史 BLOB 数据清理等。

25. pg_text_semver: 语义版本号的原生支持

pg_text_semver | GitHub

pg_text_semver 由 Rowan Rodrik van der Molen 开发，基于 text DOMAIN 实现完全符合 Semantic Versioning 2.0.0 规范的版本类型。与 C 实现的 semver 扩展不同，它对版本号各部分 没有 32 位整数的大小限制。

SELECT '0.9.3'::semver < '0.11.2'::semver;  -- true（语义比较，非字典序）
SELECT '1.0.0-alpha'::semver < '1.0.0'::semver;  -- true（预发布 < 正式版）
SELECT '8.8.8+bla'::semver = '8.8.8'::semver;  -- true（构建元数据忽略）
SELECT semver_parsed('1.0.0-a.1+commit-y');
-- (1, 0, 0, 'a.1', 'commit-y')

纯 SQL 实现，支持 min/max 聚合和 PGXN Version Range 检查。适用于扩展/包版本管理、依赖约束校验、版本分布统计等。

26. parray_gin: text[] 的子串匹配索引

parray_gin | GitHub

parray_gin 由 Eugene Seliverstov 开发，为 text[] 数组列提供基于 GIN 索引的 部分匹配 操作符。标准 PostgreSQL 的 GIN 数组操作符只支持精确元素匹配，parray_gin 新增的 @@> 操作符支持子串包含判断，底层基于 trigram 分解（复用 pg_trgm 的实现），并通过 recheck 处理 false positive。

CREATE INDEX ON test_table USING gin (val parray_gin_ops);

-- 'post' 子串匹配 'postgresql'
SELECT * FROM test_table WHERE val @@> array['post'];

-- 支持 LIKE 模式的部分包含
SELECT * FROM test_table WHERE val @@> array['%ar%'];

适合标签系统自动补全、模糊标签搜索等场景——让数组模糊匹配进入索引路径，替代应用层扫描。支持 PG 9.1–18。

27. pg_slug_gen: 加密安全的时间戳短标识

pg_slug_gen | GitHub

pg_slug_gen 由 Fernando Olle 开发，生成基于时间戳的加密安全唯一短标识。使用 pg_strong_random() 选择字符，slug 长度决定时间戳精度：10 字符（秒）、13（毫秒）、16（微秒，默认）、19（纳秒）。

SELECT gen_random_slug();      -- 微秒精度
SELECT gen_random_slug(10);    -- 秒精度
SELECT gen_random_slug(19);    -- 纳秒精度

注意这不是 URL slug 生成器（从标题转写），而是面向"安全短 ID"的方案。适合邀请码/短链接/公开资源 ID（避免自增 ID 暴露业务规模）、分布式写入（用时间戳维度做可控的无碰撞窗口）等。比 base62(序列) 更难预测。

28. pglock: PostgreSQL 内的轻量级分布式锁

pglock | GitHub

pglock 由 fraruiz 开发，在 PostgreSQL 内部实现轻量级分布式锁服务。它基于一张锁表和一组函数（pglock.lock/pglock.unlock/pglock.ttl/pglock.set_serializable）实现，支持 TTL 过期机制（默认 5 分钟），可选配合 pg_cron 定时执行 pglock.ttl() 清理过期锁。建议使用 SERIALIZABLE 隔离级别以保证并发语义正确。

-- 获取锁
SELECT pglock.lock('b3d8a762-3a0e-495b-b6a1-dc8609839f7b', 'users');

-- 释放锁
SELECT pglock.unlock('b3d8a762-3a0e-495b-b6a1-dc8609839f7b', 'users');

-- 清理过期锁
SELECT pglock.ttl();

无需外部依赖（Redis、ZooKeeper 等），适用于多实例应用抢占任务/资源（定时任务、幂等消费者）、Leader 选举、防止重复任务执行等场景。锁行为与业务写入可在同一数据库生态里治理。纯 SQL 实现。

29. pg_regresql: 让规划器信任 pg_class 统计信息

pg_regresql | GitHub

pg_regresql 是 boringSQL 的 Radim Marek 做的一个小扩展，专门解决计划回归测试里的一个老问题：即便你向 pg_class 注入了生产环境统计信息，PostgreSQL Planner 仍会去读磁盘上的真实文件大小，再按比例缩放行数估计。这样一来，选择率虽然还是对的，但 EXPLAIN 的绝对 cost 会被测试库的体量拉小，无法稳定复现生产环境的估算结果。

这个扩展通过 get_relation_info_hook 直接改写 Planner 读取到的关系与索引统计，把 relpages、reltuples、relallvisible 等值替换成 pg_class 中的目录统计。这样做的效果很直接：在 CI 中对比 EXPLAIN 成本、在本地复现生产计划、或者维护可移植的计划基线时，估算值终于能和注入的统计信息保持一致。

-- 当前会话加载扩展
LOAD 'pg_regresql';

-- 或者对测试库启用
ALTER DATABASE test_db SET session_preload_libraries = 'pg_regresql';

-- 之后 EXPLAIN 会优先使用 catalog 统计信息
EXPLAIN SELECT * FROM orders WHERE status = 'pending';

它只影响规划阶段的成本估计，不会改变真实执行过程，也不会篡改 EXPLAIN ANALYZE 的实际行数。因此这玩意适合测试环境和 CI，不适合生产库。BSD 2-Clause 许可证。

30. pgcalendar: 循环日程的无限投影

pgcalendar | GitHub

pgcalendar 由 h4kbas 开发，提供完整的循环事件日历系统：事件（events）是逻辑实体，日程（schedules）定义循环模式（每日/每周/每月/每年），投影（projections）生成实际发生时间，例外（exceptions）修改单个实例（取消、改期）。

-- 创建事件和日程
INSERT INTO pgcalendar.events (name, description, category)
VALUES ('Daily Standup', 'Team standup meeting', 'meeting');

INSERT INTO pgcalendar.schedules (event_id, start_date, end_date, recurrence_type, recurrence_interval)
VALUES (1, '2024-01-01 09:00:00', '2024-12-31 23:59:59', 'daily', 1);

-- 投影：生成一周的实际发生时间
SELECT * FROM pgcalendar.get_event_projections(1, '2024-01-01', '2024-01-07');

-- 添加例外：取消某天
INSERT INTO pgcalendar.exceptions (schedule_id, exception_date, exception_type, notes)
VALUES (1, '2024-01-15', 'cancelled', 'Holiday');

-- 切换日程配置
SELECT pgcalendar.transition_event_schedule(
  p_event_id := 1, p_new_start_date := '2024-02-01 09:00:00',
  p_new_end_date := '2024-06-30 23:59:59',
  p_recurrence_type := 'weekly', p_recurrence_interval := 2,
  p_recurrence_day_of_week := 1
);

“无限投影"“多段 schedule 配置切换"“例外处理"这类能力在排班、会议、计费周期等场景很常见，但靠应用层自己拼往往细节爆炸。把日程逻辑放数据库后，权限、审计与一致性约束更容易统一。

31. pg_variables: 比临时表更快的会话变量

pg_variables | GitHub

pg_variables 由 Postgres Professional 开发，提供会话级变量支持，涵盖标量、数组和记录（集合）类型。变量按命名包（package）组织，“是否事务性"可配置：默认变量不随 BEGIN/ROLLBACK 回滚，但 is_transactional = true 时遵守 ROLLBACK/SAVEPOINT。

SELECT pgv_set('vars', 'int1', 101);
SELECT pgv_get('vars', 'int1', NULL::int);  -- 返回 101

-- 事务性变量：跟随 SAVEPOINT 回滚
BEGIN;
SELECT pgv_set('vars', 'tx_val', 101, true);
SAVEPOINT sp1;
SELECT pgv_set('vars', 'tx_val', 102, true);
ROLLBACK TO sp1;
COMMIT;
SELECT pgv_get('vars', 'tx_val', NULL::int);  -- 返回 101

-- 记录集合操作
SELECT pgv_insert('pack', 'employees', row(1, 'Alice'::text));
SELECT * FROM pgv_select('pack', 'employees');

作为临时表的高性能替代，避免了目录膨胀（catalog bloat）。适合复杂存储过程/批处理中保存中间状态、连接级信息缓存，也作为其它扩展的基础设施（如 pgelog 用它缓存 dblink 连接）。

32. pgelog: 回滚也丢不掉的日志

pgelog | GitHub

pgelog 由 anfiau 开发，通过 dblink 实现 伪自治事务，使日志记录在调用事务回滚时依然存活。这解决了 PL/pgSQL EXCEPTION 块中的日志在 ROLLBACK 后丢失的经典问题。dblink 连接通过 pg_variables 做会话级缓存优化。

-- 即使外层事务回滚，日志依然保留
DO $$
BEGIN
  PERFORM 1/0;  -- 触发除零错误
EXCEPTION WHEN OTHERS THEN
  PERFORM pgelog_to_log('FAIL', 'my_func', 'division by zero', '1', SQLERRM, SQLSTATE);
  RAISE;
END $$;

-- 查询日志
SELECT log_stamp, log_info FROM pgelog_logs ORDER BY log_stamp DESC LIMIT 5;

-- 配置日志 TTL
SELECT pgelog_set_param('pgelog_ttl_minutes', '2880');

关键流程审计时，你不想因为业务事务回滚就丢失诊断线索。批处理/迁移脚本中，阶段性日志比单纯 RAISE NOTICE 更可查询。依赖 dblink 和 pg_variables 扩展，每个会话可能额外打开一个连接，需评估 max_connections。

总结

这 33 个扩展背后有几条清晰的趋势线。

第一，PostgreSQL 正在通过扩展把"专业对象"内建化。 BSON、Protobuf、RDF、循环日程、化学分子、图/本体关系——这些扩展把数据库从"结构化表"推向"可查询的复杂对象存储”。权限、审计、备份、事务语义都沿用数据库基础设施，减少了数据搬运和外部服务依赖。

第二，查询能力在向"组合式 API"演化。 RRF 融合、SQL 模板树、查询重写、稀疏计算、近似摘要结构——这些扩展的共同目标是让复杂逻辑以更少、更稳定的 SQL 片段表达，同时保持可审计、可复跑和可优化。

第三，生产工程与平台化在加速。 从 pg_stat_ch 的实时遥测外送、pg_datasentinel 的容器资源可见性，到 block_copy_command 的安全钩子、pg_isok 的软告警治理——扩展层正在承接越来越多"原本要靠外部系统"的能力。

第四，垂直领域渗透持续加深。 从化学信息学（rdkit）、水文分析（pghydro）到哈萨克语 NLP（pg_kazsearch），PostgreSQL 正在成为越来越多专业领域的计算底座。

PostgreSQL 的扩展生态就是这样：既有大教堂（Apache 基金会项目），也有集市（个人开发者的周末项目），共同构建着世界上最先进的开源数据库。

归档说明（2026-08-30）： 本文原载 vonng.com。文中的软件包数量、截图与上下文以原始发表日期为准；当前行为请以 PIG 文档和实时扩展目录为准。

1.7 - PG 扩展百科全书：中英双语，开箱即用

我把 PostgreSQL 生态里 464 个扩展做成了一本中英双语、开箱即用的扩展百科全书：元数据、下载矩阵、安装命令、使用说明与二进制仓库一站齐全。

扩展目录：中文站 · 英文站

扩展是 PostgreSQL 的灵魂。没有扩展的 PostgreSQL，只是一个普通的关系型数据库；有了扩展的 PostgreSQL，才是那个能吞噬整个数据库世界的超级平台。

但长期以来，PG 扩展生态一直面临一个尴尬的问题：找不到、看不懂、装不上。你想用一个扩展，得先去 GitHub 翻 README，再去 PGXN 碰运气看有没有包，然后对着不同操作系统的包管理器折腾半天。运气好装上了，运气不好，编译失败、依赖缺失、版本不兼容，一下午就没了。

所以我做了一件事：把 PostgreSQL 生态里收录的 464 个扩展，每一个都做成一张完整的“身份证”，整理成一个中英双语的扩展百科全书。当然，它不只是百科全书，还是一套真正可交付的二进制仓库。我们提供 14 个 Linux 平台、最近 5 个 PG 大版本的 RPM / DEB 软件包，做到真正的开箱即用。

PG 扩展百科全书首页

这不是一个列表，而是一本百科全书

市面上不缺 PostgreSQL 扩展列表。PGXN 有一个，各种 Awesome List 也一大堆。但它们通常只给你一个名字和一句话简介。你想进一步知道这个扩展用什么语言写、用什么许可证、支持哪些 PG 版本、在你的操作系统上有没有预编译包、怎么安装、有没有冲突扩展，往往还是得自己去折腾。

我做的这个目录不一样。点进任意扩展详情页，你能直接看到：

  • 基础元数据：版本号、所属分类、开源许可证、开发语言、GitHub 仓库、源码下载地址。
  • 扩展属性：是否需要预加载、是否包含 DDL、是否支持 CREATE EXTENSION、是否 trusted、是否可 relocate、默认安装到哪个 schema。
  • 版本与构建信息：当前收录版本、支持的 PG 大版本、RPM 包名、DEB 包名。
  • 全平台下载矩阵：14 个操作系统与架构组合下，对应的包、下载链接和包大小。
  • 安装命令：针对 pig、dnf、apt 三种方式，给出可直接复制粘贴的完整命令。
  • 关联关系：相关扩展、依赖扩展、冲突扩展一目了然。
扩展详情页

此外，我们还收录了 460+ 扩展文档，让你可以在一个地方直接浏览大量 PG 扩展的双语文档，而不是在分散的页面之间来回跳转。

扩展文档总览

464 个扩展，16 个分类

这 464 个扩展按功能被分成了 16 个大类。如果你之前听说过 PostgreSQL 可以做时序数据库、向量数据库、图数据库、文档数据库，甚至兼容 Oracle 和 SQL Server，那么现在你可以在同一个目录里把这些能力背后的扩展全部找出来，看到详细信息，再一行命令装上。

扩展分类总览

多维度浏览

除了按分类浏览，你还可以从不同维度切入这个目录。

按归属仓库

每个扩展归属于 PGDG、PIGSTY 或 CONTRIB 三类来源之一。PGDG 是 PostgreSQL 官方社区仓库，CONTRIB 是 PostgreSQL 自带扩展，而 PIGSTY 则是我额外打包收录和维护的部分。

按仓库来源浏览扩展

按编程语言

你可以看到这些扩展分别是用 C、C++、Rust、Java、Python、SQL 还是纯数据文件实现的。尤其是近两年 Rust 扩展的增长趋势，在这里看得非常直观。

按开发语言浏览扩展

按开源协议

MIT、Apache 2.0、PostgreSQL、BSD、GPL、AGPL、Timescale License，不同协议对商业使用的影响各不相同，在技术选型时非常值得关注。

按许可证浏览扩展

按扩展属性

哪些扩展需要修改 shared_preload_libraries 重启才能用？哪些是没有 SQL DDL 的“无头扩展”？哪些扩展之间有依赖或冲突？哪些包里包含多个扩展？这些都能在目录中直接看清楚。

按扩展属性浏览

按操作系统

在特定操作系统和 CPU 架构组合下，哪些扩展可用、哪些不可用、版本分别是多少，一张表就能说明白。

按平台矩阵浏览扩展

三件套：目录 + 仓库 + 包管理器

光有元数据目录还不够，配套基础设施同样重要。这次重做扩展目录，其实是一个系统性工程的一部分，整套体系包含三样东西：

  • 扩展目录：告诉你有什么、能不能用、怎么用。
  • 扩展仓库：提供预编译好的 RPM / DEB 二进制包，通过 CDN 分发，不必自己编译。
  • 包管理器 pig：屏蔽不同操作系统和 PG 版本的差异，一行命令完成安装。

这三样东西配合起来，把“找扩展、选扩展、装扩展、用扩展”的完整链路打通了。

一些数字

下面是这套扩展百科全书和配套仓库的一些统计数据。

扩展总量统计文档覆盖统计平台覆盖统计软件包分发统计

为什么要做这件事

做这个扩展目录，表面上是在做一个文档网站，实际上是在做 PostgreSQL 扩展生态的基础设施。

PostgreSQL 扩展生态的现状长期是“有酒无杯”：好东西很多，但发现、安装、使用的门槛太高。一个 DBA 想用 pgvector 做向量检索，或者用 pg_duckdb 跑 OLAP，他首先得知道这个扩展存在，然后得确认自己的操作系统上有没有包，再去处理各种编译、依赖和版本问题。这个过程中任何一环断掉，他都可能直接转头去用别的方案。

我想做的是把这个门槛降到最低：来这里看看有什么，挑你要的，复制一行命令，装上就能用。

每个扩展详情页，都是一个完整的 one-stop shop。你不需要再去 GitHub 翻 README，不需要去 PGXN 找包，也不需要猜操作系统兼容性。所有信息汇聚在一个页面里，中英双语，对国内外用户同样友好。

怎么用

如果你本来就会折腾 PostgreSQL，只是想在 PGDG 仓库之外额外安装一些“官方仓库”没有的扩展，那么直接添加 Pigsty 的 APT / DNF 仓库即可。pig 包管理器可以把这个过程大幅简化，但它并不是强制依赖。

curl -fsSL https://repo.pigsty.cc/pig | bash
pig repo add pigsty pgdg -u
pig install <extension>

如果你压根不想操心这些细节，也可以直接使用 Pigsty PostgreSQL 发行版。它的 rich 模板已经默认准备好了绝大多数常用扩展，你只需要按需启用即可。

curl -fsSL https://repo.pigsty.cc/get | bash
cd ~/pigsty
./configure -c rich
./deploy.yml

完全开源

顺便一提，这个网站和扩展元数据本身也是完全开源的。如果你想自己保存一份副本，或者复用这套数据，直接去 pgsty/pgext 仓库就可以了，省得再自己写爬虫解析。如果你发现了扩展信息、元数据或文档中的错误，也欢迎直接提交 Issue 或 Pull Request。

扩展元数据与网站仓库

附：Extension for Everyone

原稿末尾还附了一张相关主题演讲的海报，这里一并保留下来。

Extension for Everyone 主题海报

小结

扩展是 PostgreSQL 的灵魂，而这个目录，就是灵魂的索引。

464 个扩展，16 个分类，14 个操作系统，5 个大版本；中英双语；元数据、下载链接、安装命令、使用说明汇于一处。这件事的目标很简单：让 PostgreSQL 的扩展生态更容易被发现、更容易被安装，也更容易真正用起来。

如果你发现了有趣的扩展，或者对这套目录和仓库有任何建议，欢迎告诉我。

归档说明（2026-08-30）： 本文原载 vonng.com。文中的软件包数量、截图与上下文以原始发表日期为准；当前行为请以 PIG 文档和实时扩展目录为准。

1.8 - 464个扩展开箱即用：新版 PG 扩展目录发布

今天老冯又让 Claude Code 干了一件大好事 —— 做了一个全新的 PostgreSQL 扩展目录。就放在 https://pigsty.cc/ext 这里。

今天老冯又让 Claude Code 干了一件大好事 —— 做了一个全新的 PostgreSQL 扩展目录，就放在 pigsty.cc/ext 这里。

说起来，这已经是第五版了。兜兜转转一大圈，又回到了第一版使用的 Hugo + Docsy 框架，重新融合到 Pigsty 主站。这个过程本身就是个故事，后面再聊。先说说这一版到底做了什么。

Pigsty PostgreSQL 扩展目录首页

不只是有包，还要有文档

之前的扩展目录，核心功能是告诉你：这个扩展叫什么、元数据在哪里、二进制包怎么下载、一键安装怎么搞。你装好了就行，至于怎么用 —— 自己找文档去。

这次不一样了。在 AI 的帮助下，我们开始系统性地收集并翻译这 464 个扩展的文档，目标是让你在一个地方就能看到所有扩展最关键的使用信息。

具体来说，分两种情况：

对于文档体量巨大的"巨无霸"扩展，我们会建立专门的子站点来做翻译。比如 Citus、TimescaleDB、PostGIS 这几个，文档量本身就相当于一本书，值得单独对待。

对于大多数轻量级扩展，情况其实很简单 —— 它们的全部文档往往就是一页 README。比如 pgvector，作为 PG 生态中最炙手可热的向量数据库扩展，文档就一页纸；

pgvector 扩展文档页面

再比如 pg_repack，这个在线治理表膨胀的运维利器，文档也就是一页 Markdown。

pg_repack 扩展文档页面

我们要做的，就是把这些 README 统统收集起来，嵌入到每个扩展的详情页面中。你不用再到处跳转、翻 GitHub，在一个集中的地方就能查阅所有扩展的核心文档。对于特别大的扩展，我们也会把信息索引聚合起来，让你有一个权威可靠的参考入口。

目前 pigsty.cc 已经完成了 PgBouncer、pgBackRest 和 Patroni 的文档翻译。后续所有扩展 —— 包括 PostgreSQL 内核本身 —— 都会逐步推进并持续维护。

花一天翻完了 PG 生态三大组件的文档

这也是我们的一个愿景：成为 PG 生态中关键信息的可靠来源。

说实话，很多时候我做"正活"剩下的 AI Token 额度没烧完，就顺手拿来填这些空，算是一种兜底，也算在做公益。

同时对 Agent 友好，对人类友好

接下来聊聊这个目录是怎么设计的。

虽然技术栈兜了一圈又回到 Hugo + Docsy，但在 Claude Code 的加持下，纯静态网站也能做出非常出色的效果。设计上，老冯遵循一个核心原则：同时对 AI Agent 友好，对人类读者友好。

对 Agent 友好，意味着网页的源码是开源的、采用 Markdown 格式，而且有一个硬性要求：减少杂音。Markdown 里不应该混入大量原生 HTML 短代码或格式噪声，否则会给 Agent 的解析和阅读制造很大障碍。

对人类读者友好，意味着要把信息高效组织为美观的可视化形式，让人能直观地发现问题、聚焦关键信息。

扩展可用性矩阵的 Markdown 源码

举个具体例子：这一版我们做了一个很实用的尝试 —— 将所有扩展融合进一张大表格。在特定的 PG 版本和操作系统组合下，你可以通过单元格直接看到有多少个可用的包、来自哪个仓库，点击即可下载，非常方便。

但是老冯并没有去用很复杂的 HTML 来实现，依然用的是标准的 Markdown 格式，只是在外面套了一层短代码进行必要的内容转换。这个在 Hugo 编译的时候进行必要的内容转换，然后通过定制的 CSS 格式，让它呈现出可观的效果。

渲染后的 PostgreSQL 扩展可用性矩阵

同时我们这次也提供了一系列分门别类的列表索引，从不同维度展示扩展的属性信息，方便快速检索定位。站内搜索也比之前的版本好用了不少。

按功能分类浏览 PostgreSQL 扩展PostgreSQL 扩展 RPM 软件包索引PostgreSQL 扩展 DEB 软件包索引按编程语言浏览 PostgreSQL 扩展按开源许可证浏览 PostgreSQL 扩展特定 Linux 平台的扩展可用性矩阵时序扩展分类页面

另外，这次我们还将一些 PG 内核分支独有的扩展也收录了进来：

特定 PostgreSQL 分支内核专属扩展

五个版本，兜兜转转回到原点

最后聊一个不那么技术、但挺有感触的话题：文档框架的选型。

这个扩展目录从第一版到现在，前后经历了五个版本：

1.Hugo + Docsy（初版，融合在 Pigsty 主站）2.Docsify3.Next.js4.Hugo + Hextra（独立站点 pgext.cloud）5.Hugo + Docsy（现在，回归 Pigsty 主站）

中间那个独立站点 pgext.cloud，因为没有备案、挂在 Cloudflare 上，有国内用户反馈访问不稳定，怀疑被墙。思来想去，还是老老实实用备案过的域名来做这件事。

第一版：基于 Hugo + Docsy （和这次一样）

第一版 Hugo 与 Docsy 扩展目录

第二版：基于 Docsify

第二版 Docsify 扩展目录

小猪骑大象：PG内核与扩展包管理神器

第三版：基于 Next.js + Fumadocs

第三版 Next.js 与 Fumadocs 扩展目录

数据库老司机勇闯现代前端大观园

后来实在受不了动态网站的一堆破事，回归静态网站了。

第四版：基于 Hugo + Hextra

第四版 Hugo 与 Hextra 扩展目录

PG扩展云，免翻免费解锁PG完全体

Hextra 是另一个轻量化的，类似 Fumadocs 的主题。我很喜欢，它对于小型项目来说非常合适，比如翻译书什么的。但是对于大型文档站点来说还是有些力不从心。但是老冯的几本书，教程，小项目都很喜欢用这个框架。

这次挂在了独立站点 pgext.cloud 三，因为没有备案、挂在 Cloudflare 上，有国内用户反馈访问不稳定，怀疑被墙。思来想去，还是老老实实用备案过的域名来做这件事。

第五版： Hugo + Docsy

第五版回归 Hugo 与 Docsy 的扩展目录

最终的结论其实很简单：

如果你要做静态文档站，选 Hugo 就行了。 Docsy 是 Google 出品的主题，Kubernetes 和 etcd 的文档都在用，基本功扎实，搜索好用，结构清晰，到现在还在活跃更新。轻量级的场景可以用 Hextra，重量级的就上 Docsy。如果需要做内容丰富的动态网站，Next.js 可以考虑，但它有时候确实挺重的。

Hugo 这个框架我用了快十年，从来没让我失望过。折腾了这么多新玩意，最后发现六七年前第一次选的框架就是最合适的选择。这大概也印证了一个道理：扎实的 Boring Technology 才是最好的。 网站不在于做得多炫酷，而在于里面的信息有没有价值。内容为王，始终没变。

你要说这些折腾的时间拿去做视频教程、写实战案例，是不是更有价值？也许吧。但折腾一圈回来，你知道了有哪些选择、它们各自的利弊权衡，提升了自己的 Web 设计经验与品位 —— 这本身就是一种收获。

谁说得准呢？折腾本身，也蛮有乐趣的。

PIG 包管理器吉祥物骑着 PostgreSQL 大象

归档说明（2026-08-30）： 本文原载 vonng.com。文中的软件包数量、截图与上下文以原始发表日期为准；当前行为请以 PIG 文档和实时扩展目录为准。

1.9 - 立足中国，面向全球的 PostgreSQL 发行版

如何打造一个立足中国，面向全球的 PostgreSQL 数据库发行版？在第八届中国PG生态大会上的主题演讲。

大家好，我是冯若航，Pigsty 的作者，独立开源贡献者。 今天我想和大家聊一个话题：如何打造一个立足中国，面向全球的 PostgreSQL 数据库发行版。

这个标题听着有点大，但我想说的很简单：PostgreSQL 已经赢了，问题是 —— 我们中国开发者在这场胜利中扮演什么角色？ 是旁观者，还是参与者？是跟随者，还是引领者？

数据库内核之争已经尘埃落定，真正的竞争将会发生在数据库发行版上。 而在这个关键的机会窗口里，我们应该凝聚生态合力，打造一个全世界开发者都愿意使用的基础设施，数据库世界中的 Ubuntu / Deepseek。

WHY — 为什么

PostgreSQL 已经成为数据库领域主宰者

PostgreSQL 已经赢了 —— 这个观点有着非常扎实的数据支撑。

Stack Overflow 开发者调查 显示，专业开发者中 PostgreSQL 的使用率达到 58.2%，甩开第二名 MySQL 18.6 个百分点，而且这个比例还在加速增长。 从新开源项目，AI SaaS 到 OpenAI 这样的独角兽，PG 已经成为新项目的标配 “默认” 数据库。

PostgreSQL 使用与市场趋势数据

无论 DB-Engines 的数据库热度指数，还是 JetBrains 的开发者调查 都得出了相似的结论。 如果这些社区调查还不够，我们再看看资本市场的动向。

2025 年，PostgreSQL 生态发生了两起标志性收购案： Databricks 斥资约 10 亿美元收购了 PostgreSQL 初创公司 Neon，而 Snowflake 则以 2.5 亿美元收购了 Crunchy Data。 两大数据平台巨头通过收购杀入 PostgreSQL 的 OLTP 市场——他们选的不是 MySQL，也不是自研新库，而是直接押注 PostgreSQL。

全球数据库厂商围绕 PostgreSQL 的产业动向

各大云厂商同样在 All in PostgreSQL：AWS 的新品 Aurora DSQL，Azure 的新品 HorizonDB，GCP 的 AlloyDB，这些云上创新产品都是 PostgreSQL 独占。 PG 的胜利不仅仅是技术上的胜利，更是商业上的胜利。全球最聪明的钱，都在往 PostgreSQL 生态里涌。选择 PostgreSQL 就是选择了未来！

中国在PG开源生态中并没有多少参与感

遗憾的是，在 PostgreSQL 全球狂飙突进的过程中，中国开源的存在感却非常弱。 在这幅波澜壮阔的版图上，很难找到几样醒目的 “Made in China”。我们在见证 PG 巨大胜利的同时，却几乎缺席了这场盛宴。

此前的 PostgreSQL 社区内核 Committer 列表里，没有一位中国人。 而在开源项目方面，老冯搜集了由中国公司或者中国开发者主导的 PG 开源项目，结果发现 Star 数最多， 影响力最大的竟然是老冯这个数据库个人开发者的 Pigsty 。我一方面感觉很自豪，另一方面也感觉很荒诞。

PostgreSQL 开源生态中的中国项目
项目 Star 简介
pigsty 4.3K 开箱即用的PG发行版
PolarDB PG 3.1K 阿里云 PolarDB 开源内核
pgvector.rs 2.1K Rust 编写的PG向量扩展
VectorChord 1.4K 下一代 Rust PG 向量扩展
TBase 1.4K 腾讯云 PG 内核
Cloudberry 1.1K Hashdata 的开源 Greenplum 2.0
IvorySQL 960 瀚高主导的 Oracle 兼容内核
openGauss 751 华为主导的早期 PG 分叉
openHalo 626 易景开源的 MySQL 兼容 PG 内核
zhparser 798 使用 scws 的PG中文分词扩展
duckdb_fdw 393 李红艳开源的 DuckDB 包装器
pg_jieba 392 使用结巴分词的 PG 中文分词扩展
VectorChord-bm25 314 PG 原生的 BM25 排序索引算法
pg_roaringbitmap 263 PG 中的 RoaringBitmap 位图

我这两年参加了几场 国际 PostgreSQL 会议，感受很复杂。 去年 PG 开发者大会里，我碰上了瀚高北美的 Grant Zhou 和 Carry Huang，富士通的 Zhijie Hou，再加上我，就没有别的中国开发者影子了。 今年 还碰上了 TensorChord 的朋友。放在几百人的大会里面，依然是不成比例的极少数。

中国有两三百个数据库产品，很多都是 PG 衍生。但在全球 PostgreSQL 生态里，几乎没有存在感。 我们的人才、我们的资金、我们的精力，都花在了重复造轮子上。当全球同行们正在奋勇创新，在资本市场嘎嘎乱杀的时候。 中国的数据库同行们却在泥潭中挣扎 —— 几百家国产数据库公司，只有四家在盈利，整个行业正在高速缩水凋亡。 这说明什么？说明我们在错误的方向上投入了太多资源，市场正在用脚投票。

我们需要思考如何破局：如何在 PostgreSQL 生态中找到一个切入点，做出像 Deepseek 这样有世界级影响力的东西

有这样的东西吗？有的，朋友们，有的。

数据库发行版大战拉开序幕

数据库内核之争已经尘埃落定，真正的战斗将会发生在数据库发行版上。 —— 这个判断来自对 Linux 发展历程的观察。

1991 年，Linus Torvalds 发布了 Linux 内核。但 Linux 内核本身是不能直接用的， 你需要有人把内核、工具链、软件包、配置脚本打包在一起，形成一个可以安装、可以使用的操作系统。这就是 发行版。

1993 Debian 年诞生，94 年 RedHat 诞生。之后服务端操作系统内核很快就收敛到了 Linux 上， 大家都用同一个内核，OS 世界的竞争很快就从内核层面转移到了发行版。

今天的 PostgreSQL，正处于当年 Linux 的位置上。

Linux 内核与发行版的分层关系

做过系统管理的朋友都清楚，真正的生产环境中几乎没有有人会从源码编译整个 Linux 内核和软件栈，而是直接选择一个发行版。 因为后者已经帮我们选好了内核版本、驱动与库，准备好了软件仓库和包管理器，带有文档手册与最佳实践，可以 开箱即用。

PostgreSQL 内核如今已经足够成熟强大了，如何把内核 + 扩展 + 高可用 + 监控 + 备份 + 安全等要素整合起来，形成一个开箱即用的完整解决方案，这件事成为了关键。 PostgreSQL 内核称王，发行版诸侯争霸。谁会成为数据库世界的 Debian / Ubuntu / RedHat，群雄逐鹿，犹未可知。

PostgreSQL 内核与发行版的分层关系

事实上，目前在全球范围内，围绕 PostgreSQL 已经出现了一些“准发行版”的雏形。最有名的就是 Supabase。 它把 PostgreSQL 内核与几个扩展和开源生态组件打包起来，加上UI封装成一个后端即服务 (BaaS) 平台。 从本质上看，这就是一个 PostgreSQL 发行版！钉死了 PG 中的 Android 生态位.

一家成立不到五年的 PG 发行版创业公司，估值高达 50 亿美元； 而 PostgreSQL 内核贡献的老大哥 EDB，成立近20年估值才 10～20 亿美元，这足够证明很多事情了。

这对于我们而言既是挑战，更是机会。在这个时间窗口里， 我们完全有机会打造一个由中国团队主导的 PostgreSQL 开源发行版，服务全球用户，抢占新的制高点。 如果我们再错过这一次的机会窗口，我们可能又要在下一个时代继续扮演追随者的角色。

HOW：我是怎么做的？

但在讲故事之前，我先亮个底牌 —— 我不是来画饼的，我已经做出来了。

Pigsty，一个 PostgreSQL 发行版。从下载量和网站 UV 看，用户大概小十万，中国一半，海外一半。GitHub Star 在中国 PG 生态项目里排第一。

PostgreSQL 发行版面向的用户群体

要是拿来和 Supabase 这种50亿美金的巨无霸比呢，差距确实很大，Supabase 的 Star 数量和用户量都是 Pigsty 的 20 倍。

Supabase 其实属于 2C 的 “Android”，而且也被老冯偷了家，目前 Pigsty 是极个别可以直接 自建生产级 Supabase 的开源方案。

但这个生态允许错位竞争，可以同时出现多个赢家， 如果看 Linux 原生 PG RDS 发行版 这个细分赛道，Pigsty 拿第一当仁不让。 就算拉上 EDB、Crunchy 这些大厂搞的十几个 K8S 云原生 Operator 一起比，也算是打得有来有回。

主流 PostgreSQL 发行版的 GitHub Star 历史

至少我证明了：一个中国开发者，用正确的方法，也可以在 PG 全球生态里占有一席之地，拿到了一张决赛圈的门票。

Claude 对 PostgreSQL 发行版生态的分析

Claude Opus 4.5: PG 生态发行版格局分析

Gemini 对 PostgreSQL 发行版生态的分析

Gemini 3 Pro: PG 生态发行版格局分析

老冯 2022 年开始全职创业做这个，差不多三年半了。技术储备从 2018 年就开始。 作为开源项目，有一些外部贡献者，但 99% 以上的代码和工作量，是我一个人完成的。 那么问题来了：一个人，怎么做到这些的？其实就是两句话，立足中国，面向世界。

立足中国：规模是最好的试炼场

什么是“立足中国”？ 它不是一句口号，而是我们手中最有价值的资源 —— 规模与场景。

Pigsty 并不是在车库里凭空想出来的，它是在 探探 —— 中国第二大陌生人社交平台上孵化出来的。（PS. 这是个瑞典的创始团队） 在那几年里，我们要面对的是什么？是 250 万全局 QPS 的恐怖流量，是所有核心业务逻辑全跑在数据库存储过程里的极限架构，以及上百套大型物理机集群的高效监控管理。

就连现在独角兽之王 OpenAI 对于 PostgreSQL 的使用规模与深度，也没有达到当初我们所面临的挑战。 当时市面上的监控、高可用方案，在这种规模的冲击下，要么不够看，要么不好用。 没办法，逼着我们自己试，自己造，自己整合。 我们是在几百万 QPS 的高压锅里，在一个又一个故障和报警的锤炼下，把 Pigsty 打磨出来的。

这就是“立足中国”的真正含义： 中国拥有全球罕见的互联网规模和复杂场景。这里的海量用户高并发挑战，就是最好的炼丹炉。 如果一个方案能扛住探探这种级别的压力与复杂度，并解决好这些问题，那它放在全世界的其他场景下基本都是降维打击。

—— 立足中国，就是要用中国互联网场景独有的规模场景，打磨出世界先进的生产级方案。

Pigsty 自建 PostgreSQL 服务能力概览

面向全球：成为供应链的上游

那什么叫“面向全球”？ 把文档翻译成英文，去海外发帖推广，那算不了什么。 真正的面向全球，是 让你自己成为全球软件供应链不可或缺的一环。而想要走向全球，你需要关注的是开发者的体验与需求。

Pigsty 面向开发者的 PostgreSQL 使用体验

差不多做到 2023 年，Pigsty 运维层面已经很完善了。 高可用，备份恢复，监控系统，离线部署，IaC 大规模管理全部整合到了一起，可以无需容器在主流 Linux 上一键交付。 但我隐隐觉得哪里不对，老冯一直站在 DBA 的视角，做了很多可靠性、可观测性，质量与易用性上的工作 —— 但我忽视了开发者的核心需求 —— 功能特性。

PostgreSQL 扩展生态全景图

我意识到：扩展才是 PostgreSQL 最大的价值所在。MySQL 想加向量搜索，折腾很久效果还不好。 PG 呢？一个社区开发者写了 pgvector，几个扩展一起赛马，直接把这个赛道卷没了，这就是可扩展架构的威力。

去年我写了一篇文章《PostgreSQL 正在吞噬数据库世界》，发到 Hacker News 火了，传遍整个 PG 社区。 核心观点就是：PG 能拳打 Oracle、脚踢 MySQL，靠的是极致的可扩展性和繁荣的扩展生态。

于是我开始做扩展仓库。一开始想借力，等生态里其他项目做完再集成。 等了几个月发现等不来，就自己干了。先编译十几个，然后几十个，然后一百多个。 做着做着发现：PG 生态里能打的扩展就几百个，官方仓库提供一百出头， 而我凭一己之力把这个数字推到了 437 个。

437 个 PostgreSQL 扩展的软件包覆盖统计

这个仓库覆盖 14 个 Linux 发行版、x86 和 ARM 两种架构、6 个 PostgreSQL 大版本。 仓库里有六七万个 RPM 和 DEB 包。很多扩展得改代码才能编译通过，我前后修了几十个。 想借力借不到只能自己干，反而干出了壁垒。最费工夫的苦活，成了最坚固的护城河。 但老冯也不会藏着掖着，敝帚自珍，而是将这个扩展仓库对公众与同行免费开放。

PGEXT.CLOUD 扩展目录首页

让我没有想到的是， 现在不仅仅是 PG 终端用户在用 Pigsty。 国外的数据库发行版项目，甚至是一些商业数据库公司，开始直接使用 Pigsty 的扩展仓库作为他们的上游源。

以前，我们是下载别人的代码，用别人的源。 现在，是一个中国开发者维护的仓库，成为了国际数据库同行的上游基础设施。 我们不再只是旁观者或者消费者，我们成了供应商，我们嵌入到了全球 PG 的供应链里。

PostgreSQL 上游与下游软件仓库的关系

这是真正的出海：不是去别人的地盘抢饭吃，而是让别人做饭的时候，用你的大米。 用这种方式，老冯的发行版开始成为了 PostgreSQL 生态的一块基础设施，成为全球软件供应链的一个节点。

有了从零到一的突破之后，中国的 PG 生态开源软件也能够更容易的走向国际。 在老冯的 Pigsty 仓库中，目前还分发三款来自中国的 PostgreSQL Kernel 分支 —— IvorySQL，PolarDB，OpenHalo，以及一些中国开发者的扩展与工具。

PostgreSQL 分支内核的软件包交付矩阵

邀请

一个人做到现在这个程度，真的很不容易。但如果想要更进一步，打造出一个像 Ubuntu 这样的，全球主流的 PostgreSQL 发行版。 那就绝非一人能成了，需要众人拾柴火焰高。所以今天，我想借这个机会，向在座的各位发出邀请。共同参与到这样的事业中来。

面向用户的邀请

对于用户来说，你可以通过使用 Pigsty 免费获得企业级质量的本地 RDS 服务，免去手搓HA，编译安装配置等诸多烦恼，一步到位完成生产数据库自建，开箱即用。

我们邀请您在新项目中尝试 Pigsty —— 反正一行命令就能部署，不满意可以随时换掉。如果愿意向朋友推荐，写下使用心得，投稿博客或者视频，那对于项目来说也是巨大的贡献。

面向数据库厂商的邀请

对于数据库厂商来说，我想说的是，如果你们交付给客户的还是一个裸的 RPM / DEB 包，现在你可以选择用 Pigsty 交付一套完整的生产级基础设施。 Pigsty 可以成为你们的交付载体。你们专注做内核、做特色功能，Pigsty 帮你们解决周边生态的问题。这是双赢的合作。已经有好几款PG内核分支 通过 Pigsty获得了完整的 RDS 能力。

面向 PostgreSQL 厂商的生态合作邀请

作为诚意，原本 AGPLv3 许可证的 Pigsty 本体也将在下个大版本中使用更宽松的开源许可。而像 PG 扩展仓库，PIG 包管理器的的全部代码与基础设施都以 Apache 2.0 许可证开源。

面向开发者的邀请

对于扩展作者来说，PGEXT.CLOUD 是一个让你的作品触达全球用户的渠道。

你写了一个 PostgreSQL 扩展，怎么让用户用上？自己编译打包适配十几个不同的 Linux 发行版？ 自己去触达全世界的 PG 用户？如果你有这样的烦恼，也许老冯可以帮到你。

结语

最后，我想用一句话来总结今天的演讲：

与其在两百多个国产数据库里内卷，不如一起打造一个全世界都想用的 PostgreSQL 发行版。

PostgreSQL 已经赢了。现在的问题是，我们中国人要不要参与这场胜利，以及以什么姿态参与。我选择的姿态是：拥抱 PostgreSQL，做一个发行版，立足中国，面向全球。

这条路我已经走了 7 年，即使是一个人，我会继续走下去。但我希望不是一个人走，而是有更多的人一起前行。

谢谢大家。

打造面向全球的 PostgreSQL 发行版

归档说明（2026-08-30）： 本文原载 vonng.com。文中的软件包数量、截图与上下文以原始发表日期为准；当前行为请以 PIG 文档和实时扩展目录为准。

1.10 - 聊聊开源软件供应链信任问题

在严肃的生产环境里，你不能依赖一个明确说"我不提供任何保证"的上游。当别人告诉你"别指望我"，最好的回应是"那我自己来"。从TUNA镜像站的争议谈开源软件供应链信任问题。

昨天，老冯的一篇文章《从PG“断供”看软件供应链中的信任问题》收到一条评论， 评论者称是高校开源镜像站的管理员（清华 TUNA），向老冯提出批评抗议，内容如下：

作为高校开源镜像站管理员，我想要提醒作者，文中“躺平”“没有担当”的措辞是很不负责任的、令人心寒的指控。

高校镜像站管理员的评论

老冯看到评论之后也做了回复：

感谢 回复与评论，也感谢这些年 TUNA 以及国内各高校镜像站为开源镜像生态投入的时间和精力。我看到当时 TUNA 的 PostgreSQL 仓库已经恢复了和上游的同步，这一点先点个赞。

最初发现问题时，我用的是阿里云的 PostgreSQL 镜像。后来注意到 TUNA 上也存在同样的情况，就纯粹出于开源道义在 向 TUNA 邮件列表反馈问题，得到的是一句（本邮件列表是 TUNA 的邮件列表，与阿里云无关）与长期的沉默，这样的感受会体现在文章的情绪中。

回头看原文，用“躺平”“没有担当”这样带有明显的情绪色彩的字眼，放在 贵站身上 已经不准确，也容易被误解为在给志愿者贴道德标签，这并非我本意。如果这段措辞让一线维护同学感到不舒服，我在这里先说声抱歉。我已经 修改措辞 为更中性的说法，比如“长期未更新” / “不再维护”，避免伤到真正干活的人。

对于你提到的一点我是认同的：高校镜像站本质上是志愿者项目，没有法律或合同意义上的承诺。不再维护这件事无法在法律和道德上苛责什么，这一点在文章里也多次强调过。但从下游用户的角度看，PGDG 切断 rsync 之后，国内主流镜像在相当长一段时间里停留在几个月前的版本，对很多只会照着“推荐镜像源”配置的用户来说，客观效果就是供应链中断，这是实实在在的风险，缺乏维护损耗的是用户对镜像站的信任。

我的感想是：在没有服务承诺的前提下，把高校镜像当成关键生产基础设施，是一种错误的依赖方式。我自己的做法是不再把别人的开源镜像站当成上游，而是自建 PGDG 镜像，自己掌握软件供应链；再次感谢你把维护者的视角和感受说出来。这次讨论至少能帮更多用户搞清楚：开源软件镜像站能做什么、不能指望它做什么，这本身就是有价值的。

老冯的感想

收到消息后呢，我去清华 TUNA 源上看了一眼，PostgreSQL 仓库里已经有最新的 PG 18 的包了，不过 “Last Update” 时间戳还是 2025-05-16，应该是手工同步的。 总的来说是件大好事，除了老冯的 PIGSTY 仓库 之外，国内总算又多了一个能提供相对及时 PGDG 镜像的节点，这一点我要为 TUNA 点个赞。

讨论发生时 TUNA 的 PostgreSQL 18 软件包目录

其实在老冯的 PG 发行版 Pigsty 里，原来使用的是阿里云的 PostgreSQL 镜像站，并没有直接从 TUNA 拉 PG 包。 “躺平”“没有担当”这些情绪上的评价，最初更多是冲着阿里云这种有资源的大厂去的 —— 云计算泥石流 的保留节目。 毕竟阿里云作为互联网大厂和本土云计算一哥，从开源攫取了巨大价值，搞个开源镜像站却长期不维护 PG 仓库，实属拉垮。 结果在这次风波里，反而是清华 TUNA 的同学先站出来表达了不同看法，这一点我也理解。

长期未更新的阿里云 PostgreSQL 镜像目录

这里说一句公道话：不管是阿里云镜像站还是 TUNA 镜像站，我在原文里多次强调过 —— 作为免费的服务提供方，在法律和道德上确实没有义务去做这件“慈善”。 但这并不妨碍每个人对现实结果有自己的看法和评价。“躺平”“没有担当”是我当时的主观感受，现在回头看，用在高校志愿者身上，确实容易误伤人。 所以我已经把措辞调整为“停止维护”“长期未更新”这类事实性的表述，把情绪收回来，避免误伤一线维护的同学。

为什么老冯会有这种感觉呢？我在发现 全球镜像站出现同步问题 之后，第一时间就 给阿里云发邮件反馈了这个问题（当然阿里云现在还没修）。 同时，我也顺手看了一圈国内其他镜像站，发现清华 TUNA 镜像站也有这个问题，就在他们的邮件列表里发了一封提醒。 结果有同学回复说：“你发的这个是阿里云的问题，跟本站无关”。我解释这是所有镜像站共有的问题，然后就再没有任何回应。

TUNA 邮件列表中的 PostgreSQL 镜像同步讨论

大概又等了一个月左右，老冯实在是不想等了，就自己搭建了 PGDG 中国区域的镜像仓库，放在腾讯云上，和 Pigsty 自己的仓库放一起。 移除了对阿里云 PostgreSQL 镜像站的上游依赖，至少在 PostgreSQL 制成品分发上，实现了完整的自主可控供应链。 老实说，如果不是因为国内镜像站在这件事上的整体表现，老冯可能也不会这么快去做这件事。

老冯嘴臭惯了，对云厂商说话一向不太客气，但这不意味着我不理解志愿者的难处 —— 尤其是对于高校开源志愿者，整体上我觉得应该多一点呵护，少一点道德化的指责，这也是我后来主动调整措辞的原因。

开源与信任

实际上老冯自己也刚刚经历过类似的事情。我也维护了几个开源项目，还有不少 PostgreSQL 生态里的工具。 比如说 pg_exporter —— PG 的 Prometheus 指标导出器，有一些 PG 厂商也在用。 前天我才注意到，9月份有人在上面提了一个 Issue 写到：

你好，虽然我知道这是一个开源项目，但我一个月前提交的两个问题至今仍未得到任何回应，这实在令人失望。 我对 pg_exporter 1.0 版本以及 PG 邮件列表上的公告都充满期待，甚至考虑过贡献代码。 但我不愿把希望寄托在一个维护者缺席的项目上。希望这只是暂时的，也希望他一切安好。 我没有任何怨言，衷心祝愿这个项目和维护者一切顺利。

pg_exporter Issue 中关于维护响应的讨论

老冯九月份在新疆自驾了一个月，没怎么用电脑，Issue 点开看过但后面就忘掉了。 “缺乏维护” 导致这位用户对老冯的开源项目失去了信任，而他本来也许可以成为项目的贡献者。辜负了他的信任与期待，确实让老冯感到非常遗憾与愧疚。 所以我就放下手头的事儿，把他提的问题修了一遍，然后发布了一个新版本 1.0.3。

将心比心，当我发现我所依赖的上游镜像站出现问题，而你反馈了也没人理、没人修时，我自己也会有这位用户一样的感受：

“我不愿把希望和信任寄托在一个维护者缺席的项目上”。

软件供应链

在那篇《从PG“断供”看软件供应链中的信任问题》中，老冯提出过一个观点：

“开源” 确实并不要求你向用户提供可靠稳定的二进制制成品，但真正重要的不是开源，而是信任。 开源只是构建信任的一种形式，持续的投入，交付的承诺，专注的热情，面对问题的担当。 想要成为值得信赖，受人尊敬的社区参与者，有许多东西比丢一份源代码到仓库要重要得多。

把开源镜像站办起来，说好听一点，也是某种公共慈善。这位管理员同学的委屈我是能理解的： “我们又没拿报酬，还要扛合规和安全风险，牺牲个人时间来维护。你不说谢谢就算了，怎么反过来用‘躺平’‘没有担当’这样的词来说我们？”

这里有一个现实却不太好听的点：对维护者而言：“我没收钱，所以我没有义务”，在内心是一个很自然的防线； 但对用户而言：只要你把服务挂在公开的地址上，大家自然就会把它当成“某种可以依赖的基础设施”。这种期待不甚合理，但是真实存在。

镜像站与普通开源项目有一个重要区别：它处在软件供应链的中间 —— 是从上游到下游的通路，直接影响生产环境， 而不像单纯开源项目那样 “我写个工具，你爱用不用”。

而供应链天然就会出现分层：

  • 有可靠的，有不可靠的；
  • 有愿意给出承诺、出 SLA 的，也有只愿意尽力而为的；
  • 有愿意把“这事算我头上”的，也有明确表示 “别指望我” 的。

做到好、长期维护、有清晰的预期管理，就会积累声望、信任、影响力，成为别人可以安心依赖的关键节点； 做不好，交付过时或不可靠的结果，自然也要面对用户信任的流失。

当这位同学写下：“与商业镜像站不同，国内全部的高校镜像站都没有任何服务承诺和保证” 这句话本身从维护者视角看，非常诚实。 但换一个视角 —— 生产运维负责人听到这句，大概会在脑子里立刻画一个叉：“没有任何服务承诺和保证，那就没法出现在生产供应链上游。”

所以，这篇文章不是要去指责镜像站 “没有担当”，而是要提醒下游用户 —— 在严肃的生产环境里，你不能依赖一个明确说“我不提供任何保证”的上游。

质量与承诺

清华 TUNA 提供的很多镜像服务是有价值的。比如 pypi 和 homebrew 镜像，我个人电脑上就一直在用，它们完全胜任“加速访问”的角色。 在 Pigsty 的早期版本里，我也用过部分 TUNA 的 PostgreSQL 镜像。后来遇到过几次莫名其妙的 403 封禁，这对自动化部署来说不太友好，于是就全部改成阿里云的镜像了。

整体上看，阿里云镜像站过去的表现是比较稳定可靠的，直到这次 PGDG 切断 rsync 之后，PG 仓库一直停在几个月前的版本，至今还没有修复。 这件事客观上削弱了我对它的信任，所以我选择自己托管 PGDG 镜像，把这部分供应链从它身上剥离出去。 操作系统层面的镜像，我目前仍然在用阿里云。如果哪一天阿里云在 Linux 系统镜像上的表现也开始频繁翻车，那我也很可能会考虑自建 Rocky / Ubuntu / Debian 的镜像源。

在这件事情上：

  • 清华 TUNA 管理员很坦率地表示：高校镜像站不提供服务承诺。这个立场本身没有问题，但下游看到这句话，自然会据此调整对你的使用边界；
  • 阿里云没有明确说，但从过往表现来看，我们可以暂时把它当成“部分负责的大厂”：如果继续出问题，那老冯回去催它/批评它，或者在自己的体系里换掉它；
  • 老冯的 Pigsty / PGDG APT / DNF 仓库，会明确给出承诺：如果仓库出问题，我会去修；如果修不好，那我自己信誉扫地，对付费客户来说，这也意味着 SLA 违约责任。

镜像站、仓库、发行版，这些都是“基础设施中的基础设施”。是否愿意为自己的服务说一句“出了问题算我头上”，决定了你在这个生态里的角色 —— 只是好心的志愿者，还是真正能被依赖的关键节点。

当高校镜像站把丑话说在前面，下游又应当如何自处？当别人告诉你“别指望我”，最稳妥的回应永远是“那我自己来”。

广告时间

写文章不打广告约等于没写，也许老冯提供的服务正好能帮到你。以下三个国内镜像仓库，免费对公众提供服务： 这些仓库提供 Cloudflare 全球版本与国内云墙内版本，可以方便的使用 pig / apt / dnf 启用。 更详细的介绍请参考 PGEXT.CLOUD 软件仓库说明。

PGDG镜像

定期同步全球 PostgreSQL 开发组官方软件仓库（el 7-10, debian 11-13, ubuntu 20-24） 最近同步于今天，每周更新。文中原有的 APT/YUM 目录入口现已停用；当前镜像地址与启用方式请参见 Pigsty 软件仓库文档。

PIGSTY PGSQL

PIGSTY PGSQL 仓库：提供 几款不同风味的 PG 内核分支 (PolarDB, IvorySQL, Babelfish, OrioleDB, OpenHaloDB, Percona TDE, Supabase,… ) ，与 PGDG 官方仓库配合使用，提供多达 437 个 PG 扩展插件 与生态常用工具。支持 14 个 Linux 发行版大版本。

文中原有的 APT/YUM 目录入口现已停用；当前镜像地址与启用方式请参见 Pigsty 软件仓库文档。

PGEXT.CLOUD 扩展目录与可用性统计

PIGSTY INFRA

提供各类数据库相关工具，Grafana，Prometheus，以及 Exporter 可观测性全家桶

文中原有的 APT/YUM 目录入口现已停用；当前镜像地址与启用方式请参见 Pigsty 软件仓库文档。

DBMS Prometheus Grafana
IvorySQL 4.6 prometheus 3.7.3 grafana 12.3.0
etcd 3.6.6 pushgateway 1.11.2 loki 3.1.1
minio 20250907161309 alertmanager 0.29.0 promtail 3.0.0
mcli 20250813083541 blackbox_exporter 0.27.0 vector 0.51.1
kafka 4.0.0 VictoriaMetrics 1.129.1 grafana-infinity-ds 3.6.0
duckdb 1.4.2 VictoriaLogs 1.37.2 grafana-vmlogs-ds 0.21.4
ferretdb 2.7.0 pg_exporter 1.0.3 grafana-vmetrics-ds 0.19.6
tigerbeetle 0.16.60 pgbackrest_ex… 0.21.0 grafana-plugins 12.0.0
juicefs 1.3.0 node_exporter 1.10.2
dblab 0.34.2 keepalived_exp… 1.7.0 UTILS
vray 5.28.0 nginx_exporter 1.5.1 sealos 5.1.1
pig 0.7.2 zfs_exporter 3.8.1 rclone 1.71.2
vip-manager 4.0.0 mysqld_exporter 0.18.0 restic 0.18.1
pev2 1.17.0 redis_exporter 1.80.0 mtail 3.0.8
promscale 0.17.0 kafka_exporter 1.9.0 genai-toolbox 0.18.0
pgschema 1.4.2 mongodb_exporter 0.47.1 sqlcmd 1.8.0

归档说明（2026-08-30）： 本文原载 vonng.com。文中的软件包数量、截图与上下文以原始发表日期为准；当前行为请以 PIG 文档和实时扩展目录为准。

1.11 - PG扩展云：解锁 PG 生态的全部潜力

开源免费免翻墙，一键安装PG与431个扩展插件 14个Linux发行版 x 6大PG主版本原生 RPM/DEB。

微信公众号链接

PostgreSQL 拥有极为强大的扩展插件体系。 在 《PostgreSQL 正在吞噬数据库世界》中， 老冯已经阐述过 可扩展性 是 PostgreSQL 成功的核心要素。 举例来说，PG 有 GIS 领域的事实标准 PostGIS，向量数据库的瑞士军刀 pgvector，还有可以替代 ElasticSearch 的 pg_search， 以及使用 DuckDB 在 PG 内进行分析的 pg_duckdb / pg_mooncake 等等，这些扩展为 PostgreSQL 赋予了超乎想象的能力。 只有加装了这些扩展，PG 才能称得上是 “全盛完全体”。

PostgreSQL 扩展生态全景图

然而，要在生产环境中可靠地编译、安装这些扩展插件并非易事，会有许许多的挑战。绝大多数扩展仅仅交付源代码，需要自己去摸索编译。 对于严肃的生产环境来说，源码编译和 Docker 镜像 往往也不是一个可行选项 —— 当你需要组合使用多个不同扩展，在不同服务器上精确安装相同版本，或者根本不想使用容器时，就会有各种问题。 还有一些非技术的挑战需要克服 —— 官方镜像站停止更新 ，以及国内网络环境受限导致无法下载。

不过，这些问题都被老冯一一攻克了！经过最近两三年无数日夜的努力，我很自豪地向大家介绍 PGEXT.CLOUD —— PG扩展云， 一次性， 一条龙，一步到位解决用户安装扩展，开发者分发扩展，厂商交付扩展的难题。

PGEXT.CLOUD

PG 扩展云（PGEXT.CLOUD）提供了以下三样基础设施，帮助用户更好的利用 PostgreSQL 扩展生态系统的协同超能力：

  • 扩展目录 ：一个在线网站，查阅 431 个扩展插件 的详细信息，找到满足您需求的插件。
  • 扩展仓库 ：获取预先打包的 RPM/DEB 二进制包，在 14 个 Linux 大版本 上可用
  • 包管理器 ：屏蔽复杂度与操作系统与架构差异，使用 pig 命令行工具一键完成所有步骤

只需几行命令，即可在 主流 Linux 系统 上原生安装多达 431 个 PostgreSQL 扩展，组合使用，发挥 PostgreSQL 的超能力。 如若不信，在全新的 Linux 服务器/容器环境中，下面三行命令就能让你安装 PG 18 官方内核与一些最强大复杂的 PG 扩展插件：

curl -fsSL https://repo.pigsty.io/pig | bash
pig repo set
pig install -y -v 18 pgsql postgis timescaledb pgvector pg_duckdb

这几条看似简单的命令背后，其实隐藏了巨大的复杂度与工作量。支持 14 个 Linux 发行版、6 个 PG 主版本、431 个扩展插件所产生的排列组合，是一个近乎天文数字的挑战。

而在实现“丝滑”安装交付的过程中，还伴随着各种棘手问题 —— 庞大的数量，驳杂的质量，分发的限制，心智的负担。好在这些挑战现在都有了一个不错的答案。

无可比拟的数量

PostgreSQL 生态中拥有数量庞大的扩展，总数可能超过 1000 个。然而在官方 PGDG 仓库中，目前只提供了其中约 135 个扩展。 诚然，一些耳熟能详的插件（如 PostGIS、pgvector 等）包含在官方仓库里，但还有许多强大的扩展并未被收录 —— 例如近期炙手可热的 DuckDB-PG 融合扩展 pg_duckdb 和 pg_mooncake。老牌的 Plv8，还有 Supabase 自建所需的一系列 Rust 扩展。

官方仓库不收录这些扩展有许许多多的原因 —— 比如 YUM 仓库的维护者 Devrim 就表示，绝对不会让 Rust 写的 PG 扩展进入仓库中。 而像 plv8，pg_duckdb 这样一编译一个小时的扩展巨无霸，毫无疑问也会显著拉高仓库维护的成本，所以老冯也完全能理解。

老冯曾经寄希望于 Tembo 的包管理器 trunk，或者 pgxman 之类的东西可以解决这些问题，不过似乎最后还是不自己动手上。 （比如 tembo 就已经跑路去干 AI DBA 去了）。而这一干就一发不可收拾，一下子就干成了 PG 生态里最大的扩展目录与仓库。

简单来说，这个扩展目录目前收录了 431 个扩展，抛开 PG 自带的 71 个扩展总共 360 个。 PGDG 官方仓库维护了 144 个 EL 扩展和 105 个 Debian 扩展，而老冯的 PGSTY 维护了 260 个 EL 扩展与 241 个 Debian 扩展， 占到了总数的 72% 左右，哈哈，这可真是以一己之力撑起了大半边天。

分类 All PGDG PIGSTY CONTRIB MISS PG18 PG17 PG16 PG15 PG14 PG13
ALL 431 150 260 71 0 396 419 421 424 409 384
EL 425 144 260 71 6 385 412 415 418 406 380
Debian 417 105 241 71 14 384 407 407 410 398 369

良莠不齐的质量

当然，光有数量是不行的，更重要的是质量。PGDG 的 YUM 仓库有许许多多的 “坑”： 某个发行版和 PG 的组合可能漏掉了，不同 PG 大版本的扩展版本不一致，老冯在这里可没有少给 PGDG 仓库擦屁股。

更大的问题在于部分扩展缺乏及时维护。当 PostgreSQL 推出 16、17、18 等新版本时，一些扩展因为无人更新而无法兼容新版本，甚至直接导致崩溃。 这两年来，老冯 修复了近百个“趴窝”的扩展。例如，最近几乎所有重要的 Rust PG 扩展，在老冯的推动下都已升级到最新的 pgrx 0.16.1 框架，并支持 PG 18。

老冯维护与修复 PostgreSQL 扩展的 GitHub 贡献记录

可以说，目前目录里的这些扩展，即使原作者弃坑不干了，老冯也有信心接手维护，持续为新版本保驾护航。 当然，确实有极个别规模太大，难以抢救且作者失联的扩展，老冯也只能无奈摊手（age，hydra）。

也许你会好奇，老冯一个人是怎么维护这么多扩展的？说起来，这还真是多亏了 Claude Code。 Opus 4.1 干这个可真是一把好手，通常我只要念出正确的咒语，然后 Review 一下，大部分情况下问题就迎刃而解了，哈哈！

如何分发扩展

光解决扩展的编译打包还不够，如何高效地将扩展分发到用户手中，同样面临诸多挑战。 首先需要维护一个 APT 仓库和一个 YUM 仓库，确保不同系统的用户都能方便获取软件包。 PGEXT.CLOUD 默认通过 Cloudflare 提供全球 CDN 加速，但 Cloudflare 在中国大陆访问缓慢，因此我们专门搭建了位于国内的镜像站来提供高速下载。

虽然，打包构建是一项相对冷门稀缺的技能，但建立自有仓库镜像并不是最棘手的问题。 更大的难题在于：除了 Pigsty 自己的扩展仓库镜像，俺还需要维护 PostgreSQL 官方 PGDG 仓库的国内镜像！

在我之前的文章 从PG“断供”看软件供应链中的信任问题 和 卡脖子：PostgreSQL切断镜像站同步通道 中， 我曾提到：PostgreSQL 官方 PGDG 仓库自今年5月起停止了 ftp/rsync 同步通道，这导致全球范围内的大部分镜像站从那时起就不再更新了。 对于海外用户来说影响尚不明显，但对于无法自由访问外网的中国大陆用户而言，这意味着如果不翻墙就无法获取 PG 的最新软件包。 大家常用的阿里云、清华 TUNA 镜像源目前都停留在 2025-03-31 的版本，仓库连今年 9 月发布的 PG 18 都影子无踪。

长期未更新的阿里云 PostgreSQL 镜像目录

目前，能持续更新 PGDG 仓库镜像的我所知道也就只有老冯维护的 Pigsty、俄罗斯的 Yandex，以及欧洲 Xtom。 我每周都会手动同步上游 PGDG 仓库，确保国内用户也能拿到最新的更新。 顺带一提，老冯还在 PGDG 镜像里帮 PGDG YUM 仓库修复了一些陈年旧 bug（比如 patroni 3.0.4 这个钉子户版本）。

总而言之，如今只要你使用主流 Linux 发行版，无论身在国内还是海外，都可以通过 PGEXT.CLOUD 享受丝滑顺畅的 PostgreSQL 及其扩展安装体验，再也不用为网络和环境问题操心。

PGEXT.CLOUD 的全球与中国大陆软件包分发路径

PG扩展维基百科

扩展插件如此众多，对于普通用户来说，安装使用时难免会被各种配置、源站、镜像等细节搞得头大。 许多初学者只是想用上 PostgreSQL 及其扩展，这些繁琐细节实在没必要成为绊脚石。 这正是老冯在仓库之外，又额外提供 扩展目录 和 包管理器工具 两项服务的原因。

PGEXT.CLOUD 扩展目录首页

PGEXT.CLOUD 的扩展目录汇集了前述 431 个扩展的详细信息。 我们为每个扩展整理了元数据、在各操作系统和 PG 版本上的可用性矩阵，以及完整的安装、配置与加载使用说明。

PGEXT.CLOUD 扩展安装与使用说明PGEXT.CLOUD 扩展配置与加载说明

我们还按功能、许可证、开发语言等多个维度对扩展进行分类索引。一些重要扩展甚至配有专门的说明章节和教程。PGEXT.CLOUD 的目标很明确 —— 打造 PostgreSQL 扩展界的维基百科，让用户对可用的扩展“一览无余”，也为开发者提供展示自己作品的平台。

简单易用命令行

当然，更令人兴奋的是，我们还提供了简单易用的命令行工具 pig。 这个用 Go 语言编写的小巧工具（仅 4 MB），将 PostgreSQL 的安装和扩展交付过程简化到了极致。

例如，只需下面三行命令，就可以分别完成下载 pig、配置仓库以及安装 PG 内核和扩展插件：

curl -fsSL https://repo.pigsty.io/pig | bash
pig repo set
pig install -y -v 18 pgsql postgis timescaledb pgvector pg_duckdb

无论您使用的是哪种 Linux 发行版，配置了什么软件源，所处地域网络如何，使用 dnf/yum 还是 apt，这个工具都能替您处理好所有细节。

值得一提的是，pig 并非另起炉灶造轮子，而是对现有 Linux 包管理器的 “一层薄皮封装”（PiggyBack）。 换言之，您依然可以使用经典的 apt/yum 来直接访问 PGEXT.CLOUD 的软件仓库 —— pig 只是让这一切变得更简单，但并不是不可替代的强制依赖，更不会引入任何供应商锁定。

它不关心你运行在什么 Linux 上，配置了什么仓库，在什么区域，用的是 dnf ，yum，还是 apt，它可以帮助你处理好所有细节。

开源、供应链与信任

此前有些国外用户对老冯表示过顾虑：“你是中国人，你搞的这个仓库看上去很好，但我们怎么知道没被你偷偷做手脚呢？” 面对这样的质疑，老冯也被噎过。说到底，这是典型的软件供应链信任问题。坦白讲，没有绝对的解决办法。 即便是 PGDG 官方仓库，比如其 YUM 仓库，也是凭借维护者 Devrim 的个人声誉来背书运转的。

老冯的回答是，构建这些二进制产物的所有工具，规范，文档，细节都是开源的，你自己也可以在本地轻松的自己构建出这些扩展来。 这样如果你不放心，完全可以用同样的工具箱在离线情况下直接构建自己的 RPM/DEB 仓库。

例如，你只需要使用下面这个简单的 Dockerfile，就可以立刻拉起标准构建环境， 然后当你想要构建扩展的时候，只需要使用 pig build pkg 命令，就可以了！

FROM debian:13 AS mini
USER root
WORKDIR /root/
CMD ["/bin/bash"]

RUN apt update && apt install -y ca-certificates vim ncdu wget curl rsync unzip && \
    curl https://repo.pigsty.io/pig | bash -s v0.7.1 && pig repo set && pig build tool && \
    pig build spec && pig build rust && pig build pgrx

是的就是这么简单，比如你想要编译 timescaledb，这条命令会自动下载源代码，安装依赖，然后生成 deb 和 rpm 包：

docker build -t d13:latest .
docker run -it d13:latest /bin/bash
使用 PIG 构建 PostgreSQL 扩展软件包

目前 PGEXT.CLOUD 收录的所有扩展包，都是通过上述流程构建而成 —— 这意味着您也可以在任何支持的平台上，轻松从源代码构建出同样的扩展包！

目前的进展

PGEXT.CLOUD 其实并不算是 “新项目”，这套仓库基础设施已经运转五年了，包管理器和扩展目录有两年了。 这个新版本的网站目录倒确实是最近一个月新搞出来了的。所以从成熟度上来说，是已经“久经考验”，没啥问题的。

目前，这个仓库完全开源并免费向公众提供服务。托赛博佛祖 Cloudflare 慷慨免费套餐的福，最大的流量开销得以减免； 至于国内服务器托管，每月几百块的流量费，这点钱老冯还是掏的起的，哈哈。

老冯承诺会长期维护这个仓库。毕竟，这本来就是 Pigsty PostgreSQL 发行版自身需要的一部分，我也乐于将这份成果回馈社区。 我注意到，不少用户乃至业内同行其实只想方便地安装 PG 和各种扩展，所以我选择将 pig 工具和 PGEXT.CLOUD 仓库从 Pigsty 项目中抽离出来， 作为以 Apache 2.0 宽松许可证开源的独立项目服务大众。

有人问我，难道扩展不是 Pigsty 的一个核心价值点与壁垒吗？你就这么开源免费给别人白嫖打白工？ 老冯的观点是 —— 顶级的企业与开发者就是应该通过构建互利共赢的生态，让所有参与者都能从中获益。

这一举措也已经初见成效。例如，业内同行 Omnigres 和 AutoBase 在他们的 PostgreSQL 发行版中引入了这个扩展仓库，不费吹灰之力就让他们的发行版与用户获得了 431 个 PG 扩展的强大能力。 再比如，一些扩展开发厂商（ParadeDB、TensorChord、MooncakeLab 等）也能够借助 Pigsty 仓库，轻松将自己的扩展作品分发给全球用户。

Pigsty 支持的 PostgreSQL 分支内核

不仅如此，我们的仓库还收录并分发了多款不同风味的 PostgreSQL 内核分支 —— Supabase 的 OrioleDB、Percona 的 TDE 内核，瀚高的 IvorySQL、阿里云的 PolarDB、易景的 openHalo 等， 都可以通过这个仓库一键安装启用。PGEXT.CLOUD 不仅服务于扩展作者和使用者，同样助力各路 PG 厂商为用户创造价值。

放眼未来

目前在 PostgreSQL 扩展这条赛道上，除了老冯的 pig 项目可谓高歌猛进之外， 其他方案似乎反响平平：原本声势浩大的 Tembo Cloud 也跑去凑 AI 的热闹，弃坑不干（还坑了 PGXN 作者 David 一把）； pgxman、pgxn 等也都一直都没啥声响和进展。

真正还能在容器化场景下提供扩展分发能力、与我们一较高下的，大概只有欧盟 StackGres（Alvaro 提供的 Kubernetes 方案）。 不过 StackGres 走的是 Cloud-Native 路线，而老冯专注的是 Linux-Native，本就是井水不犯河水，各取所需。

顺带一提，Pigsty 和 StackGres 还是 Supabase 官方 唯二两个支持三方开源自建 Supabase 的发行版，也是一个 Linux 原生，一个 K8S 方案。就是因为也只有我们两家把 Supabase 的核心 —— 扩展问题给解决好了。

众所周知，PostgreSQL 的成功离不开其极致的可扩展性和繁荣的扩展生态。 老冯真心希望通过 PGEXT.CLOUD 为这个生态添砖加瓦，树立起扩展分发的事实标准， 让扩展作者、用户以及 PG 厂商都能享受到更多增值红利，拥有更卓越的使用体验。

作为一个完全开源的项目，PGEXT.CLOUD 热忱欢迎来自各方的贡献！如果您发现还有哪些扩展遗漏未收录， 或者在使用过程中遇到任何问题，欢迎随时提出 Issue。作为扩展作者，如果您因缺少跨平台打包分发能力而烦恼，老冯也很乐意帮您解决这些难题； 作为 PG 产品厂商，我们更鼓励您直接采用 PGEXT.CLOUD 的仓库与工具，将 PostgreSQL 丰富的扩展生态无缝交付给用户。

写到这里，不禁有些感慨——从个人兴趣的小项目，到如今服务全球 PG 社区的一项基础设施，PGEXT.CLOUD 的成长离不开每一位开源同行的支持。 未来，老冯将继续保持初心，与大家携手推动 PostgreSQL 生态更上一层楼！让我们共同解锁 PG 生态的全部潜力，畅想更加精彩的数据库未来！

PGEXT.CLOUD 解锁 PostgreSQL 扩展生态

归档说明（2026-08-30）： 本文原载 vonng.com。文中的软件包数量、截图与上下文以原始发表日期为准；当前行为请以 PIG 文档和实时扩展目录为准。

1.12 - 冷门但稀缺的技能：打包构建

数据库领域一项不为人知，却卡脖子卡到飞起的硬技能。

最近我的朋友，Omnigres 的创始人尤里跟我聊天，他说想要招一个 PostgreSQL 打包专家 —— 当然具体的岗位名字，他起了个 EEE —— Extension Ecosystem Engineer，也就是“扩展生态工程师”，倒是挺有意思。他发的这个 JD 是公开的，我就直接贴在下面了。

稀缺的技能：Linux 打包

我觉得他的这个 JD 有点儿过分，DevRel + SRE + DBA + Building Engineer + PostgreSQL 专精 六边形战士，简直是照着我写的，但老冯还真没见过其他有这种组合的人，所以我还是建议他老老实实找一个精通 Debian/EL 打包的构建工程师更实际一些…。但尽管如此，我认为难度还是挺大的，因为熟悉 “打包构建” 这个技能的人，咱都不能说用”稀缺“来形容了（更稀缺的应该是 DevRel）。

当然这里其实上下文语境，说的是 PostgreSQL 数据库内核/扩展在 Linux 操作系统上的构建打包。主要是 C 和 C++，还有一些 Rust，Java，Go 之类的扩展与工具。打包的产物主要是 RPM 和 DEB 包，以 APT / YUM 软件仓库的形式交付。老冯认为，这是一个相当不为人知的高价值稀缺技能。

什么时候意识到这一点？

老冯第一次意识到构建打包这个事是在 2017 年，那时候我去聊 Pivotal，面试官就问了我一嘴，你会打包吗，我们现在没有会这个的。我就嘀咕，什么包？ RPM 包？嘿还真是。后来 Pivotal 出来的姚老板（YMatrix）也问过我这个事，你是不是打包构建比较熟悉，我们现在就特别缺这个，又让我加深了印象。

后来其实我也看过许多国内国外的数据库公司发布的软件，打包这一块确实惨不忍睹。比如之前的 Greenplum 是怎么交付给客户的呢？是一个 CentOS 7.9 RPM 包。啊对，这个软件它就提供一个 EL 7.9 RPM 包，您想要在 EL 8， EL9，或者 Ubuntu / Debian 或者其他 Linux 上运行？拜拜了您呐！

包括阿里云的 PolarDB for PG ，瀚高的 IvorySQL，本来也就是一两个 EL RPM 包的样子，在老冯的 Push 下总算是支持齐活主流 Linux 发行版了。MySQL 兼容的 OpenHalo 内核和 OrioleDB ，干脆就是我直接自己上替他们打包了。

Pigsty 数据库内核目录

构建打包的价值

打包这个技能很稀缺，但价值在哪里？其实你会发现，绝大多数终端用户 并不在乎你是不是开源，他们在乎的是有没有一个稳定可靠（最好免费）的二进制软件包可以下载。就比如说 Greenplum 闭源了，但现在还时不时的有朋友来管我要 Greenplum 的 RPM 包。姚老板的 YMatrix （GP7 闭源分支）虽说是闭源商业软件，但因为免费提供试用下载，大家也照样能用着，谁管你开不开源。

更鲜活的例子是最近 Kubesphere 社区断供 —— 源代码其实还是在那里的，但是你把二进制产物（镜像）给直接删掉了，这就影响到终端用户了 —— 你开不开源其实对用户毛影响都没有。真正会出现供应链卡脖子问题的，从来都不是软件的源代码，而是软件制成品。

构建打包让开源软件自主可控

开源专家 Tison在他的公众号文章《如何安心使用开源软件？》和 《开源软件有断供的风险吗？》其实深入聊过这个问题。结论就是：开源软件是没法断供的，但是开源制品是可以断供的 —— 想要安心使用开源软件，最重要的还是拥有一份本地的软件副本，或者建设自己的软件仓库。这里的核心就是打包构建。

就比如最近的 《PostgreSQL PGDG 仓库断供》这件事，全世界几乎所有镜像站都跟 PGDG 上游失去同步了，停留在五个月前的过时版本。目前全世界只有德国的 XTOM，俄罗斯的 YANDEX，和老冯在中国的 PIGSTY 提供手动更新的 PGDG 最新软件镜像。

当然，镜像站也只不过是同步一下人家做好的软件二进制制成品，退一万步讲，如果 PGDG 不是停止增量同步而是直接彻底锁死。那你要是想完全独立从零搭建起一个软件仓库出来，针对 RISC-V，MIPS ，ARM 等乱七八糟的国产架构分门别类构建，那么打包构建依然是绕不过去的一道门槛。

打包和打包不一样

当然有人会说，哎呀，都是开源软件，你可以自己从源代码编译呀？这话说的不假，使用现代语言编写的软件已经针对打包构建流程做了很多优化了。比如，用 Go 语言写的程序就非常容易构建打包，甚至还有 goreleaser 这样的神器，可以一键帮跨平台构建所有组合，生成 RPM / DEB 包，构建并推送 Docker 镜像然后自动创建 GitHub Release ，而你让 Vibe Coding 帮你实现这样的工作流可能都要不了半个小时。

但是，我们说的并不是这些，而是像 Debian，PostgreSQL 这样的巨无霸生态型项目（基本上基于 C / C++）。而且，构建打包 PostgreSQL 数据库，可不是几个 RPM 包就完事了。我这么说，现在我提供的10个发行版Linux发行版 x 5个PG大版本，再加上扩展和工具，总共有4万多个左右的 RPM/DEB 包。

打包构建并不是一件轻松的工作：要处理好各种依赖，glibc，icu，openssl，PostGIS 带着的一颗硕大无朋的依赖数。各种插件依赖的各种奇奇怪怪的系统库，不同操作系统发行版甚至是大版本上的版本冲突， cmake，make，ninja，cargo 各种构建工具的用法，诸如此类。

你为什么不用Docker？

Docker 似乎是来 “解决” 打包构建的一种捷径 —— 一次构建，到处运行 —— 才怪。我的意思是：用 Docker 你可以不用处理 Linux 操作系统大版本的组合因子（比如 el9, d12, u24 这种差异），但你依然要针对 PG 大版本，系统架构，以及几百个扩展和他们的多个版本进行构建。第二，如果你去看 Postgres Docker 镜像，就会发现其实它的 Dockerfile 里也还是用 apt install 去安装 PGDG 的 DEB 包的…。Linux 软件包是 Docker 镜像的上游，而不是相反。

第三，PG 的扩展是它区别于其他数据库的核心特色之一，而 Docker 容器镜像至今也没有办法优雅解决 PostgreSQL 扩展插件持久化的问题 —— 你不知道用户到底需要几百个扩展中的哪一个，然而全部装上又显得过于臃肿和愚蠢。Alvaro 在这一方面正在进行一些前沿探索，但老冯感觉距离成熟实践还有距离。

把数据库放入Docker是一个好主意吗？

数据库应该放入K8S里吗？

老冯怎么干起打包了？

老冯干打包这个事也就是从两年前，那时候我要提供在 Pigsty 里自建 Supabase 的能力，但是 Supabase 用到了十几个 PG 的扩展插件，这些扩展插件大部份都不在 PGDG 官方的二进制仓库里面。我问了问 PGDG YUM 仓库的维护者 Devrim，他说，Rust 写的扩展永远也进不了 PGDG 仓库，因为编译太慢了！所以老冯就只好自己上手，给这些扩展打好了 RPM 包。后来既然都打了 RPM 包，就干脆把 DEB 包也做了 —— 再后来，既然都已经支持了十几个 PG 扩展，那干嘛不把 PGDG 官方仓库不支持的两百多个 PG 扩展也打包交付了？

一步一步走到今天，老冯独立维护了一个 PostgreSQL 扩展仓库，里面包含了 9 种风味的 PG 内核，以及两百多款 PG 扩展（加上 PGDG 的总共 423 个可用扩展）。目前是 全世界 PG 生态收录最多可用扩展制品的仓库了。不谦虚的说，说起 PostgreSQL 打包构建，我和 Devrim（YUM 仓库），Christoph（APT 仓库），Álvaro（OCI 仓库），David Wheeler（PGXN） 算是这个赛道的顶级玩家了。

最直观的例子就是，Supabase 作为目前 AI 赛道的当红炸子鸡与数据库最大赢家，本应吸引大量厂商入局，但直到现在，有能力提供自建 Supabase 能力的开源 PostgreSQL 发行版，目前也只有老冯的 Pigsty （基于原生 Linux RPM/DEB），以及 Alvaro 的 StackGres（基于 OCI 镜像与 Kubernetes ）

Supabase 自建文档中列出的 Pigsty 与 StackGres

—— 因为我们都解决了这些 Supabase 专有扩展的构建打包分发问题。其实卡点就在这里，Supabase 即使把他的扩展源代码开源出来（后面还要换 OrioleDB 内核），又有几个人懂？又有几个用户有能力用起来？

说到底，单纯懂 EL / Debian Linux 打包的工程师其实还是有一些的，但是同时熟悉 PostgreSQL 生态，能为 PostgreSQL 几百个包在十几个系统发行版构建的人确实是凤毛麟角了。

懂打包的凤毛麟角

在现实实践中，老冯发现这个技能真的太稀缺了，就像尤里问我谁还懂这个，国内就甭说了，就算是全球，我知道的可能 ZoomboDB 那个作者（pgrx 作者）懂这个（被 ParadeDB 挖走了），别的我还真想不出来有谁能做好这个事情了。

比如说，PG 生态中，这么多扩展，能有有能力直接在发布的时候提供主流 Linux RPM / DEB 包的，我知道的就只有 ParadeDB 一家（pg_search），而他们会做这个事是因为他们发版太频繁了，我实在懒得替他们打包了，所以手把手教他们应该怎么打 RPM/DEB 包。另一个会自己打包的是 pgroonga，timescaledb，citus，但是怎么说呢，打的包和 PGDG 规范不统一，而且经常缺这个缺那个 —— 比如 citus 一直就缺 ARM 的包，Timescale 则缺几个特定的发行版，pgronnga 针对的是 Debian 自带的 PG 去打的包 —— 诸如此类。

再比如说国内的数据库厂商， 之前阿里云的 PolarDB for PG 和 IvorySQL 也就几个 EL RPM 包，后来我使劲儿 push 他们，总算是 Pigsty 支持的 10 个主流操作系统发行版现在都有包了。我也帮他们解决过几个低级打包错误。另外那个 MySQL 兼容的 OpenHalo，老冯干脆自己上了，替他们打好了 DEB/RPM 包。同理，Supabase 收购的 OrioleDB 看上去也没有这个能力，所以我也替他们做了 RPM / DEB ，在 Pigsty 中开箱即用。

Pigsty 文档列出的数据库内核支持范围

小结

很多时候，价值源于非共识，打包构建就属于这种半瓶水外行看上去 “不就是编译封装一下”，但实际上相当稀缺的技能，脖子卡的嗷嗷叫的技能。

References

Extension Ecosystem Engineer 招聘 RFCExtension Ecosystem Engineer 职位定义

归档说明（2026-08-30）： 本文原载 vonng.com。文中的软件包数量、截图与上下文以原始发表日期为准；当前行为请以 PIG 文档和实时扩展目录为准。

1.13 - 从PG“断供”看软件供应链中的信任问题

PostgreSQL官方仓库切断全球镜像站同步通道，开源制成品断供，很好的试出了各家数据库厂商和云厂商的成色。

这个月发生了一起沸沸扬扬的 “开源断供”事件—— KubeSphere 删除镜像跑路， 但其实还有另一件略隐蔽的 “卡脖子案例”，老冯在上个月提到过 —— 《卡脖子：PGDG切断镜像站同步通道》。 这次 “PostgreSQL 断供” 某种程度上扮演了试金石的角色，倒是很好的试出了各家数据库厂商和云厂商的成色。

老冯对此感到非常失望，停止将国内的云厂商和大学镜像站作为软件供应链上游，直接自建了 PGDG YUM/APT 仓库的国内最新同步镜像。

PGDG的“断供”

PostgreSQL 是数据库领域的祖师爷级开源项目，也是世界上最流行，最受喜爱，需求量最大的数据库。 绝大多数的用户都是通过 PGDG APT / YUM 仓库，来在 Linux 上安装 PostgreSQL 数据库的。 不幸的是，PGDG （全称：PostgreSQL 全球开发组）的 APT / YUM 软件制成品仓库在今年五月中旬对外关闭了 ftp 与 rsync 同步通道， 这导致了几乎全球的镜像站点都与上游仓库失去同步，存放的都是几个月前的旧版本软件包。

老冯在 7月7号的 《卡脖子：PGDG切断镜像站同步通道》一文中详细介绍过这个问题。 那时候老冯观察到德国的 XTOM 其实尝试手工按月手工更新的策略，其他基本上所有镜像站全军覆没，都停留在三四五月的状态。 昨天我重新统计了一下，发现俄罗斯的 YANDEX 也手工跟进了 APT 仓库，其他的镜像站依然是老样子。

供应商 区域 同步时间戳 URL
阿里云 中国 2025-03-31 同步时间戳
腾讯云 中国 2025-03-31 同步时间戳
火山云 中国 2025-03-10 同步时间戳
华为云 中国 2024-01-02 同步时间戳
清华 TUNA 中国 2025-03-31 历史截图
浙江大学 中国 2025-03-31 同步时间戳
中科大 中国 直接下架 下架公告
TrueNetwork 俄罗斯 2025-01-31 同步时间戳
JAIST 日本 2025-03-31 同步时间戳
DOTSRC 丹麦 2025-03-31 同步时间戳
MirrorService 英国 2025-03-31 同步时间戳
普林斯顿大学 美国 2025-03-31 同步时间戳
YANDEX 俄罗斯 2025-08-13 镜像
XTOM 德国 2025-07-24 镜像
PIGSTY 中国 2025-08-14 仓库文档

镜像站的“断更”

比如，17.5 等5月更新版本修复了 CVE-2025-4207 GB18030 相关漏洞， 而今天刚刚发布的 17.6 系列版本 更是修复了 3 个 CVE 和 55 个 BUG。 如果你是镜像站的用户，那么就没法及时更新跟进打补丁了。更别提下个月即将发布的 PostgreSQL 18 新大版本了。 现在还属于问题早期阶段，也就落后两个 PG 小版本，但很快再过一个月就会落后一个大版本。 然后各种积累的漏洞补丁，安全修复国内用户全都用不上，产生的暴露风险会越来越大

从这个角度上来说，上游软件供应链停止对下游提供更新，本质上确实符合 “断供” 的定义。不过 PGDG “断供” 的理由也还算充分 —— 他们上 CDN 了嘛。

PGDG为何“断供”

PostgreSQL 邮件列表里，5月20日有韩国镜像站的维护者问过这个问题，之前用 rsync 同步 PGDG 官方仓库怎么突然断了？

Davaid Page 给出的解释是，ftp/rsync 从来就不是官方承诺提供的服务方式。 PGDG YUM/APT 仓库也就两台物理机，每天却有 10TB 的访问流量，很多都是“非法流量”， 带宽要受不了啦！所以他们就把这个仓库给托管到了 Fastly CDN 上。

他们的想法也很显然 —— 我都用了 CDN 了，那专业 CDN 的节点和体验，不比零星的镜像站好多了？ 官方可以有能力绕过镜像站直接对全世界用户提供服务， 那还要啥镜像站？于是就把 FTP rsync 给关掉了，只能通过 HTTP 访问。 看上去确实也没毛病，虽然断了镜像站同步，但也提供替代解决方案了 —— 直接用官方 CDN 就好了，也算是合情合理。

—— 你可以选择不用任何镜像站，直接使用 PGDG 官方仓库（他们刚搬到 Fastly CDN上）。

中国被卡脖子了？

镜像同步中断，对于世界上绝大多数地区的用户来说，其实影响还相对较小，因为他们总是可以去用 PGDG 新的 CDN 。 但唯独对中国来说，这就等效于制成品断供了 —— 因为众所周知的原因，中国访问不了这些 CDN 节点！如果这些镜像站不更新，中国用户就没的用了！

当然，你要是自己翻墙用什么的还是可以用的。但是你显然不能指望人人都会这个，而且即使翻了速度也还是很慢的。 所以国内的镜像站对于国内用户使用 PostgreSQL 来说依然是至关重要。 （也别说 Docker ，DockerHub 也被墙了，而且绝大多数 Docker Postgres 镜像也是从 APT 仓库里安装的…）

从这个角度来说， 中国用户这还真是被卡了一把脖子 —— 虽然本质上属于搬起石头砸自己的脚 —— 人家只是把增量的同步给关掉了，然后你用不了人家提供的替代解决方案而已。 但这个事情已经是这个样子，重要的是在这种背景下如何解决用户的问题。谁来解决这个问题呢？

中国用户想要 YUM/APT 安装 PostgreSQL 一般只能通过国内的镜像站来安装，最知名的应该是阿里云和清华大学的Tuna镜像站，当然还有浙大/中科大的源。 不幸的是，这些镜像站无一例外全都进入 “长期不更新” / “停止维护” 的状态 —— 但你也没法怪他们，毕竟免费嘛。

供应链风险

开源专家 Tison在他的公众号文章《如何安心使用开源软件？》和 《开源软件有断供的风险吗？》深入解释过，开源软件（源代码）本身是没有所谓 “断供” 风险的 —— 开源协议授予的一系列基本权利是不可撤销的，在这个维度下 “开源断供”从未发生过。对断供的担忧往往是对开源软件过度期待带来的误解。

但是用户对开源的依赖总是发生在具体的软件供应链上，保障开源依赖的供应链安全是有成本的 —— 开源制成品，也就是二进制软件包（RPM/DEB/镜像），以及开源制成品的交付渠道 —— 软件仓库（APT/YUM/Registry）是存在断供风险的。

原因也很简单，这都是有成本的，谁来支付这个成本是一个大问题。 开源开发者愿意支付大头的研发成本，很多时候是因为这个事对他们来说是一种有趣的娱乐。 然而分发，打包，构建仓库，提供持续稳定的企业级服务与供给很大程度上是一种负担。 比如国内一个GB流量卖你8毛钱，那你 PGDG 一天10个TB流量，一天就是几千块钱，对吧。 所以你看能搞开源镜像站的基本上要么就是高校要么就是大型互联网厂商，第一自己也要用，第二加双筷子没啥流量成本。

反过来说，这些使用开源软件的用户像 PGDG 和开源软件镜像站付费了吗？ 嘿，没有，所以老实说，无论是从法律上，道义上，还真没法苛责什么，因为这就是开源的 STYLE —— 没有质保 —— 毕竟人家也没收钱，提供源代码是本分，但开源协议可没有规定说要提供开源软件二进制制成品，开发者和开源软件镜像站没有义务去做这种慈善。

如何解决供应链风险？

那么商业服务可以解决这个问题吗？毕竟，这么多国产数据库都是基于 PG 换皮，套壳，魔改弄出来的子孙后代，结果上游老祖宗被 Ban 了，确实有些滑稽，就没有人出来搞个中国的镜像站吗？ 嘿，可能还真没有 —— 大部份情况下，这些数据库厂商都是直接白嫖镜像站（阿里云，清华）仓库的，或者说，交付方式甚至都不是软件仓库，而是丢给你一个 EL7 RPM 包，根本没有能力维护软件仓库。

老冯自己独立维护了一个 PostgreSQL 扩展仓库，里面包含了 9 种风味的 PG 内核，以及两百多款 PG 扩展（加上 PGDG 的总共 437 个可用扩展）。目前是 全世界 PG 生态收录最多可用扩展制品的仓库了。 不谦虚的说，说起 PostgreSQL 打包构建，我和 Devrim（YUM 仓库），Christoph（APT 仓库），Álvaro（OCI 仓库），David Wheeler（PGXN） 是这个赛道的顶级玩家与原始供应者。

但虽然我会打包构建，维护仓库，但是，在安装交付 PG 原生内核的时候，我还是会选择使用 “PG官方” 的 PGDG APT / YUM 仓库，PIGSTY 自己的仓库作为扩展补充仓库， 因为 Devrim 和 Christoph 已经干的足够好了！我会去做和他们工作有差异互补的事情。所以对于老冯的 PostgreSQL 发行版 Pigsty 来说，PGDG 仓库是 PIGSTY 的供应链上游， 国内区域因为有墙，阿里云镜像站是老冯的间接上游。现在的问题是这个间接上游，包括阿里云，清华，浙大，各种云在内的所有镜像站，全都趴窝断更没得用了，怎么办呢？

老冯在发现这个问题的时候，第一时间就给阿里云和清华TUNA的邮件列表上报了这个问题，也跟德哥聊过说过。不幸的是，几十天过去了，依然毫无波澜，没有丝毫动静。 就是没人站出来解决这个问题。老冯对国内这些云厂商和互联网厂商真的非常失望。但你也没法说人家 —— 对吧，人家毕竟是免费给你用的，你能说什么呢？

我行我上

所以老冯也懒得再啰嗦，直接自己动手就上了。其实动手了我才知道，这才多大点事和工作量？ —— 人家不给你开放 ftp rsync 同步，那你就用 apt-mirror 和 reposync 直接从 HTTP 通道去同步不就行了？老冯昨天用 Claude Code 花了两个小时，写了个同步流程，把 PGDG 的 YUM / APT 仓库给拉了下来， 丢到 Pigsty 的仓库里，然后测试了一遍，非常顺滑。我干完之后的感想就是 —— 就这？这么大点儿活，就给国内卡成这样？草台班子理论诚不欺我。

当然 PG 仓库总量大几百个 GB，如果全部弄下来就太大了，我就只要了 Linux x86 / aarch64 架构的包，同步了 Debian 11/12/13 ，Ubuntu 22/24 ，EL 7/8/9/10 这几个主要 Linux 操作系统发行版大版本下的 PG 13 - 17 的包，然后只保留最新的版本，这样总大小就只有几十个GB 了。 拉了两个小时，同步回来，丢到国内 CDN 上，然后目前在 pig 0.6.1 和 pigsty 3.6.1 中， 我已经把阿里云源换掉了，会在这两天发布，彻底摆脱躺平摆烂的中间商依赖，实现真正的自主可控。

目前这个仓库和 Pigsty 本身一样，都是开源免费的。直接使用 Pigsty 肯定是自建 PostgreSQL 服务的更佳选择，但你确实也完全可以直接使用这里的 APT / YUM 镜像仓库。 直接对公众用户开放会有不少流量成本，不过老冯应该还是兜得住的 —— 虽然开源的本质就是无质保，但好在老冯向客户们承诺长期持续维护这个镜像仓库，所以免费用户也可以搭搭便车。如果有人想要赞助（服务器，CDN，打钱），老冯也非常欢迎。

curl https://repo.pigsty.io/pig | bash
pig repo add pgdg  # 添加 PGDG 仓库

这让老冯回想起一些往事，两年前老冯想要把 PG 扩展搞进来，但是想要偷懒借力，我看到有个叫 Tembo 还有 pgxman 的公司尝试在做 PG 扩展包管理器， 我就等啊等啊等了几个月，等到最后发现他们纯粹是光吹牛不干活，老冯就不等直接自己上了，做了 pig 包管理器，pg 扩展目录和扩展仓库，现在成为了 PG 生态最大的扩展仓库。 就好比像 Omnigres 和 Autobase 这样的开源 PG 发行版/项目，也都使用 老冯维护的 Pigsty 扩展仓库，向他们的客户去交付。老冯的软件仓库也开始成为别人的供应链的上游了。

“开源” 确实并不要求你向用户提供可靠稳定的二进制制成品，但真正重要的不是开源，而是信任 。 开源只是构建信任一种形式，持续的投入，交付的承诺，专注的热情， 面对问题的担当。 想要成为值得信赖，受人尊敬的社区参与者，有许多东西比丢一份源代码到仓库要重要的多。

归档说明（2026-08-30）： 本文原载 vonng.com。文中的软件包数量、截图与上下文以原始发表日期为准；当前行为请以 PIG 文档和实时扩展目录为准。

1.14 - 卡脖子：PGDG切断镜像站同步通道

PGDG 切断 FTP rsync 同步通道，全球镜像站普遍断连，这次还真是卡了一把全球用户的脖子。

最近老冯在构建 Pigsty 离线包的时候发现，在本地测试的时候安装的 PostgreSQL 版本不太对，17.4 比最新的 17.5 落后了一个小版本。而且在 EL10 上测试的时候发现有几个仓库报错了。奇怪的是，在香港使用全球默认仓库没问题，一旦在本地使用中国的镜像站就报错。

清华 TUNA PostgreSQL 镜像停留在旧同步时间

仔细一看，发现国内的镜像站点都与 PostgreSQL 上游仓库失去同步了：清华大学开源软件镜像站（TUNA）最后一次成功同步是5月16号，而阿里云阿里云镜像站最后的同步时间戳是 2025 年 3-31。国外的镜像站，比如 mirrors.xtom.de 也出现了这种问题，最后一次同步是 6月20日，但也明显可以看出手动更新与脱离同步的痕迹。

阿里云 PostgreSQL 镜像停留在旧同步时间

我搜索了一下，发现了在 PostgreSQL 邮件列表里 5月20日已经有韩国镜像站的维护者问了这个问题了，镜像站的维护者问之前用 rsync 同步 PGDG 官方仓库怎么突然断了？

PostgreSQL 贡献者之一的 Dave Page 回复到因为有大量的非法流量涌入 —— 他们决定永久关闭了原来非正式的 FTP 服务器，不再提供 rsync 同步选项，只允许通过 HTTP 访问了。

PostgreSQL 邮件列表中宣布关闭 FTP 与 rsync 的回复

Re: rsync pgsql-ftp access

PostgreSQL 作为世界上最流行的数据库软件，绝大多数用户都是通过 PGDG 官方仓库下载安装预制的二进制成品软件，而非从源码编译。而这个仓库就托管在两台物理机上 —— 根据 PostgreSQL Infra Team 的统计，大概每天有 六千六百万的请求（约每秒 750 次下载），每天约 10 TB 的数据传输。

PGDG 仓库流量与服务器架构

PGConf.dev 2025：PostgreSQL 监控功能的设计与实现

而且这个决定就是在 PGConf.Dev 2025 最后一天进行的，他们还有个演讲，说本来有四台服务器，现在就剩两台了，前面套了个 CDN。 然后一看这个流量太大吃不住，咔嚓一下 rsync / ftp 一关，全世界的 PostgreSQL 下游仓库都断了。 老实说，老冯觉得这是一件很扯淡的事情 —— 你把这些镜像站都挡在外面，用户到时候直接涌入原始上游，那流量不是更大了么。

开源基础设施背后的隐性维护成本

但老实说，你还真没法苛责他们什么，因为这就是开源的 STYLE —— 没有质保 —— 毕竟人家也没收钱，开发者没有义务去一直做慈善。 但从另一个角度来说 这还真是卡了一把全球用户的脖子 ：比如 17.5 修复的 CVE 漏洞，如果是用镜像站的用户，可能就没法及时更新了。

老冯已经把这个问题反馈给了 阿里云镜像站和 清华TUNA 镜像站的维护者，看看最近能不能修复。比如用 HTTP 去拉取更新。如果短时间内没法解决，老冯准备自己也把 PGDG 的仓库给拉下来一部分，丢到 Cloudflare 上先做一个镜像站。

向 TUNA 邮件列表反馈 PostgreSQL 镜像同步问题

从供应链安全的角度来看，Fork 魔改一个 PG 内核确实没什么卵用。但维护一个自己控制的软件二进制制成品仓库对于运维自主可控确实有着关键意义。

依赖上游软件供应链的风险示意图

老冯也一直在想要不自己在国内弄个镜像站点，毕竟都已经搞了一个 Pigsty APT/YUM 仓库，多放个 PG 也不是什么事儿。但其实阿里云和 TUNA 之前一直做的都不错，所以一直也都是用的这两家作为国内用户的默认配置。

至于长期来看，其实俺重新编译打包弄一个专门的 PostgreSQL 仓库也未尝不可，毕竟最近老冯也打包了好几种 PG 分支内核，还有 PG 生态中 PGDG 没有收录的 250 多个扩展。在构建 APT / YUM 仓库上已经是骨灰级打包侠了。不过，主要的问题还是维护太费时间，而且国内的流量费也太贵了。不过如果有金主赞助赞助不限流量的大带宽服务器，老冯也很乐意额外用爱发发电。

归档说明（2026-08-30）： 本文原载 vonng.com。文中的软件包数量、截图与上下文以原始发表日期为准；当前行为请以 PIG 文档和实时扩展目录为准。

1.15 - Postgres Extension Day，咱们不见不散

一年一度的 PostgreSQL 开发者大会即将在五月于蒙特利尔举办。同上次第一届 PG Con.Dev 一样，这次也有一天的额外的专场活动 —— Postgres Extensions Day。

一年一度的 PostgreSQL 开发者大会即将在五月于蒙特利尔举办。同上次第一届 PG Con.Dev 一样，这次也有一天的额外的专场活动 —— Postgres Extensions Day，关注 PG 扩展的开发，交付，发布等方方面面。目前议程刚刚排出来，总共安排了 14 个 Session。

PGEXT Day 2025 活动海报

当然这次，我就不当观众了，我的演讲是下午的首场 —— “The Missing Postgres Extension Repo and Package Manager”。即 “PG 生态中长久缺失的扩展仓库与包管理器”。 我会介绍 Pigsty 提供的扩展仓库，以及 pig 包管理器。并分享在构建，维护 PG 扩展时会遇到的挑战与问题，与全球开发者分享中国开发者与数据库厂商（个体户，哈哈）在这方面的工作、教训与经验。

PGEXT Day 2025 分享主题

PGEXT DAY 的举办日期是 2025.05.12 日，和 PG 开发者大会在相同的地点 —— 加拿大魁北克省蒙特利尔市，Plaza Centre-Ville。扩展峰会之后紧接着 12 - 16 号就是 PG 大会主会的日程了。

PGEXT Day 在蒙特利尔 Plaza Centre-Ville 的会场

去年 PG 开发者大会在温哥华举办，参加之后感觉收获满满，可惜来自中国的参加者寥寥无几。不知道这一届怎么样，如果您也会去现场欢迎留言，我们可以在现场碰一碰，线下面基。

如果您对 PostgreSQL 感兴趣，可不要忘了在 https://pgext.day 上注册 —— 友情提示，虽然 PGEXT DAY 属于 PGCON Dev 的附属活动，但不同于主会场 500 加币的门票，参加 pgext.day 是不收钱的！所以如果来参加 PG 开发者大会，可不要忘了这个。

下面是 PG 扩展峰会的日程安排，期待在扩展峰会与读者朋友们相见！

扩展峰会的日程

PGEXT Day 2025 日程安排

1. 从 pl/v8 到 pl/<any>：迈向更容易的扩展开发

9:00 am → 25 min，Hannu Krosing

From pl/v8 to pl/: towards easier extension development

pg_tle 为开发者打开了一扇新大门，让任何人都能在无超级用户权限的前提下编写并部署安全的扩展。它还提供一些钩子，供受信任语言的函数使用，例如强制执行密码策略。 而 pl/<any> 则进一步允许使用任意语言来编写数据库函数，从而实现扩展。其主要途径是在 JavaScript 中编写 Language Handler，并利用任意可被转译到 JavaScript 的语言，成为 PostgreSQL 的嵌入式（或“pl/”）语言。

示例包括：

  • pl/jsonschema：基于 AJV JSON Schema 校验库，将 JSON Schema 定义直接变为可运行的校验函数，性能有时远超使用 Rust + PGRX 封装的 pg_jsonchema。
  • pl/wasm：能以标准 PostgreSQL 函数的方式运行编译后的 WebAssembly，计算密集型代码速度可接近原生代码的 2-3 倍。
  • pl/codelength：示例性 Handler，把任何源代码变成一个返回原代码长度的函数。

未来还可在 pl/v8 基础上进一步拓展，例如：

  • 编写自定义 FDW（类似 Python 里 Multicorn）
  • 编写自定义逻辑解码插件
  • 暴露更多钩子和跟踪点，以便在 JavaScript 中添加 Handler
  • 让用户可直接构造计划树，甚至增加新的节点类型或监控探针

2. 将大版本升级封装成一个扩展

9:30 am → 25 min，Andrey Borodin

Upgrade as an extension

（暂无内容介绍，但这个标题看上去就很 Excited！）

3. 内联 Postgres 函数：现在与未来

10:00 am → 25 min，Paul Jungwirth

Inlining Postgres Functions, Now and Then

当 PostgreSQL 调用用户定义函数（或内置函数）时，可能会尝试进行内联，这为 SQL 开发者与扩展作者提供了新的可能性。本次分享将介绍 PostgreSQL 目前使用的两种内联方式（你现在就能用），以及一个正在开发中的补丁，旨在支持对大多数返回集函数进行内联。你的函数可用一个“计划树”自身替换，之后优化器会将它和查询中的其他部分融合在一起，这几乎就像写一个宏一样！

4. Postgres 点菜：自选扩展的动态容器镜像

10:30 am → 25 min，Alvaro Hernandez

Postgres à la carte: dynamic container images with your choice of extensions

在构建 Postgres 容器镜像时，通常需要捆绑所需扩展，但出于安全与体积考虑，不可能把所有数以百计的可用扩展一次性打包进去。 然而，不同用户需要的扩展组合又极其多样，如果为每一种可能组合都构建专属容器镜像，数量恐怕会超过宇宙中的原子数。

于是，“动态 OCI（容器）镜像”技术应运而生，可在实时、即时构建阶段，生成包含所需扩展的 Postgres 镜像。这些镜像可在 Kubernetes 等任何兼容 OCI 的环境中使用。

本次演讲将探讨动态容器镜像背后的理念与技术，以及如何应用它来为 Postgres 镜像加载任意扩展组合。演讲中会穿插大量演示！

5. Cppgres：少一个讨厌 C++ 的理由

11:00 am → 25 min，Yurii Rashkovskii

Cppgres: One less reason to hate C++

用 C 写 Postgres 扩展常常令人感觉繁琐、易错又重复度高。虽然很多开发者因为 C++ 的复杂性而对其敬而远之，但现代 C++ 拥有丰富特性，可让我们更轻松地编写可靠、易维护的 Postgres 扩展。

如果你还在考虑转投 Rust，不妨先看看 C++——只需沿用同样的编译器，也能享受到更多安全性与易用性。

本次分享将介绍 Cppgres：一个轻量级、仅含头文件的 C++20 库，能精简并强化 Postgres 扩展的安全性与可读性。借助概念、自动类型推导等现代 C++ 技巧，你能写出简洁、高效且可维护的扩展。让我们重新认识 C++，一起让 Postgres 扩展既安全又快乐！

6. 使用 MemoryContext 并调试 Postgres 中的内存泄漏

11:30 am → 25 min，Phil Eaton

Working with MemoryContexts and debugging memory leaks in Postgres

本次演讲将聚焦如何在实际场景中创建与切换 MemoryContext，并借助 Linux 的 eBPF 等工具来发现内存泄漏。内容基于生产环境中的真实案例，总结了在编写扩展并寻找 Bug 过程中的经验与实用技巧。

7. 作为控制平面的 Postgres：使用扩展卸载计算的挑战

12:00 pm → 25 min，Sweta Vooda

Postgres as a Control Plane: Challenges in Offloading Compute via Extensions

随着 Postgres 的角色从存储层扩展到控制平面，用于编排外部系统（例如向量搜索引擎）的扩展时，需要在性能、一致性与集成之间做好平衡。

本次分享将探讨如何设计 Postgres 扩展以卸载计算，并保持 SQL 简单性与事务保证。我们将结合 pgvector-remote 的实际经验，深入探讨缓冲、谓词下推、连接池及 VACUUM 等 Postgres 内部机制。

非常适合希望在 Postgres 中卸载计算，又想保留 SQL 简单性与性能的工程师。

8. 午餐

12:30 pm → 60 min

9. 缺失的 Postgres 扩展仓库与包管理器

1:30 pm → 25 min，Ruohang Feng

The Missing Postgres Extension Repo and Package Manager

哈哈，真的是我。

尽管 PostgreSQL 扩展功能强大又灵活，大多数用户还是希望“开箱即用”，而非自己编译与手动构建。为解决这一痛点，我整合了一个统一的仓库（pigsty.io/ext/list/），打包了 200+ 扩展，补足了官方 PGDG 仓库的缺口。这些 RPM/DEB 包支持 5 个 Linux 发行版、五个主流 PostgreSQL 版本以及 x86 与 ARM 架构，一站式覆盖。

本次分享将探讨如何构建这一仓库，包括跨发行版兼容、多架构支持、版本对齐等挑战，并分享经验教训及未来改进方向，让 PostgreSQL 扩展安装更轻松。

10. 如何自动在 PGXN 上发布你的扩展

2:00 pm → 25 min，David Wheeler

How to automatically release your extensions on PGXN

当前还没有一个所有 PostgreSQL 扩展的统一发布中心。PGXN 虽是目前最大的扩展源代码发布服务，但它仅收录了大约三分之一的公开扩展，且有些版本并不够新。

PGXN 致力于成为所有扩展版本的根注册中心，未来希望将所有发布信息同步给下游，以便自动化构建流程。要实现这一点，需要开发者主动将更新扩展上传至 PGXN，从而惠及整个 PostgreSQL 社区。

本次演讲将演示如何在 PGXN 上设置发布流程，以及通过 Git、JSON、GitHub workflows 等实现自动化，让你的扩展保持最新，一键发布到 PGXN。

11. 用 Java 扩展 PostgreSQL：克服 Java 与 C 应用交互的开发挑战

2:30 pm → 25 min，Cary Huang

Extending PostgreSQL with Java: Overcoming Development Challenges in Bridging Java and C Application

Java 和 C 两种语言设计理念与内存管理方式迥异。看似南辕北辙的两种语言，若掌握正确方法，依然可以配合得天衣无缝，一同扩展基于 C 的 PostgreSQL，并与 Java 应用或库联动。

本次演讲将分享 SynchDB 项目的开发历程，该项目通过在 PostgreSQL 端编写 C 扩展、并集成 Java 版 Debezium Embedded，引导来自 MySQL、SQL Server、Oracle 等多种源的数据变更流入 PostgreSQL。

我们将深入探讨在一个扩展内同时使用 C 与 Java 时面临的关键挑战与解决方案，包括：

  • 基于 JNI 的跨语言调用
  • 将 Debezium Embedded 嵌入 C 扩展的过程
  • 内存管理与性能开销的应对
  • 如何在架构层面整合 2 种语言组件
  • 错误处理、监控及可维护性最佳实践

听众将了解如何增强 PostgreSQL 在逻辑复制方面的能力，并学到在单一扩展中融合 C 与 Java 的开发要领。

12. 重新思考 OLAP 架构：pg_mooncake v0.2 的历程

3:00 pm → 25 min，Cheng Chen

Rethinking OLAP Architecture: The Journey to pg_mooncake v0.2

在本次演讲中，我们将探讨 pg_mooncake v0.1 所存在的不足，以及在 v0.2 中所做的主要架构变更。我们还会分享在使用 Postgres 复制、后台工作进程及扩展形式的进程间通信（IPC）过程中所获得的经验教训。

13. Spat：劫持共享内存，在 PostgreSQL 中获得类 Redis 的使用体验

3:30 pm → 25 min，Florents Tselai

Spat: Hijacking Shared Memory for a Redis-Like Experience in PostgreSQL

传统数据库常把共享内存用于查询执行、缓存与事务管理等工作区，对用户不可见。但如果我们把它改造成可供用户直接使用的高性能数据结构和缓存又会怎样？

本次分享将介绍 PostgreSQL 向扩展开发者开放的共享内存 API（包括新的 DSM Registry），以及如何构建 Spat：一个把数据完全存储在共享内存、可在 PostgreSQL 内部提供类 Redis 体验的内存数据结构服务器。

Spat 提供类似键值存储的模式，支持字符串、列表、集合、哈希等结构，成为 PostgreSQL 内部轻量且高速的临时存储方案。 我们会探讨在这种超出传统范畴的共享内存用法中遇到的种种挑战与机遇，为有意将 PostgreSQL 扩展到新高度的开发者提供思路。

14. 使用 Citus 扩容 PostgreSQL：为现代应用而生的分布式数据

4:00 pm → 25 min，Mehmet Yilmaz

Scaling PostgreSQL with Citus: Distributed Data for Modern Applications

本次演讲将探讨 Citus 扩展如何将 PostgreSQL 演变为可横向扩展的分布式数据库。我们会深入介绍 Citus 的架构、作为扩展的部署方式，以及实际生产环境中的应用要点。

内容包括：

  • Citus 如何将 PostgreSQL 扩展为支持分布式查询处理与数据分片
  • 扩展打包、发布及在不同环境部署的最佳实践
  • 在分布式 Postgres 集群的运维中，性能调优与安全机制的思考
  • 成功落地的真实案例和经验教训

15. 扩展能力：新选项与愿望清单

4:30 pm → 25 min，Alastair Turner

Extensibility - new options and a wish list

当下是成为 PostgreSQL 扩展开发者的好时机——社区不断壮大，甚至出现了专门的扩展峰会活动。

同时，Postgres 也在持续开放更多可扩展领域。过去一年里，一些核心提交让 EXPLAIN、累计统计、COPY 等部分也具备可扩展性，但在存储等少数领域上，相关提案仍待推进。

本次分享将带你了解近期新的可扩展领域（附示例代码），并探讨在那些尚未突破的领域（尤其存储）上可能的改进与努力方向。

16. 晚餐

6:00 pm – 9:00 pm

Dinner

回顾 2024 年 PGCon.Dev

归档说明（2026-08-30）： 本文原载 vonng.com。文中的软件包数量、截图与上下文以原始发表日期为准；当前行为请以 PIG 文档和实时扩展目录为准。

1.16 - 小猪骑大象：PG内核与扩展包管理神器

PostgreSQL 与 Pigsty 中长期缺失的一个包管理器 —— PIG。

微信公众号

最近我在忙一个非常有趣的新项目，这两天总算弄完了。各位朋友们，给大家介绍一下这个有趣的小东西，PostgreSQL 与 Pigsty 中久久缺失的一个命令行工具，我称之为 “pig”。

那么 pig 是干什么的？简单来说，这是一个 PostgreSQL 的包管理器，也是 PostgreSQL 与 Pigsty 中久久缺失的一个命令行工具，它可以在主流 Linux 操作系统上提供跨发行版的丝滑无缝的 PostgreSQL 安装部署体验。而且还通过国内镜像解决了下载速度慢和部分仓库被墙的问题。

PIG 包管理器与 PostgreSQL 大象

当然，安装 PG 这种事算不上有什么技术挑战，真正有难度的是 PostgreSQL 生态中的扩展插件。PostgreSQL 有着数据库世界中独一无二的繁荣扩展生态，提供各种强大而惊人的能力。而 pig 则能够在（Debian / Ubuntu / EL ）三大 Linux 主流发行版（五个大版本 x AMD/ARM 两大架构）上，提供 340 个 PG 插件开箱即用的能力。

PostgreSQL 扩展生态全景图

为什么插件对 PG 至关重要？请参阅《PostgreSQL正在吞噬数据库世界》

快速上手

pig 本身是一个 Go 编写的二进制程序，您可以直接从 Release 页面下载，或者使用 Pigsty 现成提供的 YUM / APT 仓库，使用操作系统的包管理器安装。

curl -fsSL https://repo.pigsty.io/pig | bash     # cloudflare 全球仓库（默认）
curl -fsSL https://repo.pigsty.cc/pig | bash     # 中国大陆墙内镜像仓库

使用 pig 分两个步骤，首先，使用 repo 子命令添加上游仓库

$ pig repo add pigsty pgdg -u  # 添加 pgdg & pigsty 仓库并更新缓存（比较礼貌的做法）
$ pig repo set -u              # 你也可以用这个命令直接移除所有现有Repo，并覆盖添加所有必须的Repo，粗暴但有效

$ pig ext install pg17         # 如果您没有安装 PostgreSQL 内核，可以使用这种方式安装 PGDG 内核包
$ pig ext install pg_duckdb    # 默认针对当前活跃的 PG 安装扩展，例如安装：pg_duckdb 扩展（针对活跃的 PG17）

然后，您就可以使用 ext 子命令搜索，查阅，安装，卸载，更新扩展了。是的，如果你就是安装个扩展，也就是一行命令这么简单。

你可以用命令行完成各种操作，文档里会详细介绍各种高级用法。此外，pig 还提供了一个 sty 子命令，用于安装 Pigsty 本身：

pig sty init     # 默认安装嵌入的最新 Pigsty 版本
pig sty boot     # 执行 Bootstrap，安装 Ansible
pig sty conf     # 执行 Configure，生成配置文件
pig sty install  # 执行 install.yml 剧本完成部署

为什么需要包管理器？

那么在包管理器出现之前，用户想要安装 PostgreSQL 及其扩展，是怎么样的体验呢？当然你可以直接从源代码编译。PG 内核本身编译安装还是“很简单”的，几条命令就可以，不过 PG 生态的核心扩展 —— 地理空间事实标准 PostGIS 的编译安装基本上就立刻跳到地狱难度了。

尽管如此，编译安装对 绝大多数用户 来说基本属于早已失传的古代技能了。根据我对社区的观察，你能对用户做出的最大期待就是会用 yum/apt install，然后会照着文档敲为数不多的 Linux 命令。再高的工作假设就显得不切实际了。

PostgreSQL 官方下载页面

PostgreSQL 官方下载页面

PGDG官方仓库有什么问题？

尽管 PostgreSQL 官方提供了官方的 PGDG YUM / APT 仓库，但是这里依然有不少的问题：首先扩展数量只有一百个左右，其次，这里只有一半扩展是同时在 YUM / APT 仓库中提供的。最后，针对不同的 PG 大版本，芯片架构，操作系统发行版版本，经常性的会出现某个组合下的扩展缺失与错漏。

PGDG 扩展在 RPM 与 DEB 仓库中的可用性对比

为了解决这个问题，我们提供了一个 PGDG 补充仓库，这有点类似于 EL Linux 上的 EPEL 源，补齐了大量缺失的扩展插件，并实现了 Debian / Ubuntu / EL 三大主流 Linux 的扩展功能集对齐，补齐了一块行业空白。我们的扩展仓库完全遵循 PGDG 的打包规范与命名惯例，使用相同的环境构建，确保与官方内核包无缝衔接对齐。

TimescaleDB 扩展的软件包可用性矩阵

为什么用操作系统包管理器？

pig 被设计为原生使用 Linux 操作系统发行版现有的包管理器（yum / dnf / apt ），而非自己造一个全新的轮子。这是因为操作系统在解决依赖管理，升级降级这些问题上已经有了非常成熟且标准的实践了。并且毫无疑问最广大 PostgreSQL 用户群体早已接受并习惯于这一标准，因此我们认为打破这一标准的做法是远远弊大于利的。

因此，pig 仓库使用的软件包全部使用操作系统标准的 RPM / DEB 格式进行封装，确保它可以在主流的 Linux 发行版上丝滑安装与运行。Pigsty 在不同操作系统发行版上提供了一层统一的抽象，你只需要知道扩展名就可以安装，你不需要操心 PG 版本号，OS 大小版本，芯片架构，pig 会为你处理好所有细节。

$ pig ext scan

Installed:
* PostgreSQL 17.2  74  Extensions

Active:
PG Version      :  PostgreSQL 17.2
Config Path     :  /usr/pgsql-17/bin/pg_config
Binary Path     :  /usr/pgsql-17/bin
Library Path    :  /usr/pgsql-17/lib
Extension Path  :  /usr/pgsql-17/share/extension
Name                 Version  SharedLibs                                                           Description            Meta
----                 -------  ----------                                                           ---------------------  ------
amcheck              1.4      functions for verifying relation integrity                           module_pathname=$libdir/amcheck relocatable=true lib=amcheck.so
anon                 1.3.2    Data anonymization tools                                             directory=extension/anon relocatable=false superuser=false module_pathname=$libdir/anon lib=anon.so
auth_delay           -        pause briefly before reporting authentication failure                lib=auth_delay.so
...
wal2json             2.5.3    Changing data capture in JSON format                                 lib=wal2json.so
xml2                 1.1      XPath querying and XSLT                                              module_pathname=$libdir/pgxml relocatable=false lib=pgxml.so

Encoding Libs: cyrillic_and_mic, euc2004_sjis2004, euc_cn_and_mic, euc_jp_and_sjis, euc_kr_and_mic, euc_tw_and_big5, latin2_and_win1250, latin_and_mic, utf8_and_big5, utf8_and_cyrillic, utf8_and_euc2004, utf8_and_euc_cn, utf8_and_euc_jp, utf8_and_euc_kr, utf8_and_euc_tw, utf8_and_gb18030, utf8_and_gbk, utf8_and_iso8859, utf8_and_iso8859_1, utf8_and_johab, utf8_and_sjis, utf8_and_sjis2004, utf8_and_uhc, utf8_and_win

Built-in Libs: dict_snowball, libecpg, libecpg_compat, libpgtypes, libpq, libpqwalreceiver, llvmjit

Unmatched Shared Libraries: psqlodbc, psqlodbca, psqlodbcw
psqlodbc
psqlodbca
psqlodbcw

使用 pig 工具扫描已安装的 PG 扩展

这个项目的价值在哪里？

抽象是软件能提供的核心价值。而 Pig 提供了一个相当优雅的抽象，解决好了 PostgreSQL 内核与扩展安装的问题。其实 Pigsty 在之前已经非常好的解决了这个问题 —— 你可以一键从裸操作系统上拉起装好所有 PG 扩展的插件，自带监控系统，高可用，PITR，还不要钱！

但我能理解，这样一个一揽子一条龙全家桶解决方案并非适用于所有用户 —— 特别是许多外国人更喜欢：每个工具做好一件事做到极致的方式。pig 其实是用 Go 重写了 Pigsty 的包管理部分。只不过之前 Pigsty 是用 Ansible Playbook 实现的，有个 Python 依赖。而 Pig 是一个干干净净没有依赖的 Go 二进制程序，开箱即用。

pig 除了可以一键安装 PG 扩展，当然也可以一键安装各种版本的 PG 内核。

这个项目的核心壁垒是什么？

pig 只是一个小工具，真正重要的是这个工具背后的 Pigsty 扩展仓库。这个仓库里维护了 140 个 PG 扩展，以及各种针对 PGDG 仓库补漏的构件。要构建这个扩展仓库，你需要有丰富的 PostgreSQL 经验与 Linux 操作系统经验，你需要同时熟悉 RHEL 与 Debian/Ubuntu 的打包方法，而老实说这是一项相当稀缺的技能。

我曾经跟 Pivotal （Greenplum）的团队聊天，老板说他们亟缺构建打包的专家。其实很容易就能看出来，他们发布的时候就一个可怜的 CentOS RPM 包。当然，说他们一句国内 PostgreSQL 综合实力第一的团队应该不为过，而这样的团队却依然没有懂这个的，这确实给我了一些启发。

现在这个仓库是什么状态

目前这个仓库里面提供了 150 个独特的 PG 扩展，包括二十来个 Rust 编写的强力扩展。独特的意思就是没有被收录到 PGDG 官方仓库里。PGDG 官方仓库有 100 个左右扩展，PIGSTY 仓库提供了 150 个，再加上 PG 自带的 70 个，总数 320 个，不过有些扩展只在 EL 有，有的只在 DEB 上有，所以总可用扩展数量目前是 340 个。

Provide 340 available extensions as RPM / DEB for PostgreSQL 13 - 17 in addition to the official PGDG repo.

Available on Linux: Debian 12 / Ubuntu 24.04 / 22.04 / EL8 / EL9 compatible OS distros, and x86_64 & ARM64 architectures.

Entry / Filter All PGDG PIGSTY CONTRIB MISC MISS PG17 PG16 PG15 PG14 PG13
RPM Extension 334 114 147 69 4 6 303 330 333 321 303
DEB Extension 327 104 150 69 4 13 304 323 326 319 300

这 340 个扩展的质量很高，是已经经过我严格筛选后的结果。一些没鸡毛用的扩展，缺乏维护，年久失修的扩展，代码质量差的扩展，无法跨平台兼容的扩展，已经被我无情淘汰了大概二三十个了。我们有一个 PGEXT.CLOUD 扩展目录，详细收录了这 340 个扩展的元数据详情。在 pig 命令行工具里面也提供了检索与查阅详情的能力。

Pigsty 仓库的 Cloudflare 下载流量

目前这个仓库托管在 Cloudflare 上，国内镜像放在腾讯云 CDN 上。每个月的下载量算上镜像大概 500 GB 左右，考虑到一个扩展也就几百KB，这个下载量还是相当可观的。

Pig 使用什么开源协议，如何考虑？

这个仓库本身的代码，以及 pig 工具没有使用 Pigsty 的严格 AGPLv3 协议，而是宽松的 Apache-2.0 开源许可证，这样做的目的也是为了让更多的用户与厂商参与进来。目前，这个仓库已经成为了两家友商 AutoBase （原 postgresql_cluster）和 Omnigres 默认使用的上游扩展仓库。

目前，我也在游说 CloudNativePG，Neon 和 Supabase 使用这个扩展仓库，我觉得问题不大，因为这属于互惠共赢的事情 —— 这些 PostgreSQL 发行版马上也可以宣称自己和 Pigsty 一样，340 个扩展开箱即用，哈哈。Omnigres 的创始人 Yurii 下下周来上海（PostgreSQL生态大会）跟我勾兑，我们准备搞个大新闻，尽可能把它做成 PG 世界的一个新事实标准。

为什么是你来做，而不是别人？

在年初，我提出了 可扩展性（Extensibility） 是 PostgreSQL 的核心属性，得到了社区的广泛认可与响应。我其实是期待生态里面有其他的人能够站出来，解决 PG 扩展分发的问题的。我曾经比较看好 Tembo 的愿景 —— 他们做了个 Trunk （宝箱），其实就是一个 PG 包管理器。我希望他们能做的足够好，这样我就不用操心扩展打包这些活了，直接拿过来就能用，整合到我的 PostgreSQL 发行版 Pigsty 里。

Tembo Trunk PostgreSQL 扩展目录

但是这半年观察下来，我发现包括 Trunk 也好，PGXMAN 也好，都是雷声大雨点小，不干实事的家伙，折腾来折腾去就那么些老扩展。而且愿景也比较扯蛋 ：放着现有的 YUM / APT 实事标准不弄，一会弄个 OCI 镜像分发，一会弄个新 Catalog，唯独就是不解决用户的核心痛点 —— ”我他喵的现在就是想用这个扩展怎么办？“

pgxman PostgreSQL 扩展目录

五年前，我在 PostgreSQL 生态寻找足够好的监控系统，也遇到过这个问题。社区不给力怎么办，当然是我行我上了。所以我也懒得等了，直接自己上了。老实说这里有许多难题要解决，但技术问题都是可以解决的。在这半年里，我在这个领域积累了独一无二的经验 —— 一个人就维护了超过整个 PGDG 仓库，占总数近 60% 的扩展包。

Pigsty 扩展仓库可用性矩阵

谁还用包管理器，Docker不香吗？

我在 《把 PostgreSQL 放入 Docker 是一个好主意吗》这篇文章中深入聊过这个问题，其中特别提到过扩展的问题。总的来说，会遇到：扩展持久化的问题，安装扩展需要重新构建镜像，推送并重启的问题，难以同时组合使用扩展的问题。

一个简单的例子是插件与包管理，PostgreSQL提供了很多实用的插件，譬如PostGIS。假如想为数据库安装该插件，在裸机上只要 yum install 然后 create extension postgis 两条命令就可以。但如果是在Docker里，按照Docker的实践原则，用户需要在镜像层次进行这个变更，否则下次容器重启时这个扩展就没了。因而需要修改Dockerfile，重新构建新镜像并推送到服务器上，最后 重启数据库容器，毫无疑问，要麻烦的多。

包管理是操作系统发行版的核心问题。然而 Docker 搅乱了这一切，例如，许多 PostgreSQL 不再以 RPM/DEB 包的形式发布二进制，而是以加装扩展的 Postgres Docker 镜像分发。这就会立即产生一个显著的问题，如果我想同时使用两种，三种，或者PG生态的一百多种扩展，那么应该如何把这些散碎的镜像整合到一起呢？相比可靠的操作系统包管理，构建Docker镜像总是需要耗费更多时间与精力才能正常起效。

而且最重要的是你如果去看各种 PostgreSQL Docker 镜像的 Dockerfile 就会发现，它们几乎全都是使用操作系统的软件包来安装扩展的。说到底，这些活是省不了的。用 Docker 也改变不了这一点。

为什么叫 pig 这个名字？

我有一个开源的 PostgreSQL 发行版叫 Pigsty （猪圈），那么 pig 是作为 Pigsty 的管理命令行工具而存在的。猪圈里的动物是什么，自然是猪（pig）。当然，即使你不使用 Pigsty 这个 PG 发行版，你也可以独立使用 pig 这个命令行工具来安装，管理 PostgreSQL 与 扩展。

Apache Pig 项目标志

有一个比较有名项目叫 Apache Pig ，在 Hadoop 上提供 SQL-Like 的查询语言支持（Pig Latin），已经占用了 Pig 这个名字，我也思考了很久要不要使用其他名字比如 pk （pigsty keeper，猪圈管理员），或者就叫 pg 。但最后还是决定叫 pig，反正 Apache Pig 已经过气了，使用这套工具的环境和 Apache Hadoop 的用户也尿不到一个壶里去，基本没有命名冲突的风险，所以就这么办了。

下一步 pig 会如何发展？

如你所见，Pig 目前是作为 PostgreSQL 扩展管理器发布的，但它本质上是 Pigsty 的管控命令行工具。后续我会添加更多的功能，尽可能多地把 Pigsty 的一些功能移植进 pig 里来。

在另一个方面，既然我已经成为了构建打包编译大师，那么就应该把这个技能发挥到极致。目前 Pigsty 除了支持原生的 PG 内核之外，还支持 IvorySQL，PolarDB，Babelfish 这样的 PG 分叉内核（分别提供 Oracle 兼容，RAC，MSSQL 兼容能力），但有一个问题就是这些数据库内核目前是没有扩展支持的。比如，如果你想在兼容 Oracle 语法（使用 PolarDB-O 或 IvorySQL）的同时使用 pgvector，那你只能自己去编译。

PostgreSQL 生态的各种内核分叉 —— Kernels

我的计划是针对主流的 PG Fork，统一提供主流 Linux 系统上的 RPM/DEB 内核包 + 扩展包。让这些分叉也可以做到 340 个 PG 扩展开箱即用。目前我已经基本跑通了 OrieloDB 的流程，可能会在下个版本有一个草案与初步实现。

最后

希望 pig 这个工具，可以帮助你享受 PostgreSQL 和扩展插件的乐趣～。

小猪骑着 PostgreSQL 大象

归档说明（2026-08-30）： 本文原载 vonng.com。文中的软件包数量、截图与上下文以原始发表日期为准；当前行为请以 PIG 文档和实时扩展目录为准。

1.17 - PostgreSQL神功大成！最全扩展仓库来了！

PG扩展很多很强大，但如何安装并使用起来一直都是社区的难题。现在有了Pigsty扩展仓库，390个强力插件开箱即用。

最近没怎么更新，因为在憋大招。最近功成出关，遂发此文为贺 —— 我做了一个收录PG生态所有能打的390个扩展的仓库，让 PostgreSQL 在成为数据库全能王的道路上又往前迈出了坚实的一步！

自从我在 《PostgreSQL正在吞噬数据库世界》 一文中指出 可扩展性 对于 PostgreSQL 的重要性以来，PG 社区对此进行了热烈的讨论，并且达成了共识。 最终体现在《PostgreSQL 17 发布注记！》中。

但真正重要的事情不是认识世界，而是改变世界。既然大家都已经认清了扩展很重要，那么我们应该做什么，怎么做，就成了真正关键的问题。

那么什么是 PostgreSQL 扩展最关键的问题？在我看来，扩展用得上用不上，是 PG 扩展生态的首要问题。

PG 扩展分发现状

大家知道 PG 生态有很多扩展插件，但这些扩展插件如何安装使用？这第一道门槛就成了许多用户的拦路虎。怎么解决这个问题？ PGXN 说，用我的办法，我可以现场下载编译扩展； Tembo 说，我提前帮你打好 docker 镜像； StackGres 和 Omnigres 说，我们可以在线下载编译好的 So 文件； 八仙过海，各显神通。

大家都有很多好想法，唯独没仔细考虑绝大多数用户到底是如何安装扩展的。 作为前 DBA，我只能说什么现场编译，OCI镜像，下载so文件，在实战中都有些离谱了 —— 使用最广泛且最可靠的扩展安装方式，依然是用操作系统的包管理器安装签名二进制包。 而 yum / dnf / apt 在解决这个问题上已经做的足够好了！所以真的问题其实是，谁来把这几百个扩展插件打成开箱即用的软件包？

TIME: timescaledb timescaledb_toolkit timeseries periods temporal_tables emaj table_version pg_cron pg_later pg_background GIS: postgis postgis_topology postgis_raster postgis_sfcgal postgis_tiger_geocoder address_standardizer address_standardizer_data_us pgrouting pointcloud pointcloud_postgis h3 h3_postgis q3c ogr_fdw geoip pg_polyline pg_geohash mobilitydb earthdistance RAG: vector vectorscale vectorize pg_similarity smlar pg_summarize pg_tiktoken pgml pg4ml FTS: pg_search pg_bigm zhparser hunspell_cs_cz hunspell_de_de hunspell_en_us hunspell_fr hunspell_ne_np hunspell_nl_nl hunspell_nn_no hunspell_pt_pt hunspell_ru_ru hunspell_ru_ru_aot fuzzystrmatch pg_trgm OLAP: citus citus_columnar columnar pg_analytics pg_duckdb pg_mooncake duckdb_fdw pg_parquet pg_fkpart pg_partman plproxy pg_strom tablefunc FEAT: age hll rum pg_graphql pg_jsonschema jsquery pg_hint_plan hypopg index_advisor plan_filter imgsmlr pg_ivm pgmq pgq pg_cardano rdkit bloom LANG: pg_tle plv8 pllua hstore_pllua plluau hstore_plluau plprql pldbgapi plpgsql_check plprofiler plsh pljava plr pgtap faker dbt2 pltcl pltclu plperl bool_plperl hstore_plperl jsonb_plperl plperlu bool_plperlu jsonb_plperlu hstore_plperlu plpgsql plpython3u jsonb_plpython3u ltree_plpython3u hstore_plpython3u TYPE: prefix semver unit md5hash asn1oid roaringbitmap pgfaceting pg_sphere country currency pgmp numeral pg_rational uint uint128 ip4r uri pgemailaddr acl debversion pg_rrule timestamp9 chkpass isn seg cube ltree hstore citext xml2 FUNC: topn gzip zstd http pg_net pg_smtp_client pg_html5_email_address pgsql_tweaks pg_extra_time timeit count_distinct extra_window_functions first_last_agg tdigest aggs_for_vecs aggs_for_arrays arraymath quantile lower_quantile pg_idkit pg_uuidv7 permuteseq pg_hashids sequential_uuids pg_math random base36 base62 pg_base58 floatvec financial pgjwt pg_hashlib shacrypt cryptint pguecc pgpcre icu_ext pgqr envvar pg_protobuf url_encode refint autoinc insert_username moddatetime tsm_system_time dict_xsyn tsm_system_rows tcn uuid-ossp btree_gist btree_gin intarray intagg dict_int unaccent ADMIN: pg_repack pg_squeeze pg_dirtyread pgfincore pgdd ddlx prioritize pg_checksums pg_readonly safeupdate pg_permissions pgautofailover pg_catcheck pre_prepare pgcozy pg_orphaned pg_crash pg_cheat_funcs pg_savior table_log pg_fio pgpool_adm pgpool_recovery pgpool_regclass pgagent vacuumlo pg_prewarm oid2name lo basic_archive basebackup_to_shell old_snapshot adminpack amcheck pg_surgery STAT: pg_profile pg_show_plans pg_stat_kcache pg_stat_monitor pg_qualstats pg_store_plans pg_track_settings pg_wait_sampling system_stats meta pgnodemx pg_proctab pg_sqlog bgw_replstatus pgmeminfo toastinfo explain_ui pg_relusage pg_top pagevis powa pageinspect pgrowlocks sslinfo pg_buffercache pg_walinspect pg_freespacemap pg_visibility pgstattuple auto_explain pg_stat_statements SEC: passwordcheck_cracklib supautils pgsodium supabase_vault pg_session_jwt anon pg_tde pgsmcrypto pgaudit pgauditlogtofile pg_auth_mon credcheck pgcryptokey pg_jobmon logerrors login_hook set_user pg_snakeoil pgextwlist pg_auditor sslutils noset sepgsql auth_delay pgcrypto passwordcheck FDW: wrappers multicorn odbc_fdw jdbc_fdw mysql_fdw oracle_fdw tds_fdw db2_fdw sqlite_fdw pgbouncer_fdw mongo_fdw redis_fdw redis kafka_fdw hdfs_fdw firebird_fdw aws_s3 log_fdw dblink file_fdw postgres_fdw SIM: orafce pgtt session_variable pg_statement_rollback pg_dbms_metadata pg_dbms_lock pg_dbms_job babelfishpg_common babelfishpg_tsql babelfishpg_tds babelfishpg_money pgmemcache ETL: pglogical pglogical_origin pglogical_ticker pgl_ddl_deploy pg_failover_slots wal2json wal2mongo decoderbufs decoder_raw test_decoding mimeo repmgr pg_fact_loader pg_bulkload

PostgreSQL 的 PGDG 官方仓库中，提供了大约 100 个左右的扩展，但存在各种问题：有的扩展在 Debian/Ubuntu 的 APT 仓库里有，在 EL 系统的 YUM 仓库里没有； 有的扩展在 EL8 上有，EL9 没有；有的扩展在 Ubuntu 22 上有，在 24 上没有；有的扩展针对 PostgreSQL 12 - 15 提供，PG 16，17 不提供；有的扩展只有 x86_64 架构，没有 arm 架构；有时候碰上这种问题确实蛮让人头疼。

怎么办？我行我上！

作为一个 PostgreSQL 发行版维护者，我曾经寄希望于 PG 生态的其他人来解决这个问题。 每当我看见 PGDG 仓库有出现错漏缺失，我都会第一时间反馈给仓库维护者 Devrim 和 Cris 。

有的时候这种模式挺管用，比如去年当我发现 pgvector 这个强力向量数据库扩展还没有二进制软件包制成品时，我第一时间提给 Devrim ， 将其放入 PGDG 仓库，然后 pgvector 遂成为 PG 生态中的向量数据库事实标准，进入到各家云厂商 RDS 中。

但有的时候，事情并不能总能如意。例如，Devrim 表示，他绝对不会接受任何 Rust 扩展插件进入 PGDG YUM 仓库。 但我确实有二十多个用 Rust 编写的 PostgreSQL 扩展需要分发（例如自建 Supabase 就需要 pg_graphql, pg_jsonschema, wrappers 三个 Rust 扩展），怎么办呢？

再比如说，最近 PG 生态非常火热的 DuckDB 缝合大赛，大家都在密集地更新跟进 DuckDB 系扩展 ，这些扩展插件我第一时间 打好了 RPM/DEB 包，但是如何分发呢？

思来想去，我决定还是我行我上，自己维护一个 PostgreSQL 扩展插件的 APT / YUM 仓库，分发 PG 扩展。

PGEXT.CLOUD 扩展目录首页

PG 扩展大全

在过去的半年中，我的工作重心放在 PG 扩展生态的整合上。而最近，这项工作终于达到了一个让我自己感到满意的里程碑。我建设了一个 PG Yum/APT 仓库，收录了 340 个可用 PG 扩展的元数据，以及二进制制成品。

Entry / Filter All PGDG PIGSTY CONTRIB MISC MISS PG17 PG16 PG15 PG14 PG13 PG12
RPM Extension 334 119 139 70 4 6 301 330 333 319 307 294
DEB Extension 326 104 143 70 5 14 302 322 325 316 303 293
RPM Package 251 107 138 1 4 1 220 247 250 239 229 216
DEB Package 241 90 142 1 5 1 218 237 240 234 223 213

以上是这个仓库的一些统计数字：总共有 340 个可用 Extension，去除 PG 自带的 70 个，总共 270 个第三方扩展插件。这 270 个扩展插件中，有小一半是 PGDG 官方仓库维护的（126个RPM扩展，102个DEB扩展），另外的大一半（131个RPM，143个DEB）都是由我维护，修复，编译，打包，测试，分发的。

每一个扩展，我都针对最新的 PostgreSQL 12 - 17 这六个生命周期大版本分别打包构建，针对 EL8，EL9，Ubuntu 22.04，Ubuntu 24.04，以及 Debian 12 这五个绝对主流 Linux 发行版构建。此外也对 EL7，Debian 11， Ubuntu 20.04 这些过保系统提供部分有限支持。

PGEXT.CLOUD 扩展仓库使用说明

这个仓库还解决了扩展对齐的问题，例如，原本在 APT 和 YUM 仓库中的扩展，APT 有一小半几十个扩展 YUM 仓库没有，YUM 仓库有一小半 APT 仓库没有。我把两者独有的扩展都尽可能移植到另一个操作系统生态中，现在只有 7 个 APT 扩展在 YUM 仓库中缺失，16 个扩展在 APT 仓库缺失，只占总数的 6%。很多 PGDG 扩展版本缺失的问题，也在这里得到了一并修复。

我提供了一个完整的目录，列出了支持的扩展，并且对每一个扩展，都给出了详情，依赖安装说明与注意事项。

PostGIS 扩展详情页面

我想，用户吭哧吭哧抱怨扩展编译失败的问题，应该能在这里得到最终的解决。

当然题外话是广告时间，安装这些扩展，使用这个仓库的最简单的方式是什么？当然是开箱即用的 PostgreSQL 数据库发行版 —— Pigsty —— 但这并非必选项。 你依然可以用简单的一行 shell 在任何 EL/Debian/Ubuntu 系统上启用此仓库。

使用Pigsty一次性配置好并拉起用于自建Supabase的PostgreSQL集群，只要简单地声明要安装哪些扩展插件即可！

一键自建 Supabase 所需的 PostgreSQL 集群，请参考样例配置文件：conf/supabase.yml。

# pg-meta, the underlying postgres database for supabase
pg-meta:
  hosts: { 10.10.10.10: { pg_seq: 1, pg_role: primary } }
  vars:
    pg_cluster: pg-meta
    pg_users:
      # supabase roles: anon, authenticated, dashboard_user
      - { name: anon           ,login: false }
      - { name: authenticated  ,login: false }
      - { name: dashboard_user ,login: false ,replication: true ,createdb: true ,createrole: true }
      - { name: service_role   ,login: false ,bypassrls: true }
      # supabase users: please use the same password
      - { name: supabase_admin             ,password: 'DBUser.Supa' ,pgbouncer: true ,inherit: true   ,roles: [ dbrole_admin ] ,superuser: true ,replication: true ,createdb: true ,createrole: true ,bypassrls: true }
      - { name: authenticator              ,password: 'DBUser.Supa' ,pgbouncer: true ,inherit: false  ,roles: [ dbrole_admin, authenticated ,anon ,service_role ] }
      - { name: supabase_auth_admin        ,password: 'DBUser.Supa' ,pgbouncer: true ,inherit: false  ,roles: [ dbrole_admin ] ,createrole: true }
      - { name: supabase_storage_admin     ,password: 'DBUser.Supa' ,pgbouncer: true ,inherit: false  ,roles: [ dbrole_admin, authenticated ,anon ,service_role ] ,createrole: true }
      - { name: supabase_functions_admin   ,password: 'DBUser.Supa' ,pgbouncer: true ,inherit: false  ,roles: [ dbrole_admin ] ,createrole: true }
      - { name: supabase_replication_admin ,password: 'DBUser.Supa' ,replication: true ,roles: [ dbrole_admin ]}
      - { name: supabase_read_only_user    ,password: 'DBUser.Supa' ,bypassrls: true ,roles: [ dbrole_readonly, pg_read_all_data ] }
    pg_databases:
      - name: postgres
        baseline: supabase.sql
        owner: supabase_admin
        comment: supabase postgres database
        schemas: [ extensions ,auth ,realtime ,storage ,graphql_public ,supabase_functions ,_analytics ,_realtime ]
        extensions:
          - { name: pgcrypto  ,schema: extensions  } # 1.3   : cryptographic functions
          - { name: pg_net    ,schema: extensions  } # 0.9.2 : async HTTP
          - { name: pgjwt     ,schema: extensions  } # 0.2.0 : json web token API for postgres
          - { name: uuid-ossp ,schema: extensions  } # 1.1   : generate universally unique identifiers (UUIDs)
          - { name: pgsodium        }                # 3.1.9 : pgsodium is a modern cryptography library for Postgres.
          - { name: supabase_vault  }                # 0.2.8 : Supabase Vault Extension
          - { name: pg_graphql      }                # 1.5.9 : pg_graphql: GraphQL support
          - { name: pg_jsonschema   }                # 0.3.3 : pg_jsonschema: Validate json schema
          - { name: wrappers        }                # 0.4.3 : wrappers: FDW collections
          - { name: http            }                # 1.6   : http: allows web page retrieval inside the database.
          - { name: pg_cron         }                # 1.6   : pg_cron: Job scheduler for PostgreSQL
          - { name: timescaledb     }                # 2.17  : timescaledb: Enables scalable inserts and complex queries for time-series data
          - { name: pg_tle          }                # 1.2   : pg_tle: Trusted Language Extensions for PostgreSQL
    # supabase required extensions
    pg_libs: 'pg_stat_statements, pgaudit, plpgsql, plpgsql_check, pg_cron, pg_net, timescaledb, auto_explain, pg_tle, plan_filter'
    pg_extensions: # extensions to be installed on this cluster
      - supa-stack
      - timescaledb pg_cron pg_timetable
      - postgis pg_geohash
      - pgvector pgvectorscale pg_similarity smlar pg_summarize pg_tiktoken
      - pg_search pg_bigm zhparser hunspell
      - pg_analytics pg_parquet pg_duckdb
      - pg_hint_plan hll rum pg_graphql pg_jsonschema index_advisor pg_plan_filter hypopg pg_ivm pgmq pg_cardano
      - pg_tle plv8 plpgsql_check #pljava
      - pgunit md5hash asn1oid roaringbitmap pgfaceting pgsphere pg_country pg_currency pgmp numeral pg_rational pguint pg_uint128 ip4r pg_uri pgemailaddr acl timestamp9
      - pg_gzip pg_zstd pg_http pg_net pg_html5_email_address pgsql_tweaks pg_extra_time pg_timeit count_distinct extra_window_functions first_last_agg tdigest aggs_for_arrays aggs_for_vecs pg_arraymath quantile lower_quantile
      - pg_idkit pg_uuidv7 permuteseq pg_hashids sequential_uuids pg_math pg_random pg_base36 pg_base62 pg_base58 floatvec pg_financial pgjwt pg_hashlib shacrypt cryptint pg_ecdsa pgpcre icu_ext pgqr envvar pg_protobuf url_encode
      - pg_repack pg_squeeze pg_dirtyread ddlx pg_readonly safeupdate pg_permissions pg_savior pg_fio
      - pg_profile pg_show_plans pg_stat_kcache pg_stat_monitor pg_qualstats pg_track_settings system_stats pg_meta pgnodemx pg_sqlog bgw_replstatus toastinfo pg_explain_ui pg_relusage
      - passwordcheck supautils pgsodium pg_vault anonymizer pgsmcrypto pgaudit pgauditlogtofile pg_auth_mon credcheck logerrors login_hook set_user pgextwlist pg_auditor sslutils noset
      - wrappers mysql_fdw redis_fdw pg_redis_pubsub aws_s3 log_fdw
      - pglogical wal2json decoder_raw pg_fact_loader
    pg_parameters:
      cron.database_name: postgres
      pgsodium.enable_event_trigger: off
    pg_hba_rules: # supabase hba rules, require access from docker network
      - { user: all ,db: postgres  ,addr: intra         ,auth: pwd ,title: 'allow supabase access from intranet'    }
      - { user: all ,db: postgres  ,addr: 172.17.0.0/16 ,auth: pwd ,title: 'allow access from local docker network' }
    pg_vip_enabled: true
    pg_vip_address: 10.10.10.2/24
    pg_vip_interface: eth1

这个仓库里有什么？

在 Pigsty 的扩展仓库中，所有的扩展都已经被预先分为了十五类之一：TIME，GIS，RAG，FTS，OLAP，FEAT，LANG，TYPE，FUNC，ADMIN，STAT，SEC，FDW，SIM，ETL，如下所示。

请移步 pgext.cloud 查看完整详情。

一些感想与体会

PG 每个大版本都会引入一些变动，因此维护一百多个扩展插件并不是一件轻松的事情。特别是一些扩展的作者都好几年没动静了，那还真就只能自己上。我自己修复了十几个扩展插件，提供了最新的 PG 大版本支持。能联系上作者的，我也提交了一堆 PR 或者 Issue，推动解决。

GitHub 贡献活动

在这个过程中，我和许多扩展作者都建立了联系。例如，我手把手帮助 ParadeDB 的老板与作者 解决了 RPM / DEB 包打包与分发的问题。我说动了 duckdb_fdw 的作者使用一个单独的 libduckdb，并发布了 v1.0.0 ，我给一些PG扩展的作者发邮件/Issue，国产机器学习框架 PG4ML 的作者也找到了我希望能够通过这个渠道进行分发。

再比如说，最近 PG 生态 OLAP 缝合 DuckDB 的竞赛如火如荼，但不管是ParadeDB 的 pg_analytics，国内个人开发者李红艳编写的 duckdb_fdw，CrunchyData 的 pg_parquet，MooncakeLab 的 pg_mooncake， Hydra 和 DuckDB 原厂 MotherDuck 亲自下场搞的 pg_duckdb ，都被我在第一时间编译打包收录整合其中，做到了 —— 你卷你的，反正我全都要。

言归正传，我希望这个仓库能设立起 PostgreSQL 扩展安装分发的标准，解决让人头大的分发难题。目前最让我感到高兴的进展是，流行的开源 PostgreSQL高可用集群搭建项目 postgresql_cluster 的作者 Vitaliy Kukharik 已经将这个仓库作为默认启用的仓库来安装 PostgreSQL 扩展。

postgresql_cluster 采用 Pigsty 扩展仓库

目前这个仓库 (repo.pigsty.io) 托管在 Cloudflare 上，所以没有什么流量成本。国内有一个镜像站点 repo.pigsty.cc，方便墙内用户使用，每个有小几百块流量费，不是什么大问题。两个仓库加起来，过去一个月的下载流量大概 200GB ，考虑到扩展平均几十KB到几MB的大小，总下载量小几十万是有了。

因为赛博菩萨 Cloudflare不收流量费，所以总的来说，我觉得做一个永久免费的声明与承诺并不困难，所以 So be it。我承诺这个仓库将持续维护并永久免费。如果有国内开源软件站点的朋友愿意赞助或提供镜像服务，欢迎联系我。

我相信我的工作可以帮助到全球PG用户，并对 PostgreSQL 生态的繁荣贡献一份力量。我也希望我的工作可以帮到您，Enjoy PostgreSQL！

归档说明（2026-08-30）： 本文原载 vonng.com。文中的软件包数量、截图与上下文以原始发表日期为准；当前行为请以 PIG 文档和实时扩展目录为准。

2 - 设计注记

关于 PIG 关键决策、取舍与实现边界的设计注记。

设计注记解释 PIG 为什么采用今天的行为。每篇注记都会标明决策日期、实现与发布边界、 被否决的替代方案，以及对应的当前用户文档。

这些文章提供历史与架构背景。当前命令语法和行为以 PIG 文档 为准， 交付时间线以发布注记为准。

2.1 - 从面向人类到 Agent-Native：PIG 的 CLI 契约

为什么 PIG 将人类文本、结构化结果、执行计划与环境上下文分开，而不是把 JSON 当成最后附加的格式选项。

决策日期： 2026-02-12
状态： 在 pig v1.1.0 中实现，之后继续通过命令层重构收敛。
当前参考： pig 命令总览
范围： PIG 自己拥有的命令及其机器消费契约；不透明的透传命令保留原生接口。

决策

PIG 应当既适合人在终端中使用，也适合自动化 Agent 调用，而且不要求任何一方解析另一方的展示格式。 面向人的文本保持简洁、便于操作；真正拥有稳定结果的命令提供明确的 JSON/YAML 结果、状态码与执行计划。 仅仅转发外部工具的命令则保留原生输出流、提示与退出码，不能套上一层看似统一、实则失真的结果信封。

因此，Agent-Native 的含义是明确能力边界，而不是“给每条命令都加上 JSON”。

背景

PIG 最初是一套便捷的软件包管理 CLI。随着它扩展到 PostgreSQL、Patroni、pgBackRest、 Pigsty 与软件仓库操作，纯面向人的接口出现了几个问题：

  • 自动化只能抓取带颜色的自然语言文本；
  • 外层进程退出为零时，内层操作仍可能已经失败；
  • 破坏性工作流在执行前无法被审阅；
  • Agent 需要连续调用许多发现命令才能理解当前主机；
  • 包装器容易把子进程输出与结构化结果混在一起。

v1.1.0 引入了全局输出选择、稳定结果对象、执行计划与 pig context 快照。 后续重构又把这些承诺收窄到 PIG 真正能够可靠拥有的命令上。

考虑过的方案

以下三种看似简单的方案被否决：

  1. 解析人类文本。 文案、翻译、颜色与上游工具变化都会让它失效。
  2. 把所有子进程输出捕获进 JSON。 这会破坏交互程序、流式输出、终端控制与原生退出语义。
  3. 设计一个万能结果模式。 软件包事务、恢复计划、指标和环境快照拥有不同的稳定语义，强行拍平只会丢失信息。

契约

长期有效的契约是：

  • 文本是面向人的默认接口；
  • 只有在 PIG 拥有稳定结果时，命令才声明支持结构化输出；
  • 结构化 stdout 只包含一个可解析结果，诊断与被包装工具的输出进入 stderr；
  • 计划描述动作、范围、风险和预期效果，但不执行动作；
  • PIG 自己拥有的破坏性操作在缺少确认时默认失败；
  • 状态码区分用法、确认、环境、依赖与执行失败；
  • pig context 提供有边界的环境快照，不要求调用方自行拼接；
  • 透传与交互命令保持上游契约。

影响

这种分离让脚本更可靠，也让 Agent 能够依据风险与输出能力选择命令。与此同时，每个结构化字段都会成为兼容表面， stdout 纯净性需要测试，包装器也不能承诺比被委托工具更高的稳定性。

PIG 有意允许不同命令采用不同接口风格。统一很有价值，但忠实表达语义比外观一致更重要。

验证与演进

最初框架随 v1.1.0 发布。 命令层整合提交 fb93602 随后删除重复包装器， 统一计划和输出胶水。Patroni 后来改为透明透传，正好说明当上游接口已经权威时，PIG 应减少自己拥有的结构。

当前测试覆盖结构化 stdout 隔离、结果渲染、计划、确认门与环境上下文采集。

当前状态

这项原则仍然有效：应使用具体命令明确声明支持的结构化模式，不能推断全局 -o 能安全转换所有外部或交互输出流。 当前命令面与示例维护在 pig 参考文档中。

2.2 - 先编译和校验，再提交：原生 sty conf 流水线

为什么 pig sty conf 把 Inventory 生成视为带路径安全、结构化变更、秘密纪律和原子输出的编译流水线。

决策日期： 2026-02-18；生产契约于 2026-08-14 定稿。
状态： 已实现并随 pig v1.8.0 发布。
当前参考： pig sty conf
范围： 从受信 Pigsty 模板生成一份经过校验的静态 Inventory，不是任意 YAML 转换器。

决策

pig sty conf 应当像一台小型编译器：解析一个安全模板，读取结构，应用一组有边界的结构化变更， 校验完整候选文件，并且只在所有必要阶段成功后原子提交输出。

命令不调用旧 configure 脚本，也不回退到原始 Shell 执行。 结构化结果报告选中的输入、实际选择、变更类型与告警，但不返回生成的秘密值。

背景

模板配置看似简单，直到路径、符号链接、多 IP 占位符、固定版本模板、镜像、代理环境、生成凭据与部分有效 YAML 同时出现。文本替换流水线可能级联替换 IP，修改无关域名，泄露秘密，或在最终校验失败后截断目标文件。

输出 Inventory 可能包含管理员凭据，因此文件处理与结果渲染都属于安全边界。

考虑过的方案

  • 调用现有 Shell configure 脚本。 解析、校验和结果语义仍在 PIG 控制之外。
  • 使用全局搜索替换。 IP 与域名需要精确占位符边界和同时映射。
  • 先写文件再校验。 失败候选可能替换仍然可用的 Inventory。
  • 接受任意绝对模板路径。 命令应编译已知 Pigsty mode，而不是成为特权文件复制器。
  • 为了方便返回生成密码。 结构化日志与 Agent 轨迹不是秘密交付通道。

契约

  • 模板通过安全相对名称解析到 Pigsty 配置树下；
  • 拒绝绝对路径、目录穿越、路径逃逸，以及直接路径、符号链接父目录或硬链接造成的源/输出别名；
  • 解析与 IP 冲突检查先于外部预检；
  • 占位 IP 同时映射，无关地址保持不变；
  • 域名替换只匹配精确模板 token；
  • profile、region、proxy、locale 与 PostgreSQL 版本变更都是有边界的结构化操作；
  • 每个已知凭据标识符只生成一个随机值，结果只暴露标识符；
  • 完整候选接受原生校验，并可选执行有超时边界的 Ansible 解析；
  • 任一失败都不改变目标文件；
  • 成功结果以 0600 权限原子写入。

影响

该命令只支持定义明确的一组模板和变更，不提供任意编辑能力。 这个限制是刻意的：已有 Inventory 属于无损 pig inventory 工作流，sty conf 则拥有从已知模板进行可复现编译的职责。

固定版本模板保留自己的实际版本；通用版本请求无法应用时产生告警，而不是报告请求版本却生成另一个版本。

验证与演进

原生 configure 方向最早记录于 2026-02-18，生产实现收敛于 74e084e， 最终契约同步提交为 adc4260。 测试覆盖目录穿越与别名、同时 IP 映射、域名边界、交互与关闭输入选择、版本处理、代理和区域变更、 秘密生成与脱敏、预检顺序、校验失败、权限与原子写入。

当前状态

使用 pig sty conf 从 Pigsty 模板生成新 Inventory，使用 pig inventory 查看或编辑已有声明。 当前参数、mode 与预检行为维护在 pig sty 参考文档中。

2.3 - 七成正确的调优器：界定 pig pg tune 的边界

为什么 pig pg tune 只生成确定性的硬件相关核心参数，而不把自己包装成完整的生产 PostgreSQL 调优方案。

决策日期： 2026-03-21
状态： 2026-03-23 实现，并随 pig v1.3.2 发布。
当前参考： pig pg tune
范围： 为单个本地 PostgreSQL 实例生成确定性的首轮配置，不是完整的生产设计服务。

决策

pig pg tune 只回答一个有边界的问题：给定 CPU 数量、内存、磁盘容量与工作负载画像， 这台机器的 PostgreSQL 核心参数应该采用怎样的合理起点？

它追求的是“七成正确”的初始值。命令尽可能探测硬件，允许显式覆盖，计算少量高影响参数， 并可以写入 postgresql.auto.conf。它不声称能够设计复制、持久性、安全、日志、扩展、连接池或工作负载相关 SQL 行为。

背景

在还没有工作负载遥测时，运维人员仍然经常需要一套可用基线。复制静态配置会忽略机器规模； 完整调优服务则需要查询轨迹、存储特征、可用性目标和持续反馈。

PIG 已经能够定位 PostgreSQL 安装并以数据库操作系统用户运行命令。 一个小而确定的调优器符合这个边界，而且结果可检查、可复现。

考虑过的方案

  • 发布一份万能配置。 内存与并行参数必须随主机规模变化，因此否决。
  • 构建自适应自动调优器。 它需要遥测、实验、工作负载分类与回滚机制，远超本地 CLI 的边界。
  • 重写主配置文件。 这会把生成值混入发行版或运维人员维护的配置中，也不利于回滚。
  • 调节所有 PostgreSQL 参数。 很多参数表达业务、持久性、安全和拓扑决策，硬件无法替人决定。

契约

调优器遵循以下规则：

  • 硬件探测过程可观察，每个探测值都可以覆盖；
  • profile 改变公开公式，不依赖隐藏的外部状态；
  • 相同输入产生确定性结果；
  • 写文件之前可以预览，也可以获得结构化结果；
  • 生成设置仅进入自动配置表面；
  • 编辑器保留无关的现有设置与注释；
  • 数值受 PostgreSQL 与机器资源边界约束；
  • 输出明确声明 SSD 假设与建议局限。

影响

该命令适合开发机、新安装和初步容量规划，但不能证明生产数据库已经完成调优。 复制延迟、检查点行为、查询并发、缓存命中率、存储延迟、扩展与故障目标仍需要测量和人工判断。

保持小范围也让计算公式可以被充分测试，并让用户无需远程服务即可重现结果。

验证与演进

实现提交为 60eecfe， 并标记为 v1.3.2。单元测试覆盖画像计算、硬件覆盖、结果渲染和安全的 postgresql.auto.conf 编辑。 之后的静态分析清理没有改变产品边界。

当前状态

pig pg tune 仍是一项首轮工具。应用前应审阅结果；当拓扑、高可用、可观测性或安全需要协同设计时， 应使用 Pigsty 或基于真实工作负载的调优流程。当前参数与示例维护在 pig pg 参考文档中。

2.4 - 为什么 PIG 保持扁平的 Cobra 命令层

一个顶层命令对应 cmd 中一个文件，具体行为进入 cli 与 internal 包的源码布局决策。

决策日期： 2026-06-30
状态： 当前仍在执行的仓库架构。
当前参考： pig 命令总览与源码仓库
范围： Go 源码归属与命令注册方式，而不是公开命令分类本身。

决策

cmd 包保持扁平。一个顶层命令对应一个顶层 Go 文件：pg.go、pb.go、pt.go、 pe.go、sty.go、do.go、repo.go 等。即使命令树很复杂，也继续留在这个入口文件中， 除非另有明确的布局决策。

文件可以很长，但只应包含 Cobra 关注点：名称、别名、注解、参数、实参校验、帮助、注册和选项映射。 具体工作放入 cli/*、internal/* 或其它实现包。

背景

早期命令增长产生了很多以子命令命名的小文件，也出现了多套确认、结构化输出、计划渲染和旧接口包装实现。 一些简单问题因此难以回答：顶层命令在哪里注册，某个别名由谁拥有，两段辅助代码是否在执行同一策略？

PIG 的命令族很大，但它们的公开语法是一个整体。把语法集中在一个位置更容易审查冲突， 实现包则继续按职责拆分。

考虑过的方案

  • 在 cmd 下为每个命令建目录。 普通命令不采用，因为一个公开语法会散落在多个包中，也容易把业务逻辑放到 Cobra 附近。
  • 每个子命令一个文件。 注册、别名和继承参数将难以作为整体审阅。
  • 把所有逻辑都放进 cmd。 操作逻辑依赖 Cobra 状态后，测试与复用都会变差。
  • 抽象每一行重复代码。 猜测式框架会遮蔽命令语法；只有已经稳定、跨命令复用的胶水才应共享。

契约

  • cmd/root.go 负责根命令、全局参数和顶层注册；
  • cmd/utils.go 负责共享的命令层辅助函数；
  • 每个普通顶层命令有一个对应的顶层源码文件，可以配一个同名测试文件；
  • Cobra 层校验语法和映射选项，但不执行具体操作；
  • 确认、注解、结构化输出与计划辅助逻辑只有一套实现；
  • 实现包接收普通选项并返回类型化结果或错误，不依赖 Cobra 全局状态。

影响

部分命令文件会有意保持较长。这个取舍是可接受的，因为公开接口可以作为整体审阅，而实现仍然在下层拆分。 规则也减少了别名或参数移动时的文件震荡，为 Agent 提供确定的阅读起点。

边界是架构性的，不是外观性的：把业务逻辑藏在闭包里的短 cmd 文件仍然违规； 只包含声明式命令胶水的长文件则没有问题。

验证与演进

约定记录在 9eb70db， 随后由大型命令面整合提交 fb93602 落实。 Guard 测试检查别名冲突与命令注册，实现层行为则由各包测试验证。

当前状态

这仍是新工作的仓库规则。公开命令文档统一放在本站；源码布局约束继续靠近代码保留， 确保贡献者与编码 Agent 在修改前就能看到。

2.5 - 危险操作只有一套语法：PIG 运维 CLI 安全契约

PIG 如何分离底层原语与编排器、显式表达破坏性意图，并防止别名或结构化输出改变操作含义。

决策日期： 2026-07-02
状态： pg、pb、pt、pitr 已于 v1.5.0 交付；2026-08-29 的 do 与 build proxy 修订已随 v1.8.1 发布。
当前参考： pig pg、pig pb、pig pitr、pig do 与 pig build
范围： PIG 自己拥有的运维命令；透明上游命令继续采用上游的确认与退出行为。

决策

操作便利性不能模糊操作含义。PIG 明确区分底层原语与多阶段编排器，显式表达破坏性意图， 谨慎分配别名，并要求计划与结构化结果描述的动作必须和文本模式真正执行的动作一致。

最重要的例子是恢复：pig pb restore 是 pgBackRest 原语，pig pitr 则协调 Patroni、 PostgreSQL 停止、恢复、重新启动与恢复后指引。任何别名都不能让这两条路径看起来可以互换。

背景

第一代便利别名积累了不一致的位置参数、确认参数、输出处理与服务语义。 restart、restore、promote、failover 等相似词在不同层次代表完全不同的操作。 跨越层次的短别名可能把看似无害的调用变成缺少编排保护的破坏性原语。

自动化还暴露出假成功问题：包装器输出、子进程输出和结果渲染可能使用不同的成功定义。

考虑过的方案

  • 尽可能增加短别名。 冲突和跨层同义词带来的风险高于节省几个字符的价值。
  • 给所有看起来危险的单词都加确认。 对透传命令不成立，因为提示与语义必须由上游工具拥有。
  • 让编排器成为原语的便利别名。 恢复编排拥有额外的停止、验证与重启不变量，不能合并。
  • 启动内层命令后立即返回成功。 结果必须反映 PIG 拥有的完整工作流。

契约

  • 同级命令名称与别名唯一；
  • 子命令别名不能遮蔽另一个顶层命令；
  • PIG 自己拥有的破坏性操作要求显式确认，并在有意义时提供无副作用计划；
  • 命令层在产生副作用前拒绝错误或多余的位置参数；
  • 命令专用名称遵循下游 Pigsty 契约；下游 Playbook 没有显式语法时，只采用有文档说明的最窄安全边界；
  • 结构化输出与文本模式共享同一个结果和成功定义；
  • 含凭据的值不进入诊断输出；就绪或连通性失败必须保持命令失败，不能只记警告后返回成功；
  • 底层 restore 不声称管理 Patroni 或 HA 路由；
  • PITR 编排器按需停止管理器，证明 PostgreSQL 已停止，执行恢复，可选启动 PostgreSQL， 并有意保持 Patroni 停止，等待运维人员验证；
  • 额外原生参数只通过明确记录的边界传递。

影响

部分历史缩写被移除，一些脚本需要采用 cluster-first 或显式目标语法。 作为回报，命令名称保留了层次边界，计划对应真实动作，恢复自动化也不会悄悄用原语替换编排器。

这套契约不会消除操作风险。它的作用是让风险可见，并阻止便利层制造歧义。

验证与演进

规范命令契约在 c62c0f5 中进入仓库。 后续提交继续统一别名、早期校验、恢复目标、服务语义与角色检测。 Guard 测试遍历 Cobra 树，拒绝同级与跨层别名冲突；恢复测试覆盖计划、确认、停止升级、旁路恢复、 重启行为与结构化失败结果。

Patroni 后来改成透明透传，这仍遵循同一原则：PIG 只为自己拥有的工作流提供安全保证。

同一契约在 3e1603b 中扩展到 pig do 的名称与集群校验，并在 a880485 中封闭 Ansible 内置目标。软件包驱动、凭据安全且如实报告失败的 build proxy 设置进入 220ef9c， 随后由 74cb128 补齐结构化参数遮盖与机器注解，并在 de7ffd0 中把可选参数同步到机器语法。这些修改均在 Ubuntu 24.04 与 Rocky Linux 9 ARM64 Farrow 客体中完成实机测试，并在 v1.8.1 CI 通过后，从源码提交 e3d1eb4 正式发布。

当前状态

明确需要 pgBackRest 原语时使用 pig pb restore；需要受控恢复流程时使用 pig pitr。 当前语法、警告与平台要求维护在命令参考页中，而不是冻结在这篇历史记录里。

2.6 - 编辑声明，保留文档：无损 Pigsty Inventory

为什么 pig inventory 将 YAML 语义与源字节分离，让局部编辑能够保留注释、顺序、锚点与格式。

决策日期： 2026-07-18
状态： 已实现并随 pig v1.6.0 发布。
当前参考： pig inventory
范围： 静态 Pigsty Inventory 的查看、局部编辑、校验、比较与安全写入。

决策

PIG 同时把 pigsty.yml 视为语义声明和人工维护的源文档。语义解析器负责判断 Inventory 的含义， 原始字节则决定它的书写方式。局部编辑只替换有边界的源范围，并在原子写入前重新解析完整候选文件。

这样可以避免 YAML 工具常见的失败模式：逻辑上正确的一次编辑，却悄悄重写整份文件的注释、键顺序、 引号、锚点、块标量或换行风格。

背景

Pigsty Inventory 是长期存在的运维资产，包含拓扑、调优、凭据、注释、示例、锚点和本地有意义的顺序。 普通的“解析—修改—序列化”流程可能生成有效但无法审阅的差异，并改变运维人员没有选择的结构。

另一方面，没有语义校验的纯文本编辑又可能把无效或自相矛盾的配置写入磁盘。 设计必须同时获得源文件保真与整文正确性。

考虑过的方案

  • 使用一个 YAML 序列化器完整往返。 在真实 Pigsty 语料上，没有选定的序列化器能够逐字节保留完整源契约。
  • 用正则表达式处理 YAML。 引号、注释、别名、块标量和嵌套集合让纯文本语义判断不安全。
  • 只编辑规范化生成副本。 活跃 Inventory 属于运维人员，仍会与生成表示发生漂移。
  • 允许替换所有节点类型。 锚点、别名、标签与块标量需要比普通映射和标量更严格的处理。

契约

  • 拒绝重复键与多文档 YAML；
  • selector 只定位一个无歧义的声明片段；
  • 语义解码与源范围发现是两项独立职责；
  • 编辑从精确源 revision 开始，文件被并发修改时失败；
  • 编辑片段只进行插入上下文所必需的规范化；
  • 提交前重新解析并校验完整候选文件；
  • 写入使用同目录临时文件、sync、rename 与目录 sync；
  • 拒绝符号链接与不安全路径变化；
  • 成功编辑后将含密 Inventory 权限收紧为 0600；
  • 除非命令明确属于原始文本表面，诊断、diff、计划与结构化结果都不输出声明值。

影响

编辑器比普通 YAML marshal 更复杂；当无法证明源文件保真时，一些语法有效的片段也会被有意拒绝。 换来的结果是可审阅差异：未选择部分逐字节稳定，无效 YAML 无法落盘，并发修改不会被静默覆盖。

show 仍然明确属于可能含密的接口。坦率声明这个例外，比假设一个不完整的脱敏器能识别未来所有凭据键更安全。

验证与演进

根级 Inventory 契约与既有 CMDB 边界建立于 ba6e678，实现落地于 ea43858。测试覆盖真实 Pigsty 配置语料、逐字节往返、 局部替换、受保护 YAML 形式、并发变更拒绝、原子写失败、selector、校验和无敏感值诊断。

后续重构移除了旧选项并分离校验阶段，但没有改变源文件保真模型。

当前状态

静态 Inventory 仍是主要声明表面。selector、校验 profile、结构化输出与明确标记为实验性的 CMDB 桥接， 均以当前 pig inventory 参考文档为准。

2.7 - 复用 Pigsty 已经拥有的 CMDB

为什么 PIG 撤销全新的 revision store 设计，转而成为 Pigsty 既有 PostgreSQL CMDB 的轻量受控适配器。

决策日期： 2026-07-18
状态： 全新 revision store 已被取代；复用既有 CMDB 的薄适配器已经实现，但仍为实验功能。
当前参考： pig inventory cmdb
范围： 与 Pigsty 既有 CMDB 交换声明，而不是再设计一个配置数据库。

决策

PIG 必须复用 Pigsty 已经提供的 CMDB。它的职责是有边界的适配：校验静态 Inventory， 将声明装载到既有表中，导出既有投影，检查一致性，并安全切换 Ansible 的静态与动态数据源。

PIG 不拥有第二套 schema、迁移历史、快照账本、CAS revision store、三方合并引擎或数据库回滚系统。

背景

早期设计把 CMDB 支持当成一个全新后端，提出独立 schema、不可变快照、revision token、合并与回滚、 备份 bundle 和数据源切换记录。方案内部逻辑完整，但出发点错误：Pigsty 已经拥有 pigsty 与 pglog schema、装载脚本、动态 Inventory 投影和数据源切换行为。

再建一套控制面会复制事实、制造同步问题，并让 PIG 对另一个项目拥有的数据模型负责。

考虑过的方案

  • 把新 revision store 保留为高级模式。 即使可选，两套权威仍然是两套权威。
  • 在新旧 schema 之间双向镜像。 冲突处理与迁移会成为永久产品责任。
  • 只用 Shell 包装既有脚本。 PIG 仍需要有边界的超时、安全连接处理、结构化计划与原子数据源切换。
  • 完全删除 CMDB 支持。 一个小型原生适配器仍能提供有价值的校验与自动化，而不重新定义 schema。

契约

  • Pigsty 既有 schema 与投影是数据模型权威；
  • PIG 通过显式数据库目标、环境配置或 service=meta 连接；
  • 凭据、DSN、SQL 正文与声明值不得进入计划或诊断；
  • check 只读；
  • init 应用既有基线，但不声称会备份现有数据库；
  • load 在事务内替换声明行，并要求显式确认；
  • dump 在没有 force 时拒绝意外覆盖；
  • enable 与 disable 只修改能够识别的 Ansible Inventory source 形式，并原子写入；
  • 无法识别的可执行 Inventory source 一律拒绝，不擅自重写；
  • 整个命令族继续明确标记为实验功能。

影响

纠偏删除了大量已经写出的 revision-store 代码。这是有意恢复范围，不是功能损失： 被删除的功能描述的是一个 PIG 本就不应该拥有的产品。

保留下来的适配器更小、更容易审计，也与现有 Pigsty 运维方式兼容。 它同时继承既有系统的限制：init 需要运维人员自行备份，装载声明属于替换操作，而不是协同版本控制。

验证与演进

纠正后的边界记录在 ba6e678。 废弃实现由 e0f73ed 删除， 其中包括平行 schema、snapshot、merge、revision 与 rollback 机制。 保留路径的测试覆盖 PostgreSQL 兼容性、连接信息脱敏、事务失败、摘要绑定确认、dump 安全和原子数据源切换。

当前状态

既有 CMDB 适配器已随 v1.6.0 发布，但仍为实验功能。 在真实 CMDB 上执行初始化或替换前应自行备份，并使用当前 pig inventory 文档， 不要再参考已经废弃的早期设计。

2.8 - 用有边界的 Grafana 客户端替代仪表盘脚本

为什么 pig sty grafana 只拥有仪表盘生命周期与偏好设置的一小段 HTTP 契约，而不成为通用 Grafana 管理客户端。

决策日期： 2026-07-18
状态： v1.6.0 实现；Grafana dashboard schema v2 支持随后在 v1.6.2 交付。
当前参考： pig sty grafana
范围： Pigsty 拥有的仪表盘目录、仪表盘与界面偏好；不是通用 Grafana provisioning。

决策

PIG 应通过有边界的原生 HTTP 客户端管理 Pigsty 随附的 Grafana 资产。 它可以检查就绪状态、列出托管资产、装载或初始化仪表盘、导出仪表盘、只清理自己拥有的资产， 并调整受支持的语言与样式偏好。

该命令不能扩张成通用 Grafana 管理 API。Datasource、organization、user、任意目录、plugin 和无关仪表盘都不属于它的所有权。

背景

旧仪表盘工作流依赖脚本和本地文件布局，几乎无法提供结构化证据来说明连接了哪个端点、 哪些资产属于自己，或为什么只完成了一部分。另一方面，如果没有严格所有权模型就开放完整 Grafana API， 可能删除用户内容，也可能在参数和诊断中泄露凭据。

只有在网络、认证、所有权与结果边界都明确时，原生客户端才值得存在。

考虑过的方案

  • 继续把 Shell 脚本作为公开接口。 超时、重定向、响应大小、脱敏和结构化结果仍会不一致。
  • 开放任意 Grafana API 调用。 这会让 PIG 变成第二个没有稳定边界的 Grafana CLI。
  • 仅凭目录名称删除。 名称不足以证明资产所有权。
  • 内置 demo 密码。 默认凭据会变成长寿命秘密，并鼓励不安全自动化。

契约

  • 每个请求都有连接与响应大小边界；
  • 拒绝不安全重定向与过大响应；
  • 认证操作前先检查公开 health；
  • 凭据来自显式安全输入、环境或 Inventory，不内置默认密码；
  • 命令行密码仅作为应急路径，并明确提示 argv 与 Shell 历史风险；
  • 错误与结构化结果不包含凭据或响应正文；
  • load 与 init 只处理 Pigsty 已知的仪表盘 bundle；
  • clean 只删除能够证明由 PIG/Pigsty 拥有的资产；
  • language 与 style 接受固定词表，并把 auto 映射到 Grafana 的 system 偏好；
  • schema v1 与 schema v2 仪表盘表示在客户端边界完成规范化。

影响

原生客户端提供了更好的计划、错误分类与自动化结果，但必须维护自己拥有的那一小段 Grafana API。 支持新仪表盘 schema 是合理演进，不代表会支持无关 Grafana 资源。

运维人员可以继续使用其它 Grafana 客户端完成通用管理，PIG 不会声称拥有这些资源。

验证与演进

原生仪表盘工作流落地于 3060485。 测试覆盖 health、认证、超时、重定向、大小限制、所有权检查、偏好请求、脱敏、部分失败与 load/dump。 Dashboard schema v2 支持随后在 67f6e3b 中加入， 并随 v1.6.2 发布。

当前状态

pig sty grafana 是 PIG 支持的 Pigsty 仪表盘生命周期入口。 命令和凭据规则以当前 pig sty 参考文档为准；边界之外的资源使用 Grafana 原生工具。

2.9 - 让 Patronictl 自己说话

为什么 pig pt 不再镜像 Patronictl 命令树，而是只保留少量 PIG 本地辅助功能的透明启动器。

决策日期： 2026-07-21
状态： 已实现并随 pig v1.6.0 发布。
当前参考： pig pt
范围： Patronictl 集群命令，以及 PIG 拥有的配置选择、参数设置、服务、状态和日志辅助功能。

决策

pig pt 是已安装 patronictl 的透明启动器。PIG 选择配置并分派少量本地辅助命令； 其它命令 token 及其后的所有参数原样传递，保留原生提示、终端行为、输出格式与退出码。

PIG 不再维护一份持续变化的 Patronictl 命令树副本。

背景

镜像 Patronictl 要求 PIG 复制命令、参数、位置语法、确认方式、格式和版本相关行为。 上游接口持续演进，PIG 的副本必然漂移。同一个操作通过 patronictl 与 PIG 调用时可能出现不同语义。

包装器在 Pigsty 环境中仍有价值：以数据库操作系统用户选择正确配置，提供本地服务和日志工作流， 并把一小段参数设置便利语法翻译为一次原生 edit-config 调用。

考虑过的方案

  • 继续镜像全部上游命令。 必然滞后，并重复 Patronictl 已经拥有的校验。
  • 只允许经过测试的命令白名单。 新上游命令仍要等待 PIG 发布后才能使用。
  • 把原生输出捕获成 PIG JSON。 会破坏交互编辑、流式输出、提示、终端保真和上游 schema。
  • 完全删除 pig pt。 确定性配置选择与本地 Pigsty 辅助能力仍然有价值。

契约

  • 第一个非选项命令 token 决定本地分派还是透传；
  • set、本地 service shortcut、status 与 log 由 PIG 拥有；
  • 其它命令和剩余 token 原样转发；
  • pig pt -- COMMAND ... 显式绕过本地名称冲突；
  • 包装器参数必须出现在原生命令 token 之前；
  • 原生 help 可以在没有本地 Patroni 配置时运行；
  • Patronictl 拥有交互提示、原生 --format 和退出码；
  • 会产生原生参数歧义的 PIG 全局结构化输出被明确拒绝；
  • 配置按确定顺序解析，进程以数据库系统用户运行。

影响

自动化需要采用 Patronictl 的 cluster-first 位置语法与原生输出参数。 部分 PIG 专有别名和结果 schema 被移除。换来的好处是：新 Patronictl 功能无需等待 PIG 发布， 行为也不再依赖滞后的包装器实现。

本地 set 辅助功能有意保持很小：它只分类 Patroni 标量键与 PostgreSQL 参数，然后执行一次原生 edit-config。

验证与演进

重写提交为 6cbc23b。 测试覆盖 token 边界、argv 原样保留、配置优先级、数据库用户执行、原生退出码、无配置 help、 输出模式拒绝、-- 逃逸与本地辅助命令冲突。最终 help 路径修正在 v1.6.0 前完成。

当前状态

透传命令语法以 Patronictl 自身文档为准；PIG 的配置选择与本地辅助功能以 pig pt 为准。 不能用 PIG -o json 代替 Patronictl 原生 --format json。

2.10 - PIG 2.0 产品方向：一份提案，而不是发布契约

PIG 2.0 的候选边界：稳定的 Pigsty 初始化前门、可验证 Catalog 客户端，以及保持显式部署的薄编排层。

决策日期： 2026-08-13
状态： 等待 owner 审议的提案；尚未实现，也不是 PIG 2.0 发布承诺。
当前参考： PIG 文档与当前 v1.8.1 发布
范围： 未来 PIG 2.0 / Pigsty 5.0 的候选产品边界与验证门槛。

决策

提案方向是让 PIG 成为从空白控制节点到经过校验、可以部署的 Pigsty Inventory 的稳定初始化前门。 PIG 拥有 Catalog 选择、解析、计划、有边界的执行编排、结构化结果与脱敏 receipt； 软件包事务、配置应用与基础设施状态继续委托给 DNF/APT、Ansible 和未来的 provider 工具。

提案有意保留 PIG 的独立价值：repo、ext、install 在没有 Pigsty 项目时也必须可用。 它也保留显式部署同意：未来的 pig sty setup 可以下载、引导与生成配置，但不能在用户没有单独调用部署时 自动执行多节点 deploy。

背景

到 v1.8.0，PIG 已经能够下载 release、原生引导控制节点、编译 Inventory、管理仓库与扩展， 并执行部分运维操作。产品仍存在几个接缝：

  • repository、package alias、extension、route 与 Pigsty 元数据可以独立变化；
  • 项目没有明确 Catalog 身份，无法防止后续解析受全局更新影响；
  • 路由选择与仓库安全还不是一套可见产品契约；
  • 初始化路径上的执行结果还没有形成持久、脱敏的 receipt；
  • PIG、Pigsty、Catalog schema、操作系统与 Ansible 的兼容性需要统一发布矩阵，而不是分散假设。

提案把这些接缝定义为 2.0 问题，而不是把大版本当作随意改名或重造既有工具的许可。

考虑过的方案

  • 把 PIG 变成单体配置与状态引擎。 Inventory、Catalog authoring、包管理器、Ansible 与 provider 已经分别拥有不同事实，因此否决。
  • 让 Pigsty 运行时依赖 PIG 或 pgext checkout。 Pigsty release 必须依靠版本化生成产物独立工作。
  • 让 setup 自动部署。 生成并校验配置与修改远程节点属于不同的同意边界。
  • 重新实现 DNF/APT failover 或 Ansible 执行。 PIG 应选择输入并解释结果，而不是成为另一个包管理器或配置引擎。
  • 让 Vagrant/Terraform 统一阻塞 2.0。 Lab provider 状态语义不同，也不决定核心初始化路径。
  • 立即发明万能 sty plan。 至少两个 PIG 自有工作流证明同一计划 schema 可复用后再讨论。

契约

如果获得批准，产品方向将遵循以下边界：

  • 每类事实只有一个权威：Inventory 负责集群声明，Catalog authoring source 负责产品元数据， project lock 负责选中 snapshot 身份，receipt 负责观测结果，provider 负责实时状态；
  • PIG 拥有 Catalog schema、校验、客户端、resolver 与选择逻辑，但不拥有所有 authoring 数据库；
  • sty setup 组合既有 init、boot、configure use case，不复制实现；
  • setup 在 Inventory 校验后停止，deploy 继续显式执行；
  • 独立命令跟踪兼容 Catalog channel，Pigsty 项目在成功 setup 或 conf 提交后 pin 当时的 snapshot；
  • 普通命令不隐式改写已有 project lock；
  • 路由选择来自显式配置或有边界的首次判断，不构建持续 GeoIP、云 IMDS 或后台测速服务；
  • 软件包下载重试与 endpoint failover 由 DNF/APT 负责；
  • 执行 artifact 版本化并脱敏，raw 上游模式保持原生输出流与退出语义；
  • doctor 保持诊断角色，不获得默认修复权限；
  • 未来 lab 支持只做薄适配，PIG 不拥有 Terraform state。

影响

提案会让首次使用路径更清晰，也让元数据选择可以审计。与此同时，它会新增 snapshot identity、 project lock、迁移规则、trust policy、receipt 和兼容矩阵等持久契约。 这些契约会显著增加测试与发布负担，不能作为松散功能各自交付。

一些有吸引力的工作被明确设为可选或延期。Ansible event bridge 只有在脱敏与兼容实验通过后才是目标； doctor/support bundle 与 lab adapter 属于 GA 之后；EL7 支持档位仍是 owner 决策，不是隐含兼容承诺。

验证与演进

提案成为发布契约前需要以下证据：

  • 覆盖声明 Linux 目标的原生 onboarding VM 矩阵；
  • Catalog 签名、过期、回滚、混装与离线场景的对抗测试；
  • 证明 Pig、Pigsty、pgext 生成消费者不会漂移的语义 diff；
  • no_log 与秘密零泄露的 Ansible callback 实验；
  • 全球、中国、代理和受限网络环境的路由选择测试；
  • 修改安全默认值前的仓库签名矩阵；
  • 1.x 到 2.0 的布局、lock 与混合版本迁移演练；
  • 与明确兼容矩阵绑定的 schema 和结构化输出 fixture。

当前实现基线是 v1.8.0。 该版本已经包含原生 boot 与 configure，但没有实现提案中的 Catalog v2、project pin、setup 命令、 event receipt 或 2.0 迁移契约。

当前状态

这是一份公开提案记录，不是发布公告。当前用户应继续遵循 v1.8.1 文档。 Catalog v2 安全方案、typed overlay、路径布局细节、EL7 支持档位、event bridge 可行性与最终 2.0 范围， 都需要明确决策和实验结果，之后才能作出实现或发布声明。

2.11 - Catalog v2 提案：不可变 typed snapshot，而不是更大的 CSV

一套候选的可验证 Catalog 模型：typed target、内容寻址 snapshot、显式激活、项目 pin 与离线导入。

决策日期： 2026-08-13
状态： 实现前提案；安全机制、overlay 范围、打包方式与路径 ADR 仍未决定。
当前参考： pig ext 与 pig repo描述 v1 Catalog 行为。
范围： PIG 2.0 产品元数据的候选发布与消费模型，不包含 Inventory 或实时系统状态。

决策

Catalog v2 应当是一份由多个 typed target 组成的不可变、可验证 snapshot。 Manifest 将平台、仓库、路由、package alias、扩展、兼容性、Pigsty release 与公钥元数据绑定到精确字节。 所有候选 target 一起校验，通过同一个 pointer 激活，避免新仓库 Catalog 与旧扩展矩阵被静默混装。

Snapshot digest 是最终身份。Package、system、user、portable 与 project scope 保存或选择的是同一份 已验证内容，而不是把无关 base snapshot 合并成一份人工 Catalog。

背景

v1 Catalog 很实用，但相关事实散布在 embedded CSV、repository YAML、Pigsty 变量、生成站点和 reload 路径中。 部分字段重复维护可推导信息，extension matrix 也把几个独立身份压缩到同一条记录。 独立更新后，很难证明 repository、package、extension 与 compatibility 数据来自同一次发布。

因此，Catalog v2 首先是发布与信任问题，而不仅是换一种序列化格式。

考虑过的方案

  • 制作更大的 extension.csv 或一个巨型 YAML。 不同 target 类型演进速度不同，也无法独立流式处理并整体激活。
  • 立即使用 SQLite、protobuf 或定制二进制矩阵。 当前数据量没有证明值得承担新的运行时与调试成本。
  • 按字段合并 system、user、project base snapshot。 结果没有单一 publisher、digest、兼容声明或签名。
  • 只把 active 或 project pin 内容放在 cache。 删除缓存不能破坏持久的用户或项目决定。
  • 允许 user file 遮蔽官方 trust root。 安全 policy 是约束，不是普通的后写覆盖偏好。
  • 后台静默更新并激活。 元数据变化可能改变包解析，必须是可观察操作。

契约

候选 snapshot 契约是：

  • Manifest 与小型 target 使用确定性 UTF-8 JSON，大型稀疏 target 使用 JSONL；
  • 直接校验原始 manifest bytes 与 target length/hash，避免 parse 后重新序列化产生歧义；
  • Manifest 包含 schema、单调安全版本、创建时间、过期时间、channel 和 PIG/Pigsty 兼容范围；
  • 始终提供 embedded rescue baseline；
  • package-owned baseline、durable snapshot store、可变状态 pointer 与可清理下载 cache 使用不同路径；
  • Linux 遵循 FHS/XDG，macOS 使用 Application Support 与 Caches，portable PIG_HOME 仍区分 config、data、state、cache 与 run；
  • project lock 记录 snapshot 身份和有序 overlay，已验证 snapshot 物化到持久 project support data；
  • 选择 digest 与寻找该 digest 的 bytes 是两个独立算法；
  • 低层 scope 只能收紧 system security policy，不能静默放宽；
  • 更新下载到私有 staging，校验每一层，sync 后移动到内容寻址 store，再原子替换 active pointer；
  • 失败时保留此前 active snapshot；
  • user/system active channel 更新不会移动 project pin；
  • 离线导出包含验证元数据和公开 trust material，绝不包含私钥；
  • 旧 ext reload 与 repo reload 可以在一个兼容周期内映射到整体 snapshot update， 但不能分别激活 target。

运行时 Catalog 明确不包含 Inventory、凭据、实时探测、已安装包状态、Ansible event、provider state、 危险操作确认和不属于产品决策的短期波动指标。

影响

Typed target 让所有权与校验更清晰，内容寻址让 rollback 与 airgap import 可审计。 Project materialization 避免部署依赖某个用户的全局 cache。独立 OS package 可以更新只读 baseline， 而不改变 active user selection。

代价是一套更大的发布协议：key rotation、expiry、rollback protection、GC、路径权限、迁移、 包管理器生命周期、overlay 冲突与跨仓 generator 都会成为兼容敏感工作。

Extension 模型也必须分离 SQL extension 身份、上游项目、distribution/build unit、版本化 release、 OS package offer、目标可用性和展示 policy。Aggregate platform support、required_by 等派生字段应由 generator 计算，而不是维护第二份事实。

验证与演进

实现前必须通过 ADR 在 go-tuf 与最小 signed manifest 之间作出选择。 两个候选必须通过同一组威胁测试：坏签名、过期元数据、回滚、target 替换、snapshot 混装、截断下载与离线验证。 如果都不能通过，Catalog v2 就不能作为 2.0 发布功能。

其它门槛覆盖 FHS/XDG/macOS/portable 路径、root 与非 root 权限、只读 home/project、符号链接替换、 磁盘写满与并发激活、package upgrade/remove 语义、删除全局 cache 后 project 仍能工作， 以及当前扩展和可用矩阵的无损迁移。

当前源码基线仍是 v1.8.0， 其 embedded 与可 reload 的 v1 Catalog 继续定义已发布行为。

当前状态

今天没有任何 Catalog v2 命令、manifest、trust root、store 布局、project lock 或迁移格式属于已发布 PIG 契约。 如果 typed overlay 的冲突与信任规则无法得到证明，应从 2.0 中删去；完整自定义签名 channel 比松散、未验证的 patch 更安全。当前安装与 Catalog 行为仍以 pig ext 和 pig repo为准。

2.12 - 把 Pigsty 控制节点引导设计成可恢复事务

为什么 pig sty boot 在提权前解析来源、分离硬失败与收尾告警，并在软件源准备失败时恢复仓库定义。

决策日期： 2026-08-14
状态： 已实现并随 pig v1.8.0 发布。
当前参考： pig sty boot
范围： 准备 Pigsty 控制节点及其软件来源，不包括部署数据库集群。

决策

pig sty boot 应当是一套原生、能够处理失败的控制节点引导工作流。 它在提权前解析显式来源，准备在线或离线仓库，只安装必要的控制节点软件包，证明 Ansible 真正可用， 并执行有边界的收尾检查。

仓库替换具有事务语义：软件包准备失败时恢复原有仓库定义。 可选便利功能可以告警，但无效的显式输入、软件包失败和最终不可用的 Ansible 环境属于硬失败。

背景

旧命令把工作委托给 Shell bootstrap 脚本，来源选择、下载、sudo 边界、仓库回滚、错误分类与结构化自动化都难以观察。 仅仅存在 ansible-playbook 二进制也可能产生假就绪，因为它使用的 Python 环境可能缺少必要模块。

离线安装还带来另一种歧义：控制节点已经可用时，仍可能需要为后续节点准备本地仓库。

考虑过的方案

  • 继续调用旧脚本。 PIG 无法拥有事务，也无法可靠解释部分失败。
  • 要求整个命令一开始就以 root 运行。 显式下载与来源校验不需要权限，应在一次有边界的提权前完成。
  • 把 Ansible 二进制存在视为就绪。 可执行文件使用的 Python 环境可能缺少必要模块。
  • Ansible 已就绪时跳过仓库工作。 显式离线来源的 staging 是独立的请求效果。
  • 把所有收尾检查设为硬失败。 locale 便利、本机 SSH 修复或目录初始化失败，不一定让控制节点不可用。

契约

  • 显式本地路径和 URL 必须校验，失败时不能悄悄回退到在线模式；
  • 自动发现的离线来源必须通过所有者与权限检查；
  • 已提交的本地仓库可以优先于选定的软件包；
  • 下载与受限归档解压使用原生有边界实现；
  • 离线包必须包含 pigsty/repo_complete 哨兵；附加根目录先预检并在 pigsty 前 rename， 冲突与中断残留都失败关闭，由操作员清理；
  • 来源解析完成后只进行一次提权，并可禁止或要求非交互提权；
  • 软件包准备失败时，被替换的仓库定义可以恢复；
  • 就绪检查实际执行 Ansible，并验证它会使用的 Python 模块；
  • 结果区分 ready、offline、online 与 existing 模式；
  • 硬失败和收尾告警使用不同结构化字段；
  • bootstrap 不声称 Pigsty 部署已经成功。

影响

原生工作流比脚本启动器更大，但副作用与回滚状态可见。 它能够在已经可用的控制节点上继续 staging 离线内容，也能为自动化提供稳定结果而不隐藏可选问题。

该命令仍不能证明 Pigsty 已经部署。控制节点就绪、Inventory 生成、部署和真实服务验证是不同门槛。

验证与演进

原生实现落地于 222616e， 并在 74e084e 中继续收敛。 测试覆盖来源优先级、权限检查、受限解压、sudo 自重启、仓库回滚、locale 修复、Ansible/Python 就绪、 本机 SSH、初始化、告警分类与结构化结果。v1.8.0 发布页记录了交付状态。

一项尚未发布的 v1.8 后续改进把离线包路径扩展为保留多个安全顶层仓库。它继续使用既有哨兵 契约，明确不增加 manifest 或恢复 journal。该改进已经实现并通过本地测试，但不属于上面的 v1.8.0 发布声明。

当前状态

pig sty boot 负责准备控制节点，不运行 deploy.yml，也不证明数据库服务已经就绪。 来源模式、环境控制和后续步骤以当前 pig sty 文档为准。

3 - 发布注记

pig 每个版本的发布注记

pig 每个已发布版本的发布注记，从新到旧。安装包与校验和见各版本的 GitHub 发布页。

已经装了的话，pig update 会通过系统包管理器就地升级；其它安装方式见 安装。

3.1 - pig v1.8.1

CLI 安全与仓库流程加固、扩展目录刷新、Go 1.27.1，以及 cargo-pgrx 0.19.2。

Pig v1.8.1 是 v1.8.0 之上的安全、正确性与维护版本。 本版本加固命令初始化、提权日志访问、仓库与构建流程、发布完整性，以及结构化输出脱敏； 同时刷新内置扩展目录，并将构建工具链升级到 Go 1.27.1 与 cargo-pgrx 0.19.2。 内置 Pigsty 版本仍为 4.5.0。

CLI 安全与正确性

  • 只读且不依赖配置的命令不再要求 HOME 可写，也不会把创建 ~/.pig 当作查询副作用； 叶子命令会保留自己声明的初始化策略。
  • pig pg log、pig pt log 与 pig pb log 通过 sudo 切换数据库 OS 用户时完整保留参数， 并拒绝不安全的日志文件链接。
  • pig do 在执行前校验 Pigsty 名称，并拒绝 Ansible 保留的集群目标。
  • PostgreSQL 原生角色检测绑定到用户选中的实例，而不是无关的本机默认实例。
  • 结构化结果会遮盖凭据、许可证材料与构建代理标识符，同时保持真实的失败状态。

仓库与构建加固

  • 仓库添加与删除在任一请求失败时整体返回失败，对模块选择去重，并保持替换边界。
  • 离线缓存包拒绝不安全路径、链接、特殊文件与不完整输入；归档解压继续采用有根、失败关闭的实现。 生产路径迁移到结构化结果后，删除了仅由测试引用的旧导出缓存包装。
  • 构建源码与制品校验会拒绝不完整或不安全输入；pig build proxy 使用软件包提供的服务契约， 参数保持可选，结构化输出不再泄露秘密标识符。
  • 自更新会验证发布校验和；发布工具拒绝脏工作区、错误 tag，以及覆盖不可变制品。

工具链与扩展目录

  • Go 升级到 1.27.1，Logrus 升级到 1.10.2，GoReleaser 升级到 2.18.0， golangci-lint 升级到 2.13.2。
  • pig build pgrx 默认安装 cargo-pgrx 0.19.2；如果某个扩展的目录元数据要求旧版 pgrx， 仍可通过 -v 显式选择。
  • 内置目录从维护中的 pgext 视图刷新：新增 acdat 0.1.0，将已被取代的 pgcontext_pgvector 标记为 removed，并更新软件包版本、仓库归属、PostgreSQL 覆盖与可用性矩阵。

验证

本版本从源码提交 e3d1eb4 构建。该精确提交通过完整 CI 工作流， 覆盖随机顺序测试、命令 race 回归、vet、静态分析、死代码检查、漏洞扫描与 GoReleaser snapshot。 随后 tag 通过 Release 工作流，生成并发布 RPM、DEB、macOS 与 Linux 制品。

兼容性提醒

  • 本版本没有移除 CLI 命令或参数。
  • 如果旧脚本依赖只读命令顺便创建本地配置，应改为显式准备所需状态。
  • pgrx 默认值变为 0.19.2；构建特定扩展时，仍以该扩展的目录元数据为准。

校验和

制品：GitHub Release · checksums.txt

文件校验和
pig-1.8.1-1.aarch64.rpm Linuxarm64SHA-256 839ce3818941318be7707bd6c845f371c609d6f176f04705916108f04cbee38c
pig-1.8.1-1.x86_64.rpm Linuxamd64SHA-256 54183895b09f82fb4d00d75f99e84f6bb4761e4bebd24042d646ee8b309a6d03
pig-v1.8.1.darwin-amd64.tar.gz macOSamd64SHA-256 167891e181d460d478a5ed8637d41017bc73201ec479a5735ca43c09dcf3826f
pig-v1.8.1.darwin-arm64.tar.gz macOSarm64SHA-256 1338500b4373c3ee3a08d6233202b3f391f5bf69ac0517501884ed2978e17d26
pig-v1.8.1.linux-amd64.tar.gz Linuxamd64SHA-256 5050cc4444313edc5863acd1a6c20bcfd3ae4af6e849c978d9a5882bc58f60a3
pig-v1.8.1.linux-arm64.tar.gz Linuxarm64SHA-256 ecf5fcf11e35169b557380bbfc717562db5a440271b79b9eb3b8fd74c0c7f167
pig_1.8.1-1_amd64.deb Linuxamd64SHA-256 cf0de4f938c7360908ac0e315a7241ab7f3810eb026e28d4b92137ad743dde34
pig_1.8.1-1_arm64.deb Linuxarm64SHA-256 108f50c5e6ccaf87b27cb62e36bbd8b45436039626e7715dbb3912bcbbb6963b

v1.8.1 ·

3.2 - pig v1.8.0

原生 pig sty boot 与 pig sty conf 工作流，以及 575 个已打包 PostgreSQL 扩展。

Pig v1.8.0 将 Pigsty 控制节点的准备过程原生化。两条核心安装命令 pig sty boot 与 pig sty conf 现在是具备完整失败处理能力的 Go 工作流， 不再包装旧版 bootstrap 与 configure Shell 脚本。本版本继续以 575 个已打包 PostgreSQL 扩展 作为统一发布口径，内置 Pigsty 4.5.0。

原生 pig sty boot

pig sty boot 现在是一套具备事务语义与完整失败处理的原生控制节点引导流程。它不再执行 <PIGSTY_HOME>/bootstrap，HTTP 下载与归档解压也不依赖 curl、wget、tar 或 gzip。

权限与就绪检查

  • 普通用户可以直接发起命令。Pig 会在一次 sudo 自重启前解析并下载显式来源； PIG_NO_SUDO=1 可禁用提权，PIG_NON_INTERACTIVE=1 可要求非交互 sudo。
  • Debian 12/13 会在安装控制节点软件包前检查 locale，并在新软件包可能补齐工具后按需重试。
  • 就绪判定会实际执行 ansible-playbook，发现其 Python 解释器，并检查 yaml、jmespath， 以及 cryptography 或 OpenSSL 两者之一；只有二进制文件但无法运行的 Ansible 不再产生假成功。

仓库来源与事务

  • 来源覆盖本地归档、HTTP(S) URL、经过权限检查的自动 /tmp/pkg.tgz、已经提交的 /www/pigsty 仓库，以及区域在线仓库。显式来源无效时直接失败，不会悄悄转为在线引导。
  • 已完成的 /www/pigsty 优先于选中的离线包。Pig 可以自行建立预期的 /www -> /data/nginx 布局，以受限解压提交离线内容，并在离线模式下只启用严格的 pigsty-local 仓库；在线模式会安装内嵌的 Pigsty 密钥，并保持仓库签名校验开启。
  • 默认覆盖策略会备份仓库定义，仓库或软件包准备失败时自动恢复；--keep 使用增量策略， 在线刷新失败时可以利用现有定义重试。
  • 结果会明确标记 ready、offline、online 或 existing 模式。即使 Ansible 已经可用， 显式、自动发现或已提交的离线来源仍会被准备。

收尾检查与自动化

  • Pig 会探测控制节点辅助工具，为发起调用的管理员用户修复到 127.0.0.1 的密钥 SSH， 并尽可能从在线或本地内容初始化缺失的 ~/pigsty。
  • locale、辅助工具、本机 SSH 与 Pigsty 目录初始化失败属于告警；显式输入无效、仓库或软件包 操作失败、安装路径不受支持，以及安装后 Ansible 仍不可用，仍然是硬错误。
  • JSON/YAML 使用 pig.sty.boot/v2 结果契约，包含模式与软件包管理器、仓库策略与回滚状态、 来源路径、locale、SSH 与初始化状态、变更、告警，以及后续 conf、inventory 与 deploy 命令。

原生 pig sty conf

pig sty conf 现在是一套完整的原生 Inventory 编译流程。它不执行 ./configure，也不会 回退到原始 Shell 行为：Pig 解析一个模板、执行有边界的结构化变更、校验完整候选，最后才提交 输出文件。

安全配置流水线

  • 默认模板为 conf/meta.yml；安全的斜杠分隔相对模式既可作为位置参数，也可通过 --conf 指定。绝对路径、目录穿越、路径逃逸，以及通过直接路径、符号链接、带符号链接父目录或硬链接 造成的源/输出别名都会被拒绝。
  • 源模板解析与 IP 冲突检查先于外部预检；解析、变更、预检或校验失败都不会改动目标文件。
  • Pig 执行原生 Inventory 校验，并在 ansible-inventory 可用时进行一次有时间边界的外部 解析；成功结果以 0600 权限原子写入。

Inventory 结构化变更

  • 最多十个互不相同的 --ip 地址会同时映射到 10.10.10.10 至 10.10.10.19，VIP 等 无关地址保持不变。未指定 --ip 时，交互、非交互与输入关闭场景都有明确且确定的选择行为。
  • --domain 只替换精确的 i.pigsty；CPU 少于四核的控制节点会自动从 oltp 节点与 PostgreSQL 调优配置切换为 tiny。
  • 区域变更会更新 all.vars.region；china 会启用模板中已有的 Docker 与 pip 镜像。 --proxy 将可用的代理环境变量写入 all.vars.proxy_env。
  • 通用模板支持 PostgreSQL 14-18 与显式指定的 19 beta，包括匹配的 locale 与 beta 仓库； 固定版本的 mssql、polar 与 pgNN 模式保留模板实际版本并产生告警。
  • --generate 为每个已知凭据标识符分配一个 24 位随机值，并一致更新生效值与文档占位符； 结果只列出生成的标识符，绝不输出机密值。

预检与结果契约

  • 未指定 --skip 时，预检覆盖平台、软件包管理器、控制节点资源、sudo/管理员权限、本机 SSH 与 Ansible 可用性；conf/build/ 下的构建模板有意绕过 IP 映射与管理员预检。
  • JSON/YAML 使用 pig.sty.configure/v1，报告模板与输出、已选择和丢弃的地址、请求与实际 PostgreSQL 版本、已应用选项、生成的机密标识符及告警。

其他更新

  • EL8 及以上软件包操作统一优先使用 DNF；本地 RPM 依赖按提供能力解析；新建软件仓库时恢复 预期的 /www 布局；自更新可容忍 latest 标记中的空白字符。
  • 例行刷新扩展目录、软件包版本、元数据与可用性矩阵，发布的 PostgreSQL 扩展数量保持 575。
  • CI 与发布构建使用 Go 1.26.6、固定版本的分析工具与 GoReleaser，并执行依赖校验、 工作流检查、漏洞扫描与完整发布快照构建。

兼容性提醒

  • pig sty boot 不再执行 <PIGSTY_HOME>/bootstrap；依赖 Shell 脚本副作用的自动化应改为 使用原生命令及其结构化结果。
  • pig sty conf --raw 已移除。请使用原生工作流；--conf MODE 仍然可用，等价的位置参数 形式为 pig sty conf MODE。
  • pig sty conf --ip 可接受最多十个逗号分隔的 IPv4 地址；--skip 与 --ip 仍互斥。 大写 -O 选择 Inventory 文件，全局小写 -o 选择命令输出格式。
  • EL8 及以上使用 DNF；有限的 EL7 兼容目录继续保留独立的传统 YUM 路径。

校验和

制品：GitHub Release · checksums.txt

文件校验和
pig-1.8.0-1.aarch64.rpm Linuxarm64SHA-256 02fd2628810c1b00de730ece32b09dba1318be4c99a4ff1a0551740e32bf223b
pig-1.8.0-1.x86_64.rpm Linuxamd64SHA-256 72ba72a00af52a84b08b1346f85b42668b52bc097e315774ff9f501ca23ece8b
pig-v1.8.0.darwin-amd64.tar.gz macOSamd64SHA-256 f023a5c9049dc532a057e932c73a8197683eaf4d97cb7a8f219492da1ad2a65f
pig-v1.8.0.darwin-arm64.tar.gz macOSarm64SHA-256 e0ccf61c4d135dbc45359c207751092aeb6df788e826bb73eccc1a1ed8800998
pig-v1.8.0.linux-amd64.tar.gz Linuxamd64SHA-256 a24a08c1b8d54adcdef5a99ed7b91caeedef1552a1440b1258eb4eb07fb20353
pig-v1.8.0.linux-arm64.tar.gz Linuxarm64SHA-256 9d23875804f87e78039498245059fd6b765831f027aacfc511ad0ac42711fa7b
pig_1.8.0-1_amd64.deb Linuxamd64SHA-256 96259ff7584cd52254c91a9fd7d77bd577f23c55cb09f4bc995a3ca0fcbc7321
pig_1.8.0-1_arm64.deb Linuxarm64SHA-256 2e7370211514df6355ef96fb812670febe6ee1b85a28378432c33ebdaecb4b63

v1.8.0 ·

3.3 - pig v1.7.0

更安全的 EL 模块处理、更新的中国镜像、精简的 EL7 兼容目录，以及 575 个已打包扩展。

Pig v1.7.0 是 v1.6.2 之上的仓库兼容性与目录更新版本：明确中国镜像选择语义，默认保留 DNF 原生模块过滤，恢复精简的 EL7 仓库目录，并将内置扩展快照从 572 个增加到 575 个。内置 Pigsty 版本仍为 4.5.0。

主要变化

  • -m|--mirror 现在直接选择内置的 china 仓库定义。PGDG、Rocky Linux、Debian、Ubuntu、Docker 等区域路由使用维护中的镜像列表，不再进行旧版运行时 PGDG 代理改写。
  • EL 仓库不再全局注入 module_hotfixes=1。确实需要覆盖模块流的 Pigsty 与 PGDG 仓库会显式启用；BaseOS、AppStream、EPEL 等普通仓库继续使用 DNF 原生模块过滤。
  • EL7 保留有意精简的兼容目录：面向 x86_64 的 CentOS 7 Base/Updates/Extras/SCLo 与 EPEL 归档源，以及共享的 Pigsty 和仍受支持的 PGDG 条目。渲染 EL7 YUM 配置时会移除仅适用于 DNF 的 module_hotfixes。
  • 当目录中没有匹配当前平台的仓库定义时，仓库设置会明确报告平台不受支持，而不是继续处理空仓库集合。
  • 发布元数据升级到 1.7.0，内置 Pigsty 版本保持 4.5.0。

扩展目录

  • 已打包扩展数量从 572 增加到 575，没有移除项。
  • 新增 3 个扩展：pg_local_cache 1.2.0、pg_statviz 0.1.0、pg_policy 0.1.0。
  • 版本更新包括 biscuit 3.0.0、pg_clickhouse 0.10.0、pg_search 0.25.2、pg_turbovec 软件包 1.29.0、pg_uuid_v8 1.1.0，以及 Debian q3c 2.0.5 软件包。
  • 刷新软件包元数据与可用性矩阵；需要比本版本内置快照更新的目录时，请运行 pig ext reload。

兼容性提醒

  • 本版本没有移除命令或全局参数。
  • -m|--mirror 现在明确选择中国区域，不再进行 PGDG 代理改写。需要固定路由时请使用 --region=default|china|europe。
  • 自定义 EL 仓库如果确实需要覆盖模块流，现在必须显式设置 meta.module_hotfixes: 1；普通操作系统仓库会有意省略该设置，EL7 上则会移除它。
  • EL7 已停止维护，仅提供有限兼容性；当前 PostgreSQL 与扩展软件包应优先使用 EL8 或更高版本。

校验和

制品：GitHub Release · checksums.txt

文件校验和
pig-1.7.0-1.aarch64.rpm Linuxarm64SHA-256 e3a339fefdd2203825d15438b52f18e729547eb88dae014212a46006a9bd47d1
pig-1.7.0-1.x86_64.rpm Linuxamd64SHA-256 34ce29d75ef9f669f3bf832cc812ae082abda7320ee2b2336ea61e701b9b67f8
pig-v1.7.0.darwin-amd64.tar.gz macOSamd64SHA-256 d26803c685ba29c01cb8e6dfe50c6c1b0f004173be82015618fa8cdf6a329ba7
pig-v1.7.0.darwin-arm64.tar.gz macOSarm64SHA-256 ea8120d48b93da936919f590ebbefeb72e73277e6bc133c1ef0bb1abc055d3ce
pig-v1.7.0.linux-amd64.tar.gz Linuxamd64SHA-256 40295b64a2423094fa6f4e6d31da8d8ad5b26698c397d8916c0289591522d0bf
pig-v1.7.0.linux-arm64.tar.gz Linuxarm64SHA-256 7929091732957d85751ef3381285a1e5b0c3c7f82c0e00fc24ed085c496012d5
pig_1.7.0-1_amd64.deb Linuxamd64SHA-256 41523c15f36a6c1acaf4af5c851d2626472fc15c21d25f91fc1e991fe8411072
pig_1.7.0-1_arm64.deb Linuxarm64SHA-256 adf7b2d9ce8fe42bad935428d16a9c998337df986b1065e0761dc167ce837ef5

v1.7.0 ·

3.4 - pig v1.6.2

572 个已打包扩展、Grafana 仪表盘 schema v2，以及 SOW 优先的本地软件仓库生成。

Pig v1.6.2 是 v1.6.1 之上的功能与目录更新版本：已打包扩展从 562 个增加到 572 个，新增 Grafana 仪表盘 schema v2 原生支持，并改进本地软件仓库生成流程。内置 Pigsty 版本继续锁定为 4.5.0。

主要变化

  • pig sty grafana 现在同时支持传统仪表盘 JSON 与原生 dashboard.grafana.app/v2 Dashboard 资源。载入 v2 仪表盘时使用 Grafana resource API，确保标签页与 section 变量可以完整往返；导出到现有 v2 文件时保持 v2 格式，新文件默认仍使用传统格式。
  • pig repo create 在 SOW 可用时优先执行 sow create --pigsty --timeout 10m -- <dir>，要求生成的 repo_complete 完成标记存在且为普通文件；Linux 上仍可回退到 createrepo_c / dpkg-scanpackages。
  • macOS 现在可通过 SOW 创建本地软件仓库，默认使用当前目录且无需 sudo；Linux 默认目录仍为 /www/pigsty。
  • 发布元数据升级到 1.6.2，内置 Pigsty 版本保持 4.5.0。

扩展目录

  • 已打包扩展数量从 562 增加到 572，没有移除项。
  • 新增 10 个扩展：pg_turbovec、pg_disorder、pg_mentat、plruby、jsonb_plruby、hstore_plruby、ltree_plruby、pg_describe、cat_tools、pg_vault_tde。
  • 更新 12 个扩展版本：timescaledb 2.29.1、q3c 2.0.5、pgmnemo 0.16.1、pg_search 0.25.1、citus 14.2.0、citus_columnar 14.2.0、provsql 1.12.0、plpgsql_check 2.10.4、pg_rational 0.0.3、pgbson 2.1.0、pg_readme 0.7.1、pg_readme_test_extension 0.7.1。
  • 刷新软件包元数据与可用性矩阵；运行 pig ext reload 可以用最新在线目录替换内置的发布快照。

兼容性提醒

  • 本版本没有移除命令或全局参数。
  • 安装 SOW 后，pig repo create 会优先使用 SOW 而非传统 Linux 生成器，并在报告成功前检查完成标记是否存在。
  • 目录总数不代表每个包都适用于所有 PostgreSQL / 操作系统 / 架构组合；请在目标主机上使用 pig ext avail NAME 查看实际可用矩阵。
  • 包管理器与安装脚本会使用配置的软件仓库中已经发布的最新版本，可能晚于 GitHub；需要精确获取本版本时请使用 GitHub 制品。

校验和

制品：GitHub Release · checksums.txt

文件校验和
pig-1.6.2-1.aarch64.rpm Linuxarm64SHA-256 6697a96bbf476e697a5c3da8b6c861719e4b7208e1e4fe927cf4b475ea1f162f
pig-1.6.2-1.x86_64.rpm Linuxamd64SHA-256 ad0b311867bc6cd689dd73e9a96b84f1fe0f49f6c0f1184abf9eb3232a07a184
pig-v1.6.2.darwin-amd64.tar.gz macOSamd64SHA-256 bb167e04fceb6cebee5c8a2423279cefb4474f46301a5055c464ac98294dc9db
pig-v1.6.2.darwin-arm64.tar.gz macOSarm64SHA-256 3de74e33321884a0c36596c1e7df9370be594a315395538e9ba5b775bbc1a79d
pig-v1.6.2.linux-amd64.tar.gz Linuxamd64SHA-256 7b69214e115e6815e772b7e179aa4070bd8553e585b164ba3a0f69a1d53a0294
pig-v1.6.2.linux-arm64.tar.gz Linuxarm64SHA-256 b511e727642987867be5921d72e8019e9c6186b82e63ddc34ad653773abed5a8
pig_1.6.2-1_amd64.deb Linuxamd64SHA-256 3d1a80b833c6179b84ac5cc590ad06695b187b2bb4a09f544b1a14f9684dc4bc
pig_1.6.2-1_arm64.deb Linuxarm64SHA-256 00e4c84cd6b07a98401c73fb58dedaafe34bc794d7604edbcb76c5de39b0fb44

v1.6.2 ·

3.5 - pig v1.6.1

pig v1.6.1 刷新了内置的扩展目录，并将内嵌的 Pigsty 版本对齐到 4.5.0。

pig v1.6.1 是 v1.6.0 之上的维护版本：没有新增命令，也没有参数变更， 这次发布的重点是二进制里自带的那份扩展目录。

变更内容

  • 扩展目录刷新：内置的 extension.csv 依据 Pigsty 软件仓库重新生成，pig ext list 与 pig install 无需先跑一次 pig ext reload，即可对齐当前的软件包版本。
  • Pigsty 版本对齐到 4.5.0：pig sty 与 pig status 报告的内嵌 Pigsty 版本随之更新。
  • 版本号同步：构建元数据与 pig update 的版本字符串一并更新。

v1.6.1 发布包内置的目录覆盖 PostgreSQL 14–18 上的 562 个已打包扩展， 适用于 EL 8/9/10、Debian 12/13、Ubuntu 22/24/26，x86_64 与 aarch64 双架构。 运行 pig ext reload 后，这份发布快照可能会被更新的在线目录替换。

升级方式 

pig update                 # 通过系统包管理器就地升级
pig update -v 1.6.1        # 或者指定精确版本

全新安装会直接拿到 v1.6.1：

curl -fsSL https://repo.pigsty.cc/pig | bash   # 中国大陆镜像
curl -fsSL https://repo.pigsty.io/pig | bash   # 全球站点（Cloudflare CDN）

如果只想刷新目录、不升级二进制，也可以：

pig ext reload             # 把最新目录下载到 ~/.pig/extension.csv

完整版本历史见 发布注记。

v1.6.1 ·

3.6 - pig v1.6.0

562 个已打包扩展，pt 原生透传，inventory 与 CMDB，Grafana 管理

Pig v1.6.0 是一个大版本：pig pt 重写为 patronictl 原生透传，新增根级 pig inventory 命令组提供 pigsty.yml 的无损编辑与校验（附带实验性的 PostgreSQL CMDB 交换能力），pig sty grafana 提供原生 Grafana 仪表盘管理，已打包扩展目录增至 562 个。

主要变化

  • pig pt 重写为 patronictl 原生透传：所有集群命令（list、restart、switchover、failover、edit-config 等）直接转发，使用原生参数、交互确认、输出与退出码，patronictl 的新功能无需等待 pig 发版即可使用。本地保留 status、log、set、service/svc 辅助命令，新增 -c/--config-file、-d/--dcs-url、-k/--insecure 选项与 pig pt -- … 逃逸写法。
  • 新增根级 pig inventory 命令组（别名 inv）：status / list / show / edit / validate / check / diff —— 无损 YAML 引擎逐字节保留注释、格式、键序与锚点；edit 先校验再原子写入，非法 YAML 不可能落盘。
  • 新增 实验性 pig inventory cmdb 子命令（check / init / load / dump / enable / disable），通过原生驱动与 Pigsty 的 PostgreSQL CMDB 交换配置清单，破坏性操作带超时限界与摘要锁定的确认门。
  • 新增 pig sty grafana（别名 gf）通过 HTTP 原生管理 Grafana 仪表盘：info / list / boot / load / init / dump / clean / lang / style。pig sty 命令面简化：移除 sty edit / validate / check / cmdb / dashboard / release，改用 pig inventory、pig sty grafana 与 pig sty list / get。
  • 可靠性强化：仓库 / 目录 / 下载写入全部原子化（中断不再留下半截文件）；结构化输出 -o json|yaml 下 stdout 只包含结果信封，被包裹命令的输出走 stderr；退出码更精确（用法错误 → 2，缺少 --yes 确认 → 7）；Ansible 列表变量改用 JSON 编码防注入。
  • 仓库刷新：MySQL 仓库升级到 8.4 LTS，新增 Percona XtraBackup（pxb84）与 MySQL Tools 仓库，Kubernetes 升级到 v1.36，LLVM apt 覆盖 Debian/Ubuntu 26，Percona TDE 改用 repo.percona.com 官方源，移除 wiltondb 仓库。
  • 工具链：Go 1.26.5，新增原生 PostgreSQL 驱动（pgx v5），内置 Pigsty 版本 4.4.0。

扩展目录

  • 已打包扩展数量从 531 增加到 562；PGEXT.CLOUD 总目录收录 2230 个扩展。
  • 新增 33 个扩展，包括 pg_lake 家族（pg_lake、pg_lake_table、pg_lake_engine、pg_lake_iceberg、pg_lake_copy）、pg_jieba、pg_cjk_parser、pg_fts、pgmonitor、pgmemento、pg_tiktoken_c、online_advisor、pgsqlmock、plx 等。
  • 移除 2 个：pg_analytics、spat；刷新 58 个扩展版本，包括 vector 0.8.5、timescaledb 2.28.3、pg_search 0.24.3、pg_tde 2.2.1、powa 5.2.0。
  • 包别名与 Pigsty 同步：kafka 更名为 kafka-stack；Debian/Ubuntu 的 postgresql 别名收窄为仅 postgresql-$v（完整开发套件请用 pgsql / pgsql-full）。

兼容性提醒

  • ⚠ pig pt failover <name>：位置参数现在是 集群名 而不是晋升候选成员 —— 请改用 pig pt failover CLUSTER --candidate MEMBER，升级前务必检查 failover 自动化脚本。
  • pig pt 位置参数改为原生的集群优先形式（restart CLUSTER [MEMBER]）；转发命令返回 patronictl 原生退出码、由 patronictl 自行交互确认（-y 不再门禁这些命令），且不再支持 -o json（请改用原生 --format json）。pig pt config 由 pig pt set K=V 与原生 show-config / edit-config 取代。
  • 结构化输出模式下，被包裹工具的输出移至 stderr，stdout 只有 JSON/YAML 信封 —— 请更新解析混合输出的脚本。
  • pig inventory edit 编辑成功后会将配置文件权限收紧为 0600（文件可能包含数据库凭据）。

校验和

文件校验和
pig-1.6.0-1.aarch64.rpm Linuxarm64SHA-256 6899e8a3e1c0adfe8c0c177c0632b0a00821b304ed5998fcbdf28d02660c6768
pig-1.6.0-1.x86_64.rpm Linuxamd64SHA-256 cabe593fe7f5c31cdbcd8d546ae4925b57f98f70c564452335568389f3f9737c
pig-v1.6.0.darwin-amd64.tar.gz macOSamd64SHA-256 1f46d4a0b4710eed06b2cf8e7e17ee04b8d65331697c5c65afd513cc28282231
pig-v1.6.0.darwin-arm64.tar.gz macOSarm64SHA-256 845decb95697fc68bc5e12bc80cecfd4c6d23160afee96568b699d82f2e9261d
pig-v1.6.0.linux-amd64.tar.gz Linuxamd64SHA-256 4f1bb4fda8131db9f40db15e1575a6045b373dee609250cf5ee2bdedc2db89e2
pig-v1.6.0.linux-arm64.tar.gz Linuxarm64SHA-256 4384d11150e31d614ed4ac3de4d6bf7ee7fa111ac84f5575753bb9f2f31f4ed8
pig_1.6.0-1_amd64.deb Linuxamd64SHA-256 e35ef0f2c76afe5f3512d34c0440abd8c0106c0e2775c5452e167ae3a4127e8e
pig_1.6.0-1_arm64.deb Linuxarm64SHA-256 c3bc6d04c6acd7e5c3164a33b7525b25a93e2de9822ce957c15c18ee0d551901

v1.6.0 ·

3.7 - pig v1.5.1

PG 内核分支包更新，镜像模式，修复若干问题

Pig v1.5.1 是一次构建与仓库维护版本，更新了多款 PG 内核分支包。

主要变化

  • 镜像/代理模式覆盖 repo、build、sty、update、ext update 等流程；pig build rust -m 会写入 Cargo 镜像配置并使用 rsproxy.cn。
  • 新增 PostgreSQL 19 beta 的 repo、tool、pgrx 显式构建开关：pig build repo --beta、pig build tool --beta、pig build pgrx -b；稳定默认值仍保持 PostgreSQL 18 与 PG14-18 窗口。
  • 刷新 IvorySQL、PolarDB、OrioleDB、OpenHaloDB、Babelfish、pgEdge 套件等内核与 fork 包别名。
  • 改进 Cloudberry 套件构建流程，覆盖 cloudberry、cloudberry-backup、cloudberry-pxf。
  • 刷新 Cloudberry、Babelfish、OrioleDB、pgEdge、PolarDB、polarstore、zlog、libpgfeutils、libfq 等源码与包元数据。
  • 改进较新 EL release 字符串处理，包括 EL9.6+ / EL10+ 上的 PGDG 仓库，以及 EPEL 在 EL10 上使用的 10z stream。
  • 刷新扩展版本，包括 pg_ivm 1.15、spock 5.0.10、snowflake 2.5.0、pg_tde 2.2、decoderbufs 3.6.0、IvorySQL 5.4 包。

校验和

文件校验和
pig-1.5.1-1.aarch64.rpm Linuxarm64SHA-256 bc83887d640ed299a967b4eda2ae6db621a985abfa022fccabf508f7ec7b98e3
pig-1.5.1-1.x86_64.rpm Linuxamd64SHA-256 f0eab8e638d9e00a9172751446db869d0fe6ca7f382c7d540a931e0764014c0a
pig-v1.5.1.darwin-amd64.tar.gz macOSamd64SHA-256 b32d894dc444ef2b9ec00816d50d82b5834e64c35b3bb18f08b6286a7ca8e8e7
pig-v1.5.1.darwin-arm64.tar.gz macOSarm64SHA-256 4d768829b7e93fac6c732e27f665d3ab3945ec8bc1c336e5b91980932e8c9932
pig-v1.5.1.linux-amd64.tar.gz Linuxamd64SHA-256 69f4a016af52f1ee8f1a1ffc1e405bb3be551c3813b6d24f70ef8394330be5eb
pig-v1.5.1.linux-arm64.tar.gz Linuxarm64SHA-256 f49becb5fd556b36a9aa8de0c27bdbe210f7958f59254d780774828f2340e77b
pig_1.5.1-1_amd64.deb Linuxamd64SHA-256 a0d15145409d8a2629a74d3071f7af593e470920f22d9af4bf6f96725dbb6d49
pig_1.5.1-1_arm64.deb Linuxarm64SHA-256 f05b9b5abef5992ed16cbb5b6a6e3e5e58230072e3665ecc57b9ce2df3edb9a6

v1.5.1 ·

3.8 - pig v1.5.0

531 个扩展，pigsty v4.4，pg/pb/pt/pitr 重做，clone/fork

Pig v1.5.0 是一次面向 PostgreSQL 日常运维的版本：新增本地数据库 clone / fork 工作流，明确 pg、pt、pb、pitr 的职责边界，并收紧高风险操作的预览、确认与结构化输出行为。

主要变化

  • pig pg 更聚焦本地 PostgreSQL 操作。新增 pig pg clone 用于快速创建数据库级副本，新增 pig pg fork 用于创建一次性物理实例分叉，适合本地验证、恢复演练和隔离实验。
  • 恢复流程拆得更清楚：pig pitr 作为 Patroni / PostgreSQL / pgBackRest 的恢复编排入口；pig pb restore 保持为低层 pgBackRest restore 原语。恢复命令现在必须指定明确目标，并提供更具体的 plan 与恢复后指引。
  • Patroni 操作更可预期：pig pt restart、reinit、switchover、failover 等高风险操作统一由 Pig 负责确认与 plan 输出；pig pt config pg 会提示是否需要 pig pt restart --pending。
  • 自动化脚本更安全：结构化输出不再隐式确认破坏性操作，执行高风险动作需要显式 -y/--yes；--plan 与 next_actions 更一致，方便先预览、再执行。
  • 日志与状态输出更适合排障：pg、pb、pt 的日志命令补齐 latest / tail / show / grep 等常用入口，结构化日志快照使用 JSONL 语义。
  • 构建与发布默认值更新：Pig 版本为 1.5.0，内置 Pigsty 版本为 4.4.0，pig build pgrx 默认 cargo-pgrx 升级到 0.19.1。

扩展目录

  • 可用扩展数量从 524 增加到 531，没有移除项。
  • 新增扩展：pg_ducklake、pgdisablelogerror、pg_stat_log、pg_stat_plans、passwordpolicy、db2fce、plpgsql_wrap。
  • 刷新一批已有扩展版本与包元数据，代表性更新包括 timescaledb 2.28.2、postgis 3.6.4、vector 0.8.4、biscuit 2.4.1、citus 14.1.0、orioledb 1.8、documentdb 0.113、credcheck 5.0、pgtt 4.5。
  • orioledb alias 不再固定到 PG17，而是按请求的 PostgreSQL 主版本解析；EL9 ARM64 Patroni alias 也调整为 noarch 包。

兼容性提醒

  • 自动化执行破坏性操作时请使用 -y/--yes；结构化输出模式不会再替代人工确认。
  • pig pb restore / pig pitr 需要明确指定一个恢复目标；自动 promote 类行为请使用 --target-action=promote。
  • 若干易混淆短参数经过整理；日志命令的 -o json 表示 JSONL 快照，不用于 tail / follow 这类流式交互场景。

校验和

文件校验和
pig-1.5.0-1.aarch64.rpm Linuxarm64SHA-256 9f83b78ed2eccedd55a86c634f88364f1945c3cefa1b23efdd72a7cf2062e1df
pig-1.5.0-1.x86_64.rpm Linuxamd64SHA-256 b792001498e9907d4659db46640f9c5164152b20689f90f93418f76fb4633e6e
pig-v1.5.0.darwin-amd64.tar.gz macOSamd64SHA-256 ae1081dfbff8564ecdf713c85e8025c91bfd38e6575ea9ac99a92f968ab8a29d
pig-v1.5.0.darwin-arm64.tar.gz macOSarm64SHA-256 6d69efcdcdc79fd90d2112e1e8042887020402aa037252d89d632243e7085dc6
pig-v1.5.0.linux-amd64.tar.gz Linuxamd64SHA-256 8f914821b317cde73d3aec4ed311d5e90710bbc8cb372c1de3322083c31f4a85
pig-v1.5.0.linux-arm64.tar.gz Linuxarm64SHA-256 d4de9ef1c28d0a3661c4a4d47c469b7bfd5f5bddb610325796afb669ab162234
pig_1.5.0-1_amd64.deb Linuxamd64SHA-256 35fd32affb4cb5bcca845d47a768782fb7005f06fcc1bcb5b7755d2627f96245
pig_1.5.0-1_arm64.deb Linuxarm64SHA-256 2be1df804d3f630560bc3ced0107c49ffad8bb52b004f72c7f8b4d09dc8d3e04

v1.5.0 ·

3.9 - pig v1.4.2

524 个扩展，PG19 beta，pgrx 0.18.1，Patroni 修复
  • 内置扩展目录从 510 个可用扩展刷新到 524 个，新增 14 个扩展：pg_stl、pgmnemo、psql_bm25s、pg_orca、pg_sorted_heap、graph、pgrdf、fsm_core、jsonschema、pg_durable、pg_mockable、pg_uuid_v8、pg_stat_backtrace、pg_projection。
  • 更新 48 个已有扩展的软件包元数据，包括 timescaledb 2.28.0、timescaledb_toolkit 1.23.0、pg_task 2.1.29、pg_search 0.24.0、pg_clickhouse 0.3.2、pg_graphql 1.6.1、documentdb 0.112、toastinfo 1.7、wrappers 0.6.1、pgclone 4.3.2 等；没有扩展被移除或降级。
  • 新增 PostgreSQL 19 beta 的安装、构建、配置支持。PG19 可以作为显式指定的安装版本使用，但自动探测、目录展示与 latest alias 的稳定默认版本仍保持为 PostgreSQL 18。
  • 新增 pg19 软件包别名与 PG19 分类别名解析。PG19 分类别名借用 PostgreSQL 18 的可见性模板，并且 beta 软件包展开只包含 PGDG 来源条目。
  • pig sty conf -v 19 会在模板支持时自动启用 beta 仓库模块；当模板没有针对 PG19 beta 调优，或无法自动启用 beta 仓库时，会给出明确警告。
  • 修复 Patroni 集群操作：patronictl restart、reinit、switchover、failover 现在会传入解析出的 CLUSTER_NAME；pig pt list 也支持可选集群名参数。
  • pig build pgrx 的默认 pgrx 版本从 0.18.0 升级到 0.18.1。
  • 发布元数据更新到 v1.4.2，刷新 Go module checksum，并补充 PG19 alias / 配置生成与 Patroni cluster-scope 行为的针对性测试。

校验和

文件校验和
pig-1.4.2-1.aarch64.rpm Linuxarm64SHA-256 790afe4d6622cb041b06c622bc466cb1b2960a77487f368238027fb4a3a5ef93
pig-1.4.2-1.x86_64.rpm Linuxamd64SHA-256 ef918166b38a5eb1d108a928718c9e2cb8c3590e5a1f72effee942faca9b4bea
pig-v1.4.2.darwin-amd64.tar.gz macOSamd64SHA-256 3e37ff22aed076cbdd453911dc89fcc9340b1a4faac62c0580094bc1eb2d6273
pig-v1.4.2.darwin-arm64.tar.gz macOSarm64SHA-256 5eb7db776cb149331ebb33e3e6164e1cf711d0107941b92c6930a1d4c4b4eb23
pig-v1.4.2.linux-amd64.tar.gz Linuxamd64SHA-256 c536c324e40a861217e31f4699ee5f0e6c2daeb4e6f0f0e8cc5f606da9d787eb
pig-v1.4.2.linux-arm64.tar.gz Linuxarm64SHA-256 8b2d5746264a95269535e5a426f78fe0020f73fa3391fcb613f274551c4786ab
pig_1.4.2-1_amd64.deb Linuxamd64SHA-256 566e06f6da1fe9d635c41258d20cd9ff10de4e6e74b3b41ba2c6204ba22743c8
pig_1.4.2-1_arm64.deb Linuxarm64SHA-256 8c09e741975cb2f74b0f88c5995a8fa43d6c30a9a7ab7aaf0b8d83a7c66e1fc1

v1.4.2 ·

3.10 - pig v1.4.1

510 个扩展，支持 Ubuntu 26.04，仓库校准
  • 扩展目录更新到 510 个扩展，新增 3 个扩展，更新 17 个扩展。
  • 新增 Ubuntu 26.04 resolute 支持，移除 Ubuntu 20.04 focal 支持。
  • 将 el9.aarch64 特例中的 patroni / patroni-etcd 提升到 4.1.2。
  • 校准上游软件仓库定义。

校验和

文件校验和
pig-1.4.1-1.aarch64.rpm Linuxarm64SHA-256 2b96e06d26e7425b13ac1f27d620b24b258f232bfc1d84c0b3aa2ee6505ea8aa
pig-1.4.1-1.x86_64.rpm Linuxamd64SHA-256 30a68d2fb97bb1d146ec57bcec2f279ce7fa4cf075fdcc9afc3d143f9a365896
pig-v1.4.1.darwin-amd64.tar.gz macOSamd64SHA-256 ff4ac1a15f6a1e0aa935922a4e402a428fd3579c0143a5e411e835089a55cc2c
pig-v1.4.1.darwin-arm64.tar.gz macOSarm64SHA-256 a23048d854bc2bef74a2b5cf42bd2f4aae79f3c9df3181a829ddf2167d939dc2
pig-v1.4.1.linux-amd64.tar.gz Linuxamd64SHA-256 74feec28ee879853633d8e9f3722c95aa25c47a3d3f6fb5bde3f3609b5c09378
pig-v1.4.1.linux-arm64.tar.gz Linuxarm64SHA-256 d50d1ce2b0d682a4ced72a4a11e6bddbd90f9dccbd16eae886045845eec83104
pig_1.4.1-1_amd64.deb Linuxamd64SHA-256 3fe640c3b6678fe4cef527a58dca54285f15d56c8fe0b3c2ed8b6879e1e91d41
pig_1.4.1-1_arm64.deb Linuxarm64SHA-256 d09fd6e747cb65acda225ffd5448a8fba3f676ce8044f4237d75a59b3d6a5b4e

v1.4.1 ·

3.11 - pig v1.4.0

510 个扩展，pgrx 0.18.0，更多构建规格
  • 刷新扩展目录，可用扩展总数增加到 510，并更新 timescaledb 2.26.3、decoderbufs 3.5.0、pgclone 4.0.0、nominatim_fdw 1.3 等版本。
  • 默认 pgrx 从 0.17.0 升级到 0.18.0，同步对齐相关 Rust 扩展构建版本。
  • 为 pig build get 刷新权威源码包映射，覆盖 Cloudberry / OrioleDB 构建输入，以及 RDKit / OneSparse 相关附加源码。
  • 修复 repo set 标志位隔离问题，并修正 PostgreSQL schema 级维护 SQL。
  • el9.aarch64 上的 patroni 升级到 4.1.1。

校验和

文件校验和
pig-1.4.0-1.aarch64.rpm Linuxarm64SHA-256 c8d2f46ea1b25f7d4665ee0994f0cb403a59f1464f80b3ecfa575ac283e5ecd0
pig-1.4.0-1.x86_64.rpm Linuxamd64SHA-256 fb1fd2f4f1e71894779de7b11a42960c09261620dffa0b54ff7f84e60efbf976
pig-v1.4.0.darwin-amd64.tar.gz macOSamd64SHA-256 aa08045a31c26b9a6bfb770753817581c819022a6ed899e44f7b5a31f57f1733
pig-v1.4.0.darwin-arm64.tar.gz macOSarm64SHA-256 80e50dd2ccd08d4a4016e85518186e156498e00c56a898e65acb96466db339f0
pig-v1.4.0.linux-amd64.tar.gz Linuxamd64SHA-256 e425bf35ab6cb7907e94caca802b4418e3baf4bb1642dd957ab4baaa9db9f583
pig-v1.4.0.linux-arm64.tar.gz Linuxarm64SHA-256 840a21695955d64af7df12f7157b49573b18586bb2bf9cc5e7079074b86d39b7
pig_1.4.0-1_amd64.deb Linuxamd64SHA-256 401d91bae78b14e3dcc338aaac9e451e94282c79efbe9affabcfeb8b36ece587
pig_1.4.0-1_arm64.deb Linuxarm64SHA-256 d60515f72fb9f8963554dc5668d2398e5ecefd0153a7756a9d555de90115bcce

v1.4.0 ·

3.12 - pig v1.3.4

504 扩展更新与发布产物校验和刷新

扩展数量更新至 504 个。

校验和

文件校验和
pig-1.3.4-1.aarch64.rpm Linuxarm64SHA-256 dc78def9a1e5eb483ac5df4c87f4ac0ef2018bb12b4bedff650d8ba4d58a05fd
pig-1.3.4-1.x86_64.rpm Linuxamd64SHA-256 998fcbdab1846c94c3155391d2100dad9b0fe338f48212022db38980bb11e696
pig-v1.3.4.darwin-amd64.tar.gz macOSamd64SHA-256 031048c561abbeeeaa73fa3ac919b9fb89479b61c8a759bee5db2efba2e8a1df
pig-v1.3.4.darwin-arm64.tar.gz macOSarm64SHA-256 e13c939330d32fa91819ce2da88d121fb02a1063240dbf6cc8fa7975960f8fd3
pig-v1.3.4.linux-amd64.tar.gz Linuxamd64SHA-256 46aa321cf45fc9be635d91b38969b7f3602b7f226f43e5ee0e7614a030945c64
pig-v1.3.4.linux-arm64.tar.gz Linuxarm64SHA-256 f25c4f336edba5c9d2145368082f54e5b1a8b2d4261285b7a1721c088df4caa4
pig_1.3.4-1_amd64.deb Linuxamd64SHA-256 563516047e37b25da01da9e25bcbada2c55642d1636b1bdab7d62488f9dcdfbb
pig_1.3.4-1_arm64.deb Linuxarm64SHA-256 81bb482892f7fd4be862d0f377cb37d01c925006c96998d81d94c770ed9652ba

v1.3.4 ·

3.13 - pig v1.3.3

481 扩展与 Go 1.26.2 更新
  • 扩展目录刷新，可用扩展总数增加到 481 个。
  • Go 工具链从 1.26.0 升级到 1.26.2。

扩展更新

扩展名 旧版本 新版本 备注
timescaledb 2.25.2 2.26.2 正常，PG15-18
pg_background 1.8 1.9.2 仅 DEB，PG14-18
pg_ivm 1.13 1.14 升级，PG14-18
system_stats 3.2 4.0 升级，PG14-18
nominatim_fdw 1.1.0 1.2 升级，PG14-18
pg_textsearch 0.5.0 1.0.0 PG17-18
pg_clickhouse 0.1.5 0.1.10 正常，PG14-18
pg_search 0.22.2 0.22.6 手工下载，PG15-18
pg_store_plans 1.9 1.10 升级，PG14-18
pg_dispatch 0.1.5 新增，PG14-18
pg_fsql 1.1.0 新增，PG14-18
pg_liquid 0.1.7 新增，PG14-18
pg_regresql 2.0.0 新增，PG14-18
pg_slug_gen 1.0.0 新增，PG15-18
pg_stat_ch 0.3.3 新增，PG16-18
pg_variables 1.2.5 新增，PG14-18
pgcalendar 1.1.0 新增，PG14-18
pgclone 2.2.0 新增，PG14-18
pgelog 1.0.2 新增，PG14-18
pglock 1.0.0 新增，PG14-18
pgproto 0.2.1 新增，PG14-18
postgresbson 2.0.2 新增，PG14-18
rdf_fdw 2.4.0 新增，PG14-18
parray_gin 1.4.0 新增，PG14-18

校验和

文件校验和
pig-1.3.3-1.aarch64.rpm Linuxarm64SHA-256 e74418061ea975fbc3e8a89b31f274d7dc3617d12b9d681e5c8ef03584392088
pig-1.3.3-1.x86_64.rpm Linuxamd64SHA-256 8450e3e1076425fc8a10f24cc5fd833c3d2d880bab12baff5c10e59a31f62231
pig-v1.3.3.darwin-amd64.tar.gz macOSamd64SHA-256 952a0e94b9020fca5add91f8e9a398fbedfda5d2e5c8736e59ddaa2b7152c826
pig-v1.3.3.darwin-arm64.tar.gz macOSarm64SHA-256 c896b4fd44b19a250f4c3c47dc78643e10e92fde8cb6531b08cdc78e3623bb8a
pig-v1.3.3.linux-amd64.tar.gz Linuxamd64SHA-256 d18a92f9aa05d6315c5e9bfde3245afc08fca93d200a8063aa20cb40feb8e85e
pig-v1.3.3.linux-arm64.tar.gz Linuxarm64SHA-256 62d020072360229b47f6c430b014344b912f2d9b58fd528154ae9c4ee805190a
pig_1.3.3-1_amd64.deb Linuxamd64SHA-256 7a613a1f1c323ee78276b1733df026b8b0f415e0057b4cb8e509f771bfd3d614
pig_1.3.3-1_arm64.deb Linuxarm64SHA-256 f4c91ce86b787b6ab8cd584949d38c2ca87eb82d5e066bab91b80345252f43d8

v1.3.3 ·

3.14 - pig v1.3.2

例行元数据更新，新增 pg tune 命令与构建别名

例行维护版本。

  • 例行刷新部分扩展版本元数据与扩展目录条目，扩展版本更新。
  • 新增 pig pg tune 子命令，可根据硬件资源与工作负载画像生成 PostgreSQL 调优参数建议。
  • 为 pig build get 新增 pdu 与 pgdog 两个源码包 alias。
  • 调整 pgext.cloud 的 URL 至新版本的扩展目录 pigsty.io/ext

校验和

文件校验和
pig-1.3.2-1.aarch64.rpm Linuxarm64SHA-256 d760f47652ff3e2e4a61eb7b9a68ca68665b2b36c187c52f5eaf50d2f007d8f3
pig-1.3.2-1.x86_64.rpm Linuxamd64SHA-256 c2e02e62497f4c2055a9b448ddb3a24c618fcd488580c28b2b9a0e7cedacef55
pig-v1.3.2.darwin-amd64.tar.gz macOSamd64SHA-256 b8d066ddefa4530946c74c30e7e4acdab6abf8da70a47dcfe2a77719b79e397f
pig-v1.3.2.darwin-arm64.tar.gz macOSarm64SHA-256 a90e78d879fd720fd2865870c696aed7952558d5ae75591deced3121f2aab1f9
pig-v1.3.2.linux-amd64.tar.gz Linuxamd64SHA-256 2fe3a9ffbb6383154dfd25ed79420b210828eabf6a96a8af6e8feb9d744b9559
pig-v1.3.2.linux-arm64.tar.gz Linuxarm64SHA-256 522290aaf14f98f0bae83ce75cc76749f2a4e72742eb5c3cba36a1d2fa4d12c2
pig_1.3.2-1_amd64.deb Linuxamd64SHA-256 d6c1cf2c52962045f6bbfb2a669058e7f903088526591d6c939e7723f3928d30
pig_1.3.2-1_arm64.deb Linuxarm64SHA-256 4352385c629b26a1837054445a546da89591499848b557699c2fb70fde9377aa

v1.3.2 ·

3.15 - pig v1.3.1

PG13 退役，支持窗口统一为 PG14-18，扩展增至 464

这是从 v1.3.0 到 v1.3.1 的一次小型维护版本。

  • 由于 PGDG 上游已移除 PG13 归档与分发，pig 同步移除 PG13 安装/构建支持。
  • 活跃支持的 PostgreSQL 主版本现在为 14-18。
  • 扩展目录刷新（461 -> 464），新增 pg_pinyin、pg_eviltransform、qos。
  • Percona PPG 上游仓库更新到 18.3。
  • 修复 pig build 依赖/构建同步问题，rsync 增加 --keep-dirlinks 参数。
  • YUM 仓库中 Nginx 从 infra 模块拆分为独立模块索引（nginx）。

校验和

文件校验和
pig-1.3.1-1.aarch64.rpm Linuxarm64SHA-256 196e57c7dd46cdedd90ab75965a766f74aabc3bc23ddc8fb757473647bed7b8f
pig-1.3.1-1.x86_64.rpm Linuxamd64SHA-256 e4bdd52ef635524d5aec95f6a5abd76bd49940584ecbb00bd309a4f9186292ac
pig-v1.3.1.darwin-amd64.tar.gz macOSamd64SHA-256 4f3f9479344c158e1c5edc3003471be6b595c01b7d86104bf676b34f8faadce5
pig-v1.3.1.darwin-arm64.tar.gz macOSarm64SHA-256 05ae2f550ef5062ab5714518a24bbf52f48079ca6d0190359fae5b8f4cb7f20d
pig-v1.3.1.linux-amd64.tar.gz Linuxamd64SHA-256 940645497e907e56bfd387a478e580ac930aaa72593cc9d04225a08b37880ec4
pig-v1.3.1.linux-arm64.tar.gz Linuxarm64SHA-256 8b2c204fd6c933a1097cd1cd0ce491b02ba5c0025626a331a199684ceca3ab43
pig_1.3.1-1_amd64.deb Linuxamd64SHA-256 1cfc23d147795cc4c1ea9596e6978d79ff1ec34c02850fbb224f7c2844548ea5
pig_1.3.1-1_arm64.deb Linuxarm64SHA-256 e495678ae1c762194a56e8c9969fd2109e7a59830f34a4747039fb978f7820cc

v1.3.1 ·

3.16 - pig v1.3.0

构建链路强化，扩展增至 461，新内核支持

这是从 v1.2.0 到 v1.3.0 的一次工程强化与目录扩展版本：15 commits、74 files changed、代码行 +1184 / -236。

该版本重点围绕 pig build 构建链路和 ext 目录/别名能力增强，并将可用扩展数量从 451 增加到 461。

主要变化

  • 构建源码下载增强（pig build get）：
    • 支持从扩展 Source 字段解析多源码（空格/换行/Tab 分隔）并去重。
    • 新增 agensgraph / agentsgraph 源码映射。
    • pgedge 构建源码改为同时下载 postgresql-17.9.tar.gz 与 spock-5.0.5.tar.gz。
  • 依赖解析与安装优化（pig build dep）：
    • RPM 依赖安装可从 spec 的 pgmajorversion 宏推断 PG 主版本，spec 缺失改为显式报错。
    • DEB 依赖解析支持 Build-Depends / Build-Depends-Arch / Build-Depends-Indep 的多行、候选依赖、架构限定与 profile 清理。
    • 支持 PGVERSION 占位符自动展开（优先 --pg，其次已安装版本与扩展元数据）。
    • 依赖安装失败降级为 warning，批量流程继续执行。
  • DEB 构建结果判定修正（pig build ext/pkg）：
    • 构建命令退出码成功即判定成功，产物发现改为 best-effort 警告，避免误判失败。
    • 成功但无产物时不再显示空包列表横幅；部分产物场景标记 warning 而非 fail。
    • 构建日志中的源码与版本显示改为读取扩展元数据真实值，避免错误拼接 name-version。
  • 扩展操作输出语义改进（pig ext rm/update）：
    • 别名解析后，removed/updated 返回值改为“实际包名”，方便自动化脚本精确比对。
  • 扩展目录与别名更新：
    • 新增别名：agensgraph / agens、pgedge、babelfishpg。
    • openhalodb 对齐 PG14 包命名，ivorysqldb 命名对齐。
    • fork 元数据与可用性矩阵批量刷新（含 timescaledb、pgmq、orioledb、documentdb、pg_tde、babelfishpg_* 等条目）。
  • 工程与发布：
    • 版本号提升到 v1.3.0（包含 v1.2.1 过渡提交），版权年份更新到 2026，README 同步更新到 461 扩展与最新 alias 说明。

兼容性提醒

  • pig ext rm/update 结构化输出中的 removed/updated 字段由扩展名切换为包名；如果你的自动化逻辑按扩展别名匹配，请同步调整。

新增扩展（451 -> 461）

扩展名 版本 说明
aux_mysql 1.5 openHalo MySQL 兼容辅助模块（PG14）
gb18030_2022 1.0 IvorySQL 编码转换模块
ivorysql_ora 1.0 IvorySQL Oracle 兼容扩展
ora_btree_gin 1.0 Oracle 类型 GIN 索引支持
ora_btree_gist 1.0 Oracle 类型 GiST 索引支持
pg_get_functiondef 1.0 获取函数定义
plisql 1.0 PL/iSQL 过程语言
snowflake 2.4 pgEdge Snowflake ID 生成扩展
spock 5.0.5 pgEdge 多主逻辑复制扩展
lolor 1.2.2 pgEdge 大对象逻辑复制兼容扩展

完整提交列表（v1.2.0..v1.3.0）

  • b8ecf8d 版本字符串更新到 1.2.1
  • 55df9a4 build/get 支持多源码解析与 pgedge spock 源码
  • da8e347 新增 agensgraph 和 pgedge 别名
  • 86edbd7 ext rm/update 输出显示解析后的包名
  • ef3c905 build/dep 改进 rpm/deb 依赖解析
  • 7144e09 刷新 fork 元数据与可用性矩阵条目
  • befffbf DEB 构建将成功命令视作权威结果
  • 33fd517 DEB 成功但无产物时不再显示空包列表横幅
  • 3b450f2 下载源码时避免将扩展名与版本错误拼接
  • 33847ab ext rm/update 满足 staticcheck S1011
  • b8b917d 依赖安装失败降级为 warning
  • 8110c00 调整 ivorysqldb / babelfishpg 别名
  • fac9faf 版本提升到 1.3.0
  • 1f88f06 版权年份更新为 2026
  • c804757 v1.3.0 发布提交

校验和

文件校验和
pig-1.3.0-1.aarch64.rpm Linuxarm64SHA-256 196f32419886da095f303b1bcad2729b674abc03d412199e88a39390b2616534
pig-1.3.0-1.x86_64.rpm Linuxamd64SHA-256 a2dcc930dd47a08e85285c1fb7925e1355a1e67d458a265a7ef6d9666bc8e7ec
pig-v1.3.0.darwin-amd64.tar.gz macOSamd64SHA-256 c7ebda6b9839408b12ffe1c8ea561f03e1793aae0732f9bbe2320a0d45160714
pig-v1.3.0.darwin-arm64.tar.gz macOSarm64SHA-256 b717b485ed0a4a8c11dd8bf918400595b21df5ef43818836ec332f8518674c1a
pig-v1.3.0.linux-amd64.tar.gz Linuxamd64SHA-256 40e6570c6ba0fe36c97950ff8de585eecb6bc1f862509a04f410a5f08ee90148
pig-v1.3.0.linux-arm64.tar.gz Linuxarm64SHA-256 d61430eeafc8005a22918a9aa60dea5c987916f9834331b5484f761b8235644f
pig_1.3.0-1_amd64.deb Linuxamd64SHA-256 62c9a4fadc7dda393d6f28ab83b5f3d741e7d7f7de7abe40a5b89c393288519c
pig_1.3.0-1_arm64.deb Linuxarm64SHA-256 19261ae50e873a05a10a6ad500ab1b429b22e2612325c09f9cd5443dcd34308b

v1.3.0 ·

3.17 - pig v1.2.0

统一别名，例行更新，计划模式，仓库修复

  • 扩展目录与别名解析增强：

    • 引入动态 PG 分类别名解析，按 PG 主版本选择别名映射。
    • 引入 OS 维度别名覆盖（ansible/bootstrap），并在未知发行版回退中收敛为 PGDG-only。
    • 新增 node/infra、babelfish/cloudberry 等别名并更新扩展元数据，减少包解析歧义。

  • 高风险操作计划预览：

    • 新增 pig install --plan，支持结构化执行计划输出。
    • 统一 pig pitr 与 pgBackRest repack/expire 的计划预览语义。
    • 新增 plan flag 一致性测试，确保子命令行为对齐。

  • sty 原生配置能力：

    • 新增 pig sty configure 命令及完整执行流（preflight、参数处理、执行编排）。
    • 统一 sty conf/configure 行为，默认走原生实现并保留 --raw 回退。
    • 补充 configure 主流程、preflight、路由与安装联动测试，提升可维护性。

  • 仓库/构建/可靠性修复：

    • 修复 repo cache 在 os.Stat 错误场景中的 nil dereference。
    • 对齐 Ubuntu 与 Debian 仓库 channel 映射，补充 reload 镜像拉取超时控制。
    • 加固 repo rm 对 dotted module 名称的安全删除与路径校验。
    • 修复 sty init 与 build 相关符号链接保留、跨设备迁移与目标目录处理问题。
    • 改进文本输出与矩阵配色渲染，修复 ext 命令空参数与空目标校验问题。

  • 35 Commit，66 文件变更，代码行：+5006 / -379

  • PG 扩展与内核包更新

包名 旧版本 新版本 备注
timescaledb 2.25.0 2.25.1
citus 14.0.0-3 14.0.0-4 使用最新官方版本重新构建
age 1.7.0 1.7.0 新增 PG 17 的 1.7.0 版本支持
pg_background - 1.8 仅构建 DEB 包，RPM 来自 PGDG
pgmq 1.10.0 1.10.1 当前没有该扩展包
pg_search 0.21.6 0.21.8 直接下载使用
oriolepg 17.11 17.16 OriolePG 内核更新
orioledb beta12 beta14 配套 OriolePG 17.16
cloudberry - 2.0.0 新增包
babelfishpg - 5.5.0 新增 BabelfishPG 包组
babelfish - 5.5.0 新增 Babelfish 兼容包
antlr4-runtime413 - 4.13 新增 Babelfish 依赖运行时

校验和

文件校验和
pig-1.2.0-1.aarch64.rpm Linuxarm64SHA-256 344b77385fa9c3d4fe5e1961340e68716251e38d1cb8308f5af45ce8a03cd206
pig-1.2.0-1.x86_64.rpm Linuxamd64SHA-256 aa9cf1820a9045cc42f0d66689d5e8679cb71452042f3f01ddd4c3a518a2b757
pig-v1.2.0.darwin-amd64.tar.gz macOSamd64SHA-256 f26e4d9e9fa76c39f7c591c18a09287ca3388e016d121c196302ee9eafb5b678
pig-v1.2.0.darwin-arm64.tar.gz macOSarm64SHA-256 2ca41efc3495822305f6e6a3ae1825d57cc97e764f280581f833c72e6e5019a2
pig-v1.2.0.linux-amd64.tar.gz Linuxamd64SHA-256 f7aa291b3534d92d0459b6e8301190e39c63db14a45a6c097d4c5d3062c35181
pig-v1.2.0.linux-arm64.tar.gz Linuxarm64SHA-256 38007ecd6d7a69bae0e3d8f7c78f1a4c8bbaead320b7ac319b0d94d6b53853f0
pig_1.2.0-1_amd64.deb Linuxamd64SHA-256 e824716ddfbf3805dc0a1fd6d97917241b7780503657e9fd40a37beb6b398d7a
pig_1.2.0-1_arm64.deb Linuxarm64SHA-256 b67baa404d877b37004331041cb270c85b8f9a3f8a92a5083390a54d76553d2a

v1.2.0 ·

3.18 - pig v1.1.1

修复路径、符号链接与构建目录迁移问题

修复

  • 在迁移构建目录时保留符号链接语义，并支持跨文件系统移动。
  • 正确处理被配置为文件系统根目录的 PostgreSQL 日志目录，防止解析到预期目录之外的文件。
  • 允许 pig repo rm 删除名称中带点号的仓库模块，同时保留安全路径校验。
  • pig sty init 解压 Pigsty 发布包时允许安全的相对符号链接。

校验和

文件校验和
pig-1.1.1-1.aarch64.rpm Linuxarm64SHA-256 22fe5e951f09e7cfa46ab22781199b3209792992940eb5615ace4928e41a7429
pig-1.1.1-1.x86_64.rpm Linuxamd64SHA-256 7f5a10bbefdc39e5d66a7e688fa78c5ba566c8140458b9f4b1536ff0d7ed457a
pig-v1.1.1.darwin-amd64.tar.gz macOSamd64SHA-256 b90aec9dc559df81c46d32575a8d231fa6d7eeb8b25f4d2e0b6076cc0a9c0e59
pig-v1.1.1.darwin-arm64.tar.gz macOSarm64SHA-256 3063e3a72e68371a082b4e629d12aafda46d96eddc22976beb2049881854f4ea
pig-v1.1.1.linux-amd64.tar.gz Linuxamd64SHA-256 081ff8c81bf61108a35ca4cdc51007d4ddf1de8a041d8be087e58e7068e7e177
pig-v1.1.1.linux-arm64.tar.gz Linuxarm64SHA-256 9a81e868699f92d73f8aeb7752206b6eaac8d42d1688089a1f543b12ee0d272d
pig_1.1.1-1_amd64.deb Linuxamd64SHA-256 85ce861cfbff846be2ba912ba8dfc766121dad14a59937387d9c5e26b0b6f541
pig_1.1.1-1_arm64.deb Linuxarm64SHA-256 3a108f0544af4d1f98acee55c06c5b5af3b856e3be2b18767e6db0b8a1cc664f

v1.1.1 ·

3.19 - pig v1.1.0

451 扩展，Agent-Native CLI 框架

该版本是从 v1.0.0 到 v1.1.0 的一次规划中架构级升级（79 commits，193 files 变更）， 核心目标是把 pig 从“人类可用 CLI”推进到“Agent-native 可编排 CLI”。

新增七个扩展，总可用扩展数量达到 451 个。

新功能

  • Agent-native 统一输出框架落地：引入全局 --output（text/yaml/json/json-pretty），为 ext/repo/pg/pt/pb/pitr/status/version/context 等命令提供统一 Result 结构、稳定状态码与可机器解析输出。
  • 引入 ANCS（Agent Native Command Schema）元数据体系：为命令补齐 type/volatility/parallel/risk/confirm/os_user/cost 等语义字段，help 在结构化模式下可直接输出命令能力树，便于 Agent 自动发现能力与风险边界。
  • 新增 pig context（pig ctx）环境快照命令：一次调用聚合主机、PostgreSQL、Patroni、pgBackRest、扩展信息，专门面向 Agent 工作流做上下文注入。
  • Plan 能力从 PITR 扩展到更多高风险动作：新增 pig ext add/rm --plan、pig pg stop/restart --plan、pig pt switchover/failover --plan，并统一为可审阅执行计划（动作、影响面、风险、预期结果）。
  • 结构化结果覆盖进一步完善：pgbackrest info 可嵌入原生 JSON 信息，Patroni/PostgreSQL/PITR/Repo/Ext 子系统的结构化返回与辅助 DTO 统一，兼容自动化消费。
  • 兼容层增强：对 pg_exporter/pg_probe/do/sty 等存量命令引入 legacy structured wrapper，在保留旧交互行为的同时提供结构化执行结果与输出捕获。
  • Pigsty 版本更新至 v4.1.0

扩展更新

扩展 旧版本 新版本
timescaledb 2.24.0 2.25.0
citus 14.0.0-2 14.0.0-3
pg_incremental 1.2.0 1.4.1
pg_bigm 1.2-20240606 1.2-20250903
pg_net 0.20.0 0.20.2
pgmq 1.9.0 1.10.0
pg_textsearch 0.4.0 0.5.0
pljs 1.0.4 1.0.5
sslutils 1.4-1 1.4-2
table_version 1.11.0 1.11.1
supautils 3.0.2 3.1.0
pg_math 1.0 1.1.0
pgsentinel 1.3.1 1.4.0
pg_uri 1.20151224 1.20251029
pgcollection 1.1.0 1.1.1
pg_readonly 1.0.3 1.0.4
timestamp9 1.4.0-1 1.4.0-2
pg_uint128 1.1.1 1.2.0
pg_roaringbitmap 0.5.5 1.1.0
plprql 18.0.0 18.0.1
pglinter 1.0.1 1.1.0
pg_jsonschema 0.3.3 0.3.4
pg_anon 2.5.1 3.0.1
vchord 1.0.0 1.1.0
pg_search 0.21.4 0.21.6/0.21.7
pg_graphql 1.5.12-1 1.5.12-2
pg_summarize 0.0.1-2 0.0.1-3
nominatim_fdw - 1.1.0
pg_utl_smtp - 1.0.0
pg_strict - 1.0.2
pg_track_optimizer - 0.9.1
pgmb - 1.0.0

Bug 修复

  • 安全修复：修复 pig build proxy 在异常地址输入下的解析 panic 问题。
  • 安全修复：修复 pig pg log 文件名路径穿越风险，阻止通过 ../../ 访问日志目录外文件。
  • 安全加固：加强 installer/repo 路径处理与引号处理，降低路径注入与异常路径误用风险。
  • 构建链路可靠性修复：pig build get/pkg/ext 在下载或构建失败时正确传递错误并返回非零退出码；修复 DEB 构建中 pg_ver 不匹配导致的误报失败。
  • 仓库与目录刷新修复：ext/repo reload 支持静默镜像回退；repo add/set/rm 在缓存更新失败时正确返回错误状态。
  • 扩展管理修复：ext update 调整为显式目标更新并修复状态漂移问题；ext import 将请求的 DEB 资源下载到指定 repo 目录。
  • 输出与可观察性修复：修复结构化输出 exit code 与文本渲染一致性问题；修复 pg status 权限处理与解析稳定性问题。

校验和

文件校验和
pig-1.1.0-1.aarch64.rpm Linuxarm64SHA-256 95245dc035270df2b02cdd5d19afac57ccf4949a61b07b1b806fffde3a3b780e
pig-1.1.0-1.x86_64.rpm Linuxamd64SHA-256 8b1a26f1b5dd002841a0b31904eea8ce94d1e6c4acde4704a78d9e121e1656f4
pig-v1.1.0.darwin-amd64.tar.gz macOSamd64SHA-256 dbd079510513f1cd0521b0871cc6fe3eed8f7fa26f66c04c682568c43e24c456
pig-v1.1.0.darwin-arm64.tar.gz macOSarm64SHA-256 3f3ba081b54569a7de4d9a8fce72c02c84d9e1cbeb53173567f970c7291af251
pig-v1.1.0.linux-amd64.tar.gz Linuxamd64SHA-256 ad61384bf01cbb8346ce869da0bc893203ad316c516fb9420cb748f1519a005e
pig-v1.1.0.linux-arm64.tar.gz Linuxarm64SHA-256 7713632beea1e6ca5c3e2e7172c4adee13a2b1b256755f6c2898b6ca98ee1e00
pig_1.1.0-1_amd64.deb Linuxamd64SHA-256 70cfc41b7b0aad48f29e12c22c34afd55b938bf50868ac8ab067b9cb62ccb867
pig_1.1.0-1_arm64.deb Linuxarm64SHA-256 fc5cf16671254f8f3495ff7e80c9d77d06b2328c1a247f90f96cf1e918e0ad0e

v1.1.0 ·

3.20 - pig v1.0.0

444, 新增 pg/pt/pb/pitr 子命令，可用性矩阵

本版本引入三组主要的新子命令（pig pg、pig pt、pig pb），用于管理 PostgreSQL、Patroni 和 pgBackRest，同时新增编排式 PITR 命令，并增强扩展可用性显示。

新增命令

  • pig pg - PostgreSQL 实例管理

    • pg init/start/stop/restart/reload/status - 控制与管理 PostgreSQL 实例
    • pg role/promote - 检测和切换实例角色（主库/从库）
    • pg psql/ps/kill - 连接与会话管理
    • pg vacuum/analyze/freeze/repack - 数据库维护操作
    • pg log - 日志查看（list/tail/cat/less）

  • pig pt - Patroni 集群管理

    • pt list/config - 查看集群状态与配置
    • pt restart/reload/reinit - 管理集群成员
    • pt switchover/failover - 集群切换操作
    • pt pause/resume - 控制自动故障切换
    • pt start/stop/status/log - Patroni 服务管理

  • pig pb - pgBackRest 备份管理

    • pb info/ls - 查看备份信息
    • pb backup/restore/expire - 备份操作
    • pb create/upgrade/delete - Stanza 管理
    • pb check/start/stop/log - 控制操作

  • pig pitr - 编排式时间点恢复

    • 自动协调 Patroni/PostgreSQL
    • 多种恢复目标：时间、LSN、XID、还原点
    • 支持计划预览模式与恢复后指引

新功能

  • 为 pig ext avail 和 pig ext ls 添加可用性矩阵

改进

  • 统一 pg/pt/pb 命令别名风格
  • 规范化错误消息格式
  • 代码重构与清理

Bug 修复

  • 修复 UTIL 扩展分类缺失问题

校验和

文件校验和
pig-1.0.0-1.aarch64.rpm Linuxarm64SHA-256 306637079e942bcac9ccbc089cd09a80051898f8db1630269bb1acd3fbdaa872
pig-1.0.0-1.x86_64.rpm Linuxamd64SHA-256 d2b9440410f00efbca174d63b507c39d97fc55f402d8e9290ee054c1b1c6414c
pig-v1.0.0.darwin-amd64.tar.gz macOSamd64SHA-256 c8a169e48a8168ee03db508ca2edc22b56ecf6997bae924e9023796ab7ae4e62
pig-v1.0.0.darwin-arm64.tar.gz macOSarm64SHA-256 c0996037bfeffeae241b545e69d46c06e7fec2d7d456885229f3af9a7f9ea2f8
pig-v1.0.0.linux-amd64.tar.gz Linuxamd64SHA-256 13837c6f2379edf965888bad9e373e69f70cb72e8428bca18c2c804e2bd879f6
pig-v1.0.0.linux-arm64.tar.gz Linuxarm64SHA-256 08207dfedd6f72745631596a3d3293de65cc12e1544956a643d1da2165d2c876
pig_1.0.0-1_amd64.deb Linuxamd64SHA-256 a543882aa905713a0c50088d4e848951b6957a37a1594d7e9f3fe46453d5ce66
pig_1.0.0-1_arm64.deb Linuxarm64SHA-256 4cd6ec54261b09025c12e9c56bcc0cd3c11779ea0e8becdbd4f901cf2e7c8995

v1.0.0 ·

3.21 - pig v0.9.0

重命名 sty deploy 并扩展 sty conf 参数

变更

  • 将 pig sty install 重命名为 pig sty deploy，使命令名称准确表达其执行 Pigsty 部署 playbook 的行为。
  • 为 pig sty conf 增加 -g、-p 与 -o 参数，与该版本中的 configure 脚本保持一致。
  • 在 pgsql-full 软件包别名中保留 llvmjit。

校验和

文件校验和
pig-0.9.0-1.aarch64.rpm Linuxarm64SHA-256 ea0c098d0829720b6e364d2f2a91328876962c7f0ae94eee7bdcde0bd43313fa
pig-0.9.0-1.x86_64.rpm Linuxamd64SHA-256 707f4e1fde76d3faa05165ac11e97969c22a8740c97ef84da52727d0328990cc
pig-v0.9.0.darwin-amd64.tar.gz macOSamd64SHA-256 56aeb61674ddfb64368e6f5535e06a38b76f62e3d6c9536a63be7df6babed93e
pig-v0.9.0.darwin-arm64.tar.gz macOSarm64SHA-256 a213d16817d6124ffa83d93ad880a040598b6ed3fe23a74d43420c095ed43de4
pig-v0.9.0.linux-amd64.tar.gz Linuxamd64SHA-256 6a1a1836217fa723ca42bc2276ecf1453cd2ee0acacddfc313164701b24a452f
pig-v0.9.0.linux-arm64.tar.gz Linuxarm64SHA-256 5e5728aa5922138c61c900a731f97cdc1b9653c14d7fe804b6753fb6f222b8b0
pig_0.9.0-1_amd64.deb Linuxamd64SHA-256 e80d2cb3ceb5fd58fc0262ab4b39b44e8dcccb7712151c73a41ba50cb510353b
pig_0.9.0-1_arm64.deb Linuxarm64SHA-256 ecb504efffde8d696b765579332fc0b3304751fa8077c4c0394e7f3c44aa0fe2

v0.9.0 ·

3.22 - pig v0.8.1

将 llvmjit 恢复到 pgsql-full 别名

修复

  • 将 v0.8.0 中移除的 llvmjit 恢复到 pgsql-full 软件包别名。
  • 将发布版本更新为 v0.8.1。

校验和

文件校验和
pig-0.8.1-1.aarch64.rpm Linuxarm64SHA-256 fd9291b15953e8e5f579de7e0256b88ca742e11fc0ed578bf181d2ce4cf5258c
pig-0.8.1-1.x86_64.rpm Linuxamd64SHA-256 c2ec07d18eeae6ad831950da44d6bb797fad3ca4d0b1f7b0e82d715a22baedec
pig-v0.8.1.darwin-amd64.tar.gz macOSamd64SHA-256 b07017d257089166377fb4deffe167c952ae1dcacb6203de26a11a89097dfc34
pig-v0.8.1.darwin-arm64.tar.gz macOSarm64SHA-256 090889ba1447693e3ace0b18222f6852448738fc4baa4964a27acc87ce560501
pig-v0.8.1.linux-amd64.tar.gz Linuxamd64SHA-256 64cfd28d98c41776c83949b2ffb3b789c66835ccb522a346ea1b53966e9f9544
pig-v0.8.1.linux-arm64.tar.gz Linuxarm64SHA-256 6216612ab63c2c9006466834222bdbdcd9e7e8e112c52a6f17e26d0ebb24fbe4
pig_0.8.1-1_amd64.deb Linuxamd64SHA-256 29a2109af6141fa990144f0ebcf3bbbe13030c75af6fb3c6bf89eb8da956d387
pig_0.8.1-1_arm64.deb Linuxarm64SHA-256 7d8728658c942e57df259acd1da0d2655d9132ab7bffcc109527ed184784f882

v0.8.1 ·

3.23 - pig v0.8.0

440 extensions，移除 sysupdate 仓库

扩展更新

  • 扩展总数达到 440 个
  • 新增扩展：pg_ai_query 0.1.1
  • 新增扩展：pg_textsearch 0.1.0
  • 新增扩展：pg_clickhouse 0.1.0
  • pg_biscuit 从 1.0 升级至 2.0.1（切换至新仓库，更名为 biscuit）
  • pg_search 从 0.20.3 升级至 0.20.5
  • pg_duckdb 升级至官方正式版 1.1.1
  • vchord_bm25 从 0.2.2 升级至 0.3.0
  • pg_semver 从 0.40.0 升级至 0.41.0
  • pg_timeseries 从 0.1.7 升级至 0.1.8
  • 修复 debian/ubuntu pg18 扩展问题：supautils、pg_summarize、pg_vectorize、pg_tiktoken、pg_tzf、pglite_fusion、pgsmcrypto、pgx_ulid、plprql
  • pigsty 版本号同步至 4.0.0

仓库更新

  • 因上游变更移除 pgdg yum sysupdate 仓库
  • 因上游变更移除 pgdg yum llvmjit 软件包
  • 修复 el9.aarch64 上 patroni 3.0.4 重复软件包问题
  • 为 el 仓库定义添加优先级，docker 仓库不可用时自动跳过
  • 添加 epel 10 / pgdg 9/10 操作系统小版本热修复

校验和

文件校验和
pig-0.8.0-1.aarch64.rpm Linuxarm64SHA-256 e457832fb290e2f9975bf719966dc36e650bdcbf8505d319c9e0431f4c03bc9e
pig-0.8.0-1.x86_64.rpm Linuxamd64SHA-256 c97b1bfdd7541f0f464cab0ecc273e65535c8dd2603c38d5cf8dccbf7e95b523
pig-v0.8.0.darwin-amd64.tar.gz macOSamd64SHA-256 d892f06d3d3b440671529f40e6cc7949686e0167e2a4758adc666b8a3d75254d
pig-v0.8.0.darwin-arm64.tar.gz macOSarm64SHA-256 222413bafdf5a62dc682dac32ea1118cbc34ec3544e2a1b85076ec450b9cc7ae
pig-v0.8.0.linux-amd64.tar.gz Linuxamd64SHA-256 d50aa9806bbab8fee5ad9228e104fc9e7ead48729228116b5bf889000791fedc
pig-v0.8.0.linux-arm64.tar.gz Linuxarm64SHA-256 d2f410f7b243a8323c8d479f462a0267ac72d217aa4a506c80b5a9927d12dff8
pig_0.8.0-1_amd64.deb Linuxamd64SHA-256 4ccd330a995911d4f732e8c9d62aa0db479c21c9596f64c4bc129ec43f156abe
pig_0.8.0-1_arm64.deb Linuxarm64SHA-256 5cb9eccce659110f3ba58e502575564bd6befffd51992a43d84df5a17f8eb8a0

v0.8.0 ·

3.24 - pig v0.7.5

常规扩展更新，使用修复后的阿里云镜像

扩展更新

  • timescaledb 2.23.1 -> 2.24.0
  • pg_search 0.20.0 -> 0.20.3
  • convert 0.0.4 -> 0.0.5
  • pglinter 1.0.0 -> 1.0.1
  • pgdd 0.6.0 -> 0.6.1
  • pg_session_jwt 0.3.3 -> 0.4.0
  • pg_anon 2.4.1 -> 2.5.1
  • pg_enigma 0.4.0 -> 0.5.0
  • wrappers 0.5.6 -> 0.5.7
  • pg_vectorize 0.25.0 -> 0.26.0

仓库更新

使用修复后的阿里云 PGDG 镜像仓库

校验和

文件校验和
pig-0.7.5-1.aarch64.rpm Linuxarm64SHA-256 9de11ac1404fc4100074113f2a5d50e4ec42c353b6e122a0b29edc17e53feca6
pig-0.7.5-1.x86_64.rpm Linuxamd64SHA-256 071d655580f1cc63b33d41a8fb49368556b7b5a276318f4bd772a6ab50e22b34
pig-v0.7.5.darwin-amd64.tar.gz macOSamd64SHA-256 befe0a8f786e5243669ed7219acde8156d13d9adb0a5c2fb88ccf0f614a51f9b
pig-v0.7.5.darwin-arm64.tar.gz macOSarm64SHA-256 4766b4e9ba390a32a7115e9f2dd6b65cf158439e28f9c099bab5c7f2e588bae2
pig-v0.7.5.linux-amd64.tar.gz Linuxamd64SHA-256 dc45726c5e7fccd502cacaffc94c659570844151cdc279f2cac6500836071ade
pig-v0.7.5.linux-arm64.tar.gz Linuxarm64SHA-256 1483cf967d4bc9c12d4c6724567644d6b88fcd2a93aaf1d317fc6ad4e1672c13
pig_0.7.5-1_amd64.deb Linuxamd64SHA-256 0152b7bd254eccadd640e563845abd9fa62efa68f11c6b67a5f9f0eebfa2d92e
pig_0.7.5-1_arm64.deb Linuxarm64SHA-256 7d22116d26ca09c5e2b8afbf086bb1acb1aea1148905efcc38944c18908fb105

v0.7.5 ·

3.25 - pig v0.7.4

更新 ivory/pgtde 内核与 pgdg extras 仓库
  • 更新扩展版本与元数据：pg_search，pgmq，pg_stat_monitor
  • 更新 PGDG 仓库 URL 变化，extras 仓库现在位于 yum 仓库顶层
  • 将 ivorysql 更新至 5.0 版本，与 PG 18 兼容
  • 将 Percona Postgres TDE 内核更新至 18.1

Checksums

文件校验和
pig-0.7.4-1.aarch64.rpm Linuxarm64SHA-256 5769b0051f04dcda22dd92b30b8effc8ddfa40097308bded76ce2b38d012ce57
pig-0.7.4-1.x86_64.rpm Linuxamd64SHA-256 d15c829fa2e3ce8dcd1adc063c107607b8e70f2cf747646aaa2fa257cdbf979c
pig-v0.7.4.darwin-amd64.tar.gz macOSamd64SHA-256 bb4c90e253a3d470e50316e633a41e90ed2d4a5c5a1fd3a8dbb68ee87d831d47
pig-v0.7.4.darwin-arm64.tar.gz macOSarm64SHA-256 faaf7ac7b08390f5048c081bb7a78100714387e35dc890e26d9746fc1caef415
pig-v0.7.4.linux-amd64.tar.gz Linuxamd64SHA-256 037cacddd0dc1283f13dd2c9bace87ad7f2c74ffc245e629f1420be94bbf93df
pig-v0.7.4.linux-arm64.tar.gz Linuxarm64SHA-256 2ce819b2c3686cfb9f86790fdf61acd30bf7798bd6cd3c4f589df22e273dc867
pig_0.7.4-1_amd64.deb Linuxamd64SHA-256 97f62d62f1cca61ce6d335efed88e3855d94ea2cd4ed941f2755fbac73931fcd
pig_0.7.4-1_arm64.deb Linuxarm64SHA-256 d2b80af89ed42601716f6b41eda3f8bee16db34023527df9deef8a43aa25a498

v0.7.4 ·

3.26 - pig v0.7.3

修复 el10 & debian13 仓库配置
  • 新增 pig repo reload 命令，更新仓库元数据
  • 修复 EL PGDG sysupdate aarch64 仓库问题。
  • 修复 EL10.aarch64 PGDG 仓库重命名问题。
  • 订正了若干扩展版本
  • 更新 Pigsty 版本至 3.7.0

校验和

文件校验和
pig-0.7.3-1.aarch64.rpm Linuxarm64SHA-256 786d72f6b685d6d6abf5f255f0a7de9204988a05630a26a53bfc7631823c0c6f
pig-0.7.3-1.x86_64.rpm Linuxamd64SHA-256 da59e24ef79d1164e348bacc43e3222e8e2778ec0e103e7ffc0c6df064758e8f
pig-v0.7.3.darwin-amd64.tar.gz macOSamd64SHA-256 73062a979749095e89abc07dd583d34d4f57908bb4ee935cf7640f129ca6a2cb
pig-v0.7.3.darwin-arm64.tar.gz macOSarm64SHA-256 ca5f5576f6d0d9be1d10cad769821be9daa62220b2fb56b94d6e4c0cede6da61
pig-v0.7.3.linux-amd64.tar.gz Linuxamd64SHA-256 d193b4b87cf9a6e4775b1b07709802d30f0233ccb1b728843a09decb545168d3
pig-v0.7.3.linux-arm64.tar.gz Linuxarm64SHA-256 e7f612df0e8e4d9fac6df3765862b9e491bb50aad651856abf7a6935986e6f99
pig_0.7.3-1_amd64.deb Linuxamd64SHA-256 3d5306ce95dcf704dd498b05325d942637564b13115f1e5a5bb9ef6781df1ba6
pig_0.7.3-1_arm64.deb Linuxarm64SHA-256 32e695ba2d49a741d8cd92008f8f2dec29f10754d35b732035f48517b382c30d

v0.7.3 ·

3.27 - pig v0.7.2

437 个扩展，修复 pig build 的一些问题

  • 批量更新扩展，数量达到 437 个

  • 新增 PGDG EL10 Sysupdate 仓库

  • 新增 LLVM APT 仓库

  • 在 pig build 命令中使用可选的本地 extension.csv 扩展定义问题。

  • 更新的扩展： vchord pg_later pgvectorscale pglite_fusion pgx_ulid pg_search citus timescaledb pg_profile pg_stat_monitor documentdb

  • 新增的扩展：pglinter pg_typeid pg_enigma pg_retry pg_biscuit pg_weighted_statistics

校验和

文件校验和
pig-0.7.2-1.aarch64.rpm Linuxarm64SHA-256 f303c391fc28bc74832712e0aa58319abe0ebcae4f6c07fdf9a9e542b735d2ec
pig-0.7.2-1.x86_64.rpm Linuxamd64SHA-256 c096a61a4e3a49b1238659664bbe2cd7f29954c43fb6bb8e8e9fb271f95a612e
pig-v0.7.2.darwin-amd64.tar.gz macOSamd64SHA-256 5e037c891dff23b46856485108d6f64bede5216dfbd4f38a481f0d0672ee910b
pig-v0.7.2.darwin-arm64.tar.gz macOSarm64SHA-256 736b4b47999c543c3c886781f4d8dddbf4276f363c35c7bf50094b6f18d14600
pig-v0.7.2.linux-amd64.tar.gz Linuxamd64SHA-256 20b13f059efed29dd76f6927b3e8d7b597c0c8d734f9e22ba3d0a2af6dbcd3bf
pig-v0.7.2.linux-arm64.tar.gz Linuxarm64SHA-256 9548b530c05f2ffdc8d73b8f890718d47b74a51eb62852a99c08b1b52e47f014
pig_0.7.2-1_amd64.deb Linuxamd64SHA-256 b6faad9f92b926546a10f590274f2cb2afff21b9cea878094cfc5caf09e67d2c
pig_0.7.2-1_arm64.deb Linuxarm64SHA-256 452f73f1fa035e5417ab49fc51d797925550179ffcc023e8f03d80144309212a

v0.7.2 ·

3.28 - pig v0.7.1

新网站，改进容器内的使用体验
  • 全新的网站： /ext/
  • 修复了不必要的 sudo 使用问题，现在可以方便的在容器中使用
  • 允许 pig ext link 命令使用形如 pg17 pg18 的参数形式
  • 新增环境变量 PIG_NO_SUDO，强制不使用 sudo 执行命令
  • RPM 变更日志：为几乎所有扩展新增 PG 18 支持
  • DEB 变更日志：为几乎所有扩展新增 PG 18 支持
  • Infra 变更日志：例行更新至最新版本

校验和

文件校验和
pig-0.7.1-1.aarch64.rpm Linuxarm64SHA-256 a696c9ec784e2fc248e5f3d87cc8aae4116e890f78c5997957d30593f2c85ca6
pig-0.7.1-1.x86_64.rpm Linuxamd64SHA-256 f669538a99cd1dc592d3005b949628fcceb9e78114fc78862d7726b340ee194d
pig-v0.7.1.darwin-amd64.tar.gz macOSamd64SHA-256 e42bdaaf93b720c5b76b32b57362320e4b447109740c76089aefe030b7c8b836
pig-v0.7.1.darwin-arm64.tar.gz macOSarm64SHA-256 b4c240aadad34e785666ee0a755d9b7455724f790c2d088a1dd7c37ad3b2a457
pig-v0.7.1.linux-amd64.tar.gz Linuxamd64SHA-256 ffc687add0ca71ac90cba5749c8a7a6075cf7618cba85584072831cf3eb182f7
pig-v0.7.1.linux-arm64.tar.gz Linuxarm64SHA-256 7b0d1f158150d0a40c525692f02b6bce9f5b4ac523a4e59278d702c334e222e1
pig_0.7.1-1_amd64.deb Linuxamd64SHA-256 43e91a3bea273d7cacb2d7a58c0a5745501dbd06348b5cb3af971171fae70268
pig_0.7.1-1_arm64.deb Linuxarm64SHA-256 fc2a34aeb46e07cb0ae93611de47d6622c3bd46fe4c415ce4c9091840e0e08a2

v0.7.1 ·

3.29 - pig v0.7.0

强化 build 能力，大批量包更新
  • 提供针对 Debian 13 和 EL 10 发行版的支持
  • 大批量扩展更新至最新版本，带有 PostgreSQL 18 支持。
  • 几乎所有 Rust 扩展现已通过 pgrx 0.16.1 支持 PG 18
  • pig build 命令彻底重做
    • pig build pkg <pkg> 现在会一条龙完成扩展的下载，依赖安装，构建
    • pig build pgrx 命令现在从 pig build rust 中分离
    • pig build pgrx [-v pgrx_version] 现在可以直接使用现有的 PG 安装
    • pig build dep 现在会处理 EL 和 Debian 系统下的扩展依赖
    • pig build ext 命令现在有了更为紧凑和美观的输出，可在 EL 下不依赖 build 脚本直接构建 RPM
    • pig build spec 现在支持直接从 Pigsty 仓库下载 spec 文件包
    • pig build repo / pig repo add / pig repo set 现在默认使用 node,pgsql,infra 仓库模块，取代原本的 node,pgdg,pigsty
  • 大量优化了错误日志记录。
  • 基于 hugo 与 hextra 全新目录网站

校验和

文件校验和
pig_0.7.0-1_amd64.deb Linuxamd64MD5 ad60f9abcde954769e46eb23de61965e
pig_0.7.0-1_arm64.deb Linuxarm64MD5 aa15d7088d561528e38b2778fe8f7cf9
pig-0.7.0-1.aarch64.rpm Linuxarm64MD5 05549fe01008e04f8d5a59d4f2a5f0b8
pig-0.7.0-1.x86_64.rpm Linuxamd64MD5 0cc9e46c7c72d43c127a6ad115873b67
pig-v0.7.0.darwin-amd64.tar.gz macOSamd64MD5 ddacfb052f3f3e5567a02e92fdb31cdd
pig-v0.7.0.darwin-arm64.tar.gz macOSarm64MD5 17d25b565308d3d35513e4b0d824946b
pig-v0.7.0.linux-amd64.tar.gz Linuxamd64MD5 ee7e055ceff638039956765fb747f80b
pig-v0.7.0.linux-arm64.tar.gz Linuxarm64MD5 284e674807b87447d4b33691fd7a420d

v0.7.0 ·

3.30 - pig v0.6.2

正式提供 PG 18 支持
  • 使用 PG 18 官方正式仓库取代原本的 Testing Beta 仓库 instead of testing repo
  • 在接收 Pigsty 版本字符串的时候，自动添加 v 前缀
  • 改进了网络检查与下载的逻辑

校验和

文件校验和
pig_0.6.2-1_amd64.deb Linuxamd64MD5 01f5b7dc20644226c762dbb229768347
pig_0.6.2-1_arm64.deb Linuxarm64MD5 ce4f00256adc12cbea91467b7f2241cd
pig-0.6.2-1.aarch64.rpm Linuxarm64MD5 cefc36ae8f348aede533b30836fba720
pig-0.6.2-1.x86_64.rpm Linuxamd64MD5 d04a287c6eb92b11ecbf99542c2db602
pig-v0.6.2.darwin-amd64.tar.gz macOSamd64MD5 e637ca86a7f38866c67686b060223d9a
pig-v0.6.2.darwin-arm64.tar.gz macOSarm64MD5 79749bc69c683586bd8d761bdf6af98e
pig-v0.6.2.linux-amd64.tar.gz Linuxamd64MD5 ad4f02993c7d7d8eec142f0224551bb4
pig-v0.6.2.linux-arm64.tar.gz Linuxarm64MD5 9793affa4a0cb60e9753e65b7cba3dca

v0.6.2 ·

3.31 - pig v0.6.1

CI/CD, el10 存根，PGDG 中国镜像
  • 新增 el10 与 debian 13 trixie 的支持存根
  • 专门的新文档网站： /ext/pig/
  • 使用 go 1.25 重新构建，新增 CI/CD 管道
  • 在中国大陆使用 PIGSTY PGDG 镜像
  • 移除空的 pgdg-el10fix 仓库
  • 使用 Pigsty Babelfish 镜像
  • 修复 EL 10 专用的 EPEL 仓库
  • pig version 输出构建环境信息

v0.6.1 ·

3.32 - pig v0.6.0

423 个扩展，percona pg_tde，mcp 工具箱
  • 新扩展目录：https://ext.pgsty.com
  • 新子命令：pig install 简化 pig ext install
  • 添加新内核支持：带 pg_tde 的 percona
  • 添加新包：Google GenAI MCP 数据库工具箱
  • 添加新仓库：percona 仓库和 clickhouse 仓库
  • 将扩展摘要信息链接更改为 ext.pgsty.com
  • 修复 orioledb 在 Debian/Ubuntu 系统上的问题
  • 修复 EL 发行版上的 epel 仓库
  • 将 golang 升级到 1.24.5
  • 将 pigsty 升级到 v3.6.0

校验和

文件校验和
pig_0.6.0-1_amd64.deb Linuxamd64MD5 1804766d235b9267701a08f95903bc3b
pig_0.6.0-1_arm64.deb Linuxarm64MD5 35f4efa35c1eaecdd12aa680d29eadcb
pig-0.6.0-1.aarch64.rpm Linuxarm64MD5 b523b54d9f2d7dcc5999bcc6bd046b1d
pig-0.6.0-1.x86_64.rpm Linuxamd64MD5 9434d9dca7fd9725ea574c5fae1a7f52
pig-v0.6.0.linux-amd64.tar.gz Linuxamd64MD5 f635c12d9ad46a779aa7174552977d11
pig-v0.6.0.linux-arm64.tar.gz Linuxarm64MD5 165af4e63ec0031d303fe8b6c35c5732

v0.6.0 ·

3.33 - pig v0.5.0

422 个扩展，新的扩展目录
  • 将扩展列表更新至 422 个
  • 新扩展：来自 AWS 的 pgactive
  • 将 timescaledb 升级到 2.20.3
  • 将 citus 升级到 13.1.0
  • 将 vchord 升级到 0.4.3
  • 修复错误：pgvectorscale debian/ubuntu pg17 失败
  • 将 kubernetes 仓库升级到 1.33
  • 将默认 pigsty 版本升级到 3.5.0

校验和

文件校验和
pig_0.5.0-1_amd64.deb Linuxamd64MD5 9ec6f3caf3edbe867caab5de0e0ccb33
pig_0.5.0-1_arm64.deb Linuxarm64MD5 4fbb0a42cd8a88bce50b3c9d85745d77
pig-0.5.0-1.aarch64.rpm Linuxarm64MD5 9cf8208396b068cab438f72c90d39efe
pig-0.5.0-1.x86_64.rpm Linuxamd64MD5 d9a8d78c30f45e098b29c3d16471aa8d
pig-v0.5.0.linux-amd64.tar.gz Linuxamd64MD5 761df804ff7b83965c41492700717674
pig-v0.5.0.linux-arm64.tar.gz Linuxarm64MD5 5d1830069d98030728f08835f883ea39

v0.5.0 ·

3.34 - pig v0.4.2

421 个扩展，halo 和 oriole deb
  • 将扩展列表更新至 421 个
  • 为 Debian / Ubuntu 添加 openhalo/orioledb 支持
  • pgdd 0.6.0 (pgrx 0.14.1)
  • convert 0.0.4 (pgrx 0.14.1)
  • pg_idkit 0.3.0 (pgrx 0.14.1)
  • pg_tokenizer.rs 0.1.0 (pgrx 0.13.1)
  • pg_render 0.1.2 (pgrx 0.12.8)
  • pgx_ulid 0.2.0 (pgrx 0.12.7)
  • pg_ivm 1.11.0 适用于 debian/ubuntu
  • orioledb 1.4.0 beta11
  • 重新添加 el7 仓库

校验和

文件校验和
pig_0.4.2-1_amd64.deb Linuxamd64MD5 bbf83fa3e3ec9a4dca82eeed921ae90a
pig_0.4.2-1_arm64.deb Linuxarm64MD5 e45753335faf80a70d4f2ef1d3100d72
pig-0.4.2-1.aarch64.rpm Linuxarm64MD5 966d60bbc2025ba9cc53393011605f9f
pig-0.4.2-1.x86_64.rpm Linuxamd64MD5 1f31f54da144f10039fa026b7b6e75ad
pig-v0.4.2.linux-amd64.tar.gz Linuxamd64MD5 1eec26c4e69b40921e209bcaa4fe257a
pig-v0.4.2.linux-arm64.tar.gz Linuxarm64MD5 768d43441917a3625c462ce9f2b9d4ef

v0.4.2 ·

3.35 - pig v0.4.1

414 个扩展，pg18 别名支持
  • 将扩展列表更新至 414 个
  • 在 pig ext scan 映射中添加 citus_wal2json 和 citus_pgoutput
  • 添加 PG 18 beta 仓库
  • 添加 PG 18 包别名

v0.4.1 ·

3.36 - pig v0.4.0

do 和 pt 子命令，halo 和 orioledb
  • 更新扩展列表，可用扩展达到 407 个
  • 添加 pig do 子命令用于执行 Pigsty playbook 任务
  • 添加 pig pt 子命令用于包装 Patroni 命令行工具
  • 添加扩展别名：openhalo 和 orioledb
  • 添加 gitlab-ce / gitlab-ee 仓库区分
  • 使用最新 Go 1.24.2 构建并升级依赖项版本
  • 修复特定条件下 pig ext status 的 panic 问题
  • 修复 pig ext scan 无法匹配多个扩展的问题

v0.4.0 ·

3.37 - pig v0.3.4

常规更新
curl https://repo.pigsty.io/pig | bash -s 0.3.4
  • 常规扩展元数据更新
  • 使用阿里云 epel 镜像代替损坏的清华大学 tuna 镜像
  • 升级 pigsty 版本字符串
  • 在仓库列表中添加 gitlab 仓库

v0.3.4 ·

3.38 - pig v0.3.3

别名、仓库、依赖
  • 添加 pig build dep 命令安装扩展构建依赖项
  • 更新默认仓库列表
  • 为 mssql 模块（babelfish）使用 pigsty.io 镜像
  • 将 docker 模块合并到 infra
  • 从 el7 目标中移除 pg16/17
  • 允许在 el7 中安装扩展
  • 更新包别名

v0.3.3 ·

3.39 - pig v0.3.2

新扩展

增强功能

  • 新扩展
  • 使用 upx 减少二进制大小
  • 移除嵌入的 pigsty 以减少二进制大小

v0.3.2 ·

3.40 - pig v0.3.1

轻微错误修复

常规错误修复

  • 修复仓库格式字符串
  • 修复扩展信息链接
  • 更新 pg_mooncake 元数据

v0.3.1 ·

3.41 - pig v0.3.0

新主页和扩展目录

pig 项目现在有了新的 主页，以及 PostgreSQL 扩展 目录。

v0.3.0 ·

3.42 - pig v0.2.2

404 个扩展

Pig v0.2.2 中提供 404 个扩展

v0.2.2 ·

3.43 - pig v0.2.0

400 个扩展

v0.2.0 ·

3.44 - pig v0.1.4

常规错误修复

v0.1.4 ·

3.45 - pig v0.1.3

390 个扩展

v0.1.3，常规更新，现在可用 390 个扩展！

v0.1.3 ·

3.46 - pig v0.1.2

anon 扩展和其他 350 个扩展

351 个 PostgreSQL 扩展，包括强大的 postgresql-anonymizer 2.0

v0.1.2 ·

3.47 - pig v0.1.1

更新扩展列表

更新扩展列表。

v0.1.1 ·

3.48 - pig v0.1.0

repo、ext、sty 和自更新

pig CLI v0.1 发布

v0.1.0 ·

3.49 - pig v0.0.1

创世发布

创世发布

v0.0.1 ·