跳转到主要内容

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

返回本页常规视图.

PIG 博客

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

PIG 的文章、设计注记与发布历史。PIG 是 Pigsty 提供的 PostgreSQL 命令行工具， 用于管理软件仓库、扩展、数据库实例与 Pigsty 环境。

1 - 文章

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

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

文章按发表时的背景保留，文中的版本、数量与示例反映当时状态。 现在使用 PIG，请查阅操作文档、扩展目录与发布注记。

建议按以下线索阅读：

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

SOW 如何通过共享包存储、快照与增量发布，管理十万级仓库制品。

今天老冯来和大家聊一聊《母猪的产后护理》。俺做的新开源项目 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 是一个自包含二进制，在 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 自己的解析器校验。替换公开文件前，SOW 再比较软件包列表与 stat 快照，检查构建期间的文件变化；这一步不再重新读取每个包来计算哈希。

SOW Plain 平面仓库文档

Plain 不保存操作日志。各个文件分别替换，中断后可能留下不完整的索引。重新执行同一条 sow create，即可从包目录重建索引。为在线服务准备仓库时，先在独立目录中构建，成功后再切换服务目录。

--pigsty 模式会删除 DEB i386 包与 Patroni 3.0.4 包，再将保留软件包的 SHA-256 写入 repo_complete。SOW 在修改公开文件前移除旧标记，最后写入新标记。采用这项约定的消费方，应等标记出现后再使用仓库。

这套模式解决了 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 会保留上一个完整的 Generation，并记录中断的操作。恢复时可以确定哪些工作尚未完成，以及应该回滚还是继续。

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

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

传输清单来自两个已知 Generation 的比较。SOW 仍会检查本地文件树与远端对象清单，但可以跳过未变化对象的传输。

SOW 的 Plain 与 Managed 能力矩阵

发布顺序：先放对象，最后切换指针

SOW 按固定顺序发布仓库对象：

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

先放入不可变包体，再写以校验和命名的元数据与 by-hash 索引，最后更新 repomd.xml、Release / InRelease 这些客户端入口。只有保留的 Generation 和发布目标都不再需要旧对象，并且保留期已经结束，垃圾回收才能删除它。

这个顺序让新指针引用的不可变对象先就位。整个仓库并非一次原子切换：不同视图、APT 固定路径索引与分离签名分别更新。客户端在切换期间仍可能需要重试。

在本地 POSIX 文件系统上，这套过程依赖同盘 staging、fsync、原子 rename、稳定路径锁和持久操作日志。每条 Managed 写命令都会先检查并恢复上一次未完成操作，再开始自己的工作。恢复只根据已经落盘的证据判断该回滚还是前滚；记录相互矛盾时，SOW 停止操作，不猜测修复方式。

对象存储不支持跨多个 Key 的原子提交，SOW 就先持久化 commit intent，再按确定顺序前滚协议指针，并为每个 target 单独保存 Applied Checkpoint。当前文件系统与 R2 发布各有自己的证据，前者成功绝不会被误认为后者也成功。SOW 0.3 的 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 个对象现在可在 一秒内 完成，而旧实现在该基准中未能完成。基准背景见 v0.3.0 发布说明。载荷提升也改成了有界单写入者组提交，每批最多 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 安装包；最新版本可以从 下载页获取，也可以直接查看 源代码。

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

原文：vonng.com。

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 如果在打开临时 RDB 文件或重命名文件时失败，实例记录的 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 在 Redis 5:6.0.8-2 中将堆内存的 zfree(cwdp) 改为 libc free(cwdp)，并修正了另一处错误释放栈指针的问题。

后来，Debian 从 Redis 的打包体系中派生出了 Valkey 打包，这份补丁也跟着迁了过去。2024 年 10 月，一次修复泄漏的改动又加入了 zfree(cwdp)，并首次随 Debian Valkey 8.0.2+dfsg1-1 发布；8.0.1+dfsg1-1 不受影响。同一个错误，沿着同一条补丁血脉，四年后重新出现。

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

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

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 架构组合起来，做了一轮交叉构建与复现。在内置 jemalloc 的对照构建中，原始上游源码的 unit/shutdown 用例全部通过；应用错误补丁后有三个用例触发崩溃；改正释放函数后，这组用例再次全部通过。

问题在于，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 打包补丁，重新构建并运行测试。unit/shutdown 测试通过，普通路径仍会出现在错误日志中；路径超过栈缓冲区时，上游会打印 unknown。错误释放也随着补丁一起消失了。

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

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

截至本文发布的 8 月 9 日，Debian 报告 #1143239 还没有收到维护者回复。调查还发现 bookworm 的 Redis 5:7.0.15-1~deb12u7 包存在同样缺陷；我已在 Valkey 报告中说明，但当时尚未单独提交报告。

但写到这里，这篇文章真正想讲的已经不只是 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 里程碑：不会放弃的机器》

原文：vonng.com。

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

pig v1.5 新增 pig pg clone 与 pig pg fork，在命令行中提供 PostgreSQL 18 数据库克隆与实例分支。

老冯在半年前（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 用起来会非常方便。因为它可以很轻松地用探索式方式，拿到所需的结构化帮助信息。pg clone 与 pg fork 都提供结构化结果。

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 工作流

参考阅读

原文：vonng.com。

1.4 - 什么是 PostgreSQL 发行版？

PostgreSQL 发行版如何组合数据库内核、扩展软件包与运维工具。

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

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

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

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

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

区别很简单：Linux 项目开发内核，发行版围绕内核组装操作系统。

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

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

Linux 内核与发行版组成关系

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

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

共享内核提供了共同基础，发行版通过集成、发布与持续维护，把它变成可用的系统。

这正是理解 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-II 做主从切换。监控可以是 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 发行版的基础设施层次

编排与管控仍然需要大量集成工作。Kubernetes、Patroni、Ansible 提供了公共组件，但每个发行版仍要把它们连接成完整的操作流程。

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

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

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

以下 GitHub Star 数量统计于 2026 年 7 月 4 日。

赛道一：Kubernetes（云原生）

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

这是 最拥挤、也最热闹 的赛道，玩家云集：CloudNativePG（EDB 主导，约 8900 Star）、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 工具发起管理。

Linux 原生开源项目包括：Pigsty（约 5200 Star）、Autobase（约 4300 Star）、pgEdge（约 700 Star）、EDB TPA（约 90 Star）。Percona Distribution for PostgreSQL 也是开源软件栈，并提供商业支持。商业产品则包括 EDB Postgres Advanced Server、CYBERTEC PGEE 和 ClusterControl 管理平台。

这条路的优点是基础设施层次更少，可以直接使用熟悉的 Linux 工具。DBA 能直接检查进程、文件和服务。它的代价则是：没有 K8s 替你处理状态收敛、幂等执行、故障恢复、升级编排，你得自己想办法实现，还要直面十几种主流发行版大版本之间的差异 —— 这是一份持续的、并不性感的苦役。

Pigsty 的选择

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

在这里列出的项目中，Pigsty 的 GitHub Star 数量位居 Linux 原生项目之首，总体位列第二，仅次于 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 构建了二进制包并提供配置模板，让用户在同一套底座上运行不同内核，写作时已提供十余种内核与应用栈配置。

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

Pigsty 提供的 PostgreSQL 分支内核

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

以下示例使用 2026 年 7 月的 Pigsty 配置布局：

./configure                     # 默认使用 meta.yml 配置模板
./configure -c meta             # 显式指定使用 meta.yml 单节点模板
./configure -c rich             # 使用包含大部分可用扩展与 MinIO 的 rich 模板
./configure -c slim             # 使用最小化的单节点 PostgreSQL/Patroni 模板，不含监控

# 使用不同的数据库内核
./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 节点模板，etcd 为单节点
./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 世界里长出的，正是这样一份信任 —— 并且让它是开放的、可审计的、可以自己接管的。

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

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

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

原文：vonng.com。

1.5 - 人人可用的 PG 扩展

从 1,617 个 PostgreSQL 扩展项目、511 个已打包扩展出发，讨论如何把扩展交付给用户。

在线幻灯片：人人都能用上的 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 上的项目，比如 PostgreSQL 和 PostGIS。

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

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

06. GitHub 星标

7. 星标分层

07. 星标分层

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

我把四个广为人知的扩展放在第零层：PostGIS、TimescaleDB、pgvector、Citus。其余层级按 GitHub 星标数划分。

第一层：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 编写，以单个可执行文件分发。这个名字的含义是「piggyback on the OS package manager」，也就是借力系统包管理器。它将扩展名解析为所选 PostgreSQL 版本与平台对应的软件包。

有意思的是，它不只是能安装，也能构建和交付二进制包。配置好构建环境后，运行 pig build pkg pg_search 即可构建 pg_search，也可以选择 pg_duckdb 等其他支持的扩展。

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

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

20. CLI：PIG

第四部分：野外维护

21. 扩展矩阵

21. 扩展矩阵

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

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

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

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

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

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

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

21. 扩展矩阵

22. PG 小版本 ABI 破坏

22. PG 小版本 ABI 破坏

2024 年 11 月，我们遇到过一个案例。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. 致谢

原文：vonng.com。

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

一次 RDKit 打包需求如何带来 32 个新增扩展，将目录扩展到 504 项。

一个 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

目录收录了 PostgreSQL 自带扩展，以及 PGDG 与 Pigsty 提供的软件包。仓库之间有重叠，同一个扩展可能由多个来源提供。 基本上，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. onesparse: 在 SQL 里跑十亿边级图算法

onesparse | 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 基准测试 包含最多 43 亿条边 的图，部分输入上的 BFS 吞吐量超过 每秒 70 亿条边。应用场景包括交易网络反欺诈、社交网络分析与 Graph RAG。先用有代表性的小图验证数据装载、序列化和查询规划，再扩大规模。

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 公司开发，于 2026 年 2 月 13 日公布，作者是 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 开发，通过 post_parse_analyze_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 新增的 @@> 操作符支持用 LIKE 模式匹配数组元素，底层基于 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。

总结

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

第一，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 基金会项目），也有集市（个人开发者的周末项目），共同构建着世界上最先进的开源数据库。

原文：vonng.com。

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

我把 464 个 PostgreSQL 扩展的元数据、可用软件包、安装命令与使用说明，汇集成一本中英双语扩展百科。

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

扩展是 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 个 PG 大版本；中英双语；元数据、下载链接、安装命令、使用说明汇于一处。这件事的目标很简单：让 PostgreSQL 的扩展生态更容易被发现、更容易被安装，也更容易真正用起来。

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

原文：vonng.com。

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

第五版扩展目录将 464 个扩展的软件包元数据与使用文档放在一起。

今天老冯又让 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. Docsify
  3. Next.js
  4. 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 大象

原文：vonng.com。

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 诞生，1994 年 Red Hat 诞生。之后服务端操作系统内核很快就收敛到了 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 发行版

原文：vonng.com。

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 镜像站。 “躺平”“没有担当”这些情绪上的评价，最初更多是冲着阿里云这种有资源的大厂去的 —— 云计算泥石流 的保留节目。 毕竟阿里云作为互联网大厂和本土云计算一哥，从开源攫取了巨大价值，搞个开源镜像站却长期不维护 PG 仓库，实属拉垮。 结果在这次风波里，反而是清华 TUNA 的同学先站出来表达了不同看法，这一点我也理解。

长期未更新的阿里云 PostgreSQL 镜像目录

这里说一句公道话：不管是阿里云镜像站还是 TUNA 镜像站，我在原文里多次强调过 —— 作为免费的服务提供方，在法律和道德上确实没有义务去做这件“慈善”。 但这并不妨碍每个人对现实结果有自己的看法和评价。“躺平”“没有担当”是我当时的主观感受，现在回头看，用在高校志愿者身上，确实容易误伤人。 所以我已经把措辞调整为“停止维护”“长期未更新”这类事实性的表述，把情绪收回来，避免误伤一线维护的同学。

为什么老冯会有这种感觉呢？我在发现 全球镜像站出现同步问题 之后，第一时间就 给阿里云发邮件反馈了这个问题（当然阿里云现在还没修）。 同时，我也顺手看了一圈国内其他镜像站，发现清华 TUNA 镜像站也有这个问题，就在他们的邮件列表里发了一封提醒。 邮件里的链接已经改成了 TUNA 地址，但标签还写着“ALIYUN”。有同学因此回复：“本邮件列表是 TUNA 的邮件列表，与阿里云无关”。我纠正了标签，并解释这是多个镜像站共有的上游同步问题。直到这次 11 月的讨论前，没有收到进一步回复。

TUNA 邮件列表中的 PostgreSQL 镜像同步讨论

大概又等了一个月左右，老冯实在是不想等了，就自己搭建了 PGDG 中国区域的镜像仓库，放在腾讯云上，和 Pigsty 自己的仓库放一起。 移除了对阿里云 PostgreSQL 镜像站的上游依赖，至少在 PostgreSQL 制成品分发上，实现了完整的自主可控供应链。 老实说，如果不是因为国内镜像站在这件事上的整体表现，老冯可能也不会这么快去做这件事。

老冯嘴臭惯了，对云厂商说话一向不太客气，但这不意味着我不理解志愿者的难处 —— 尤其是对于高校开源志愿者，整体上我觉得应该多一点呵护，少一点道德化的指责，这也是我后来主动调整措辞的原因。

开源与信任

实际上老冯自己也刚刚经历过类似的事情。我也维护了几个开源项目，还有不少 PostgreSQL 生态里的工具。 比如说 pg_exporter —— PG 的 Prometheus 指标导出器，有一些 PG 厂商也在用。 11 月 20 日我才注意到，一位用户在 9 月提交的 Issue 中，于 10 月留下了这段话：

你好，虽然我知道这是一个开源项目，但我一个月前提交的两个问题至今仍未得到任何回应，这实在令人失望。 我对 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 配置。 当前地址与启用方式请参见 Pigsty 软件仓库文档。

PGDG 镜像

定期同步 PostgreSQL 全球开发组的软件仓库，覆盖 EL 7–10、Debian 11–13 和 Ubuntu 20.04–24.04。截至本文发表的 2025 年 11 月 22 日，仓库刚完成一次同步，当时每周更新。

PIGSTY PGSQL

这个仓库与 PGDG 配合使用，提供 PG 内核分支与兼容方案，包括 PolarDB、IvorySQL、Babelfish、OrioleDB、OpenHaloDB、Percona TDE 和 Supabase。 本文发表时，它提供 437 个 PG 扩展 和生态工具，覆盖 14 个 Linux 发行版大版本。

PGEXT.CLOUD 扩展目录与可用性统计

PIGSTY INFRA

提供数据库工具、Grafana、Prometheus 和各类 Exporter。下表保留 2025 年 11 月 22 日的软件包版本。

数据库与生态工具

软件包 版本
IvorySQL 4.6
etcd 3.6.6
minio 20250907161309
mcli 20250813083541
kafka 4.0.0
duckdb 1.4.2
ferretdb 2.7.0
tigerbeetle 0.16.60
juicefs 1.3.0
dblab 0.34.2
v2ray 5.28.0
pig 0.7.2
vip-manager 4.0.0
pev2 1.17.0
promscale 0.17.0
pgschema 1.4.2

Prometheus 与 Exporter

软件包 版本
prometheus 3.7.3
pushgateway 1.11.2
alertmanager 0.29.0
blackbox_exporter 0.27.0
VictoriaMetrics 1.129.1
VictoriaLogs 1.37.2
pg_exporter 1.0.3
pgbackrest_exporter 0.21.0
node_exporter 1.10.2
keepalived_exporter 1.7.0
nginx_exporter 1.5.1
zfs_exporter 3.8.1
mysqld_exporter 0.18.0
redis_exporter 1.80.0
kafka_exporter 1.9.0
mongodb_exporter 0.47.1

Grafana 与日志工具

软件包 版本
grafana 12.3.0
loki 3.1.1
promtail 3.0.0
vector 0.51.1
grafana-infinity-ds 3.6.0
grafana-vmlogs-ds 0.21.4
grafana-vmetrics-ds 0.19.6
grafana-plugins 12.0.0

实用工具

软件包 版本
sealos 5.1.1
rclone 1.71.2
restic 0.18.1
mtail 3.0.8
genai-toolbox 0.18.0
sqlcmd 1.8.0

原文：vonng.com。

1.11 - PG扩展云：解锁 PG 生态的全部潜力

收录 431 个 PostgreSQL 扩展的目录、原生 RPM/DEB 仓库，以及用于查找和安装软件包的 PIG 命令行工具。

微信公众号链接

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 扩展生态

原文：vonng.com。

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 发行版 × 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 几百个包在十几个系统发行版构建的人确实是凤毛麟角了。

懂打包的凤毛麟角

在现实实践中，老冯发现这个技能真的太稀缺了，就像尤里问我谁还懂这个，国内就甭说了，就算是全球，我知道的可能 ZomboDB 那个作者（pgrx 作者）懂这个（被 ParadeDB 挖走了），别的我还真想不出来有谁能做好这个事情了。

比如说，PG 生态中，这么多扩展，有能力直接在发布的时候提供主流 Linux RPM / DEB 包的，我知道的就只有 ParadeDB 一家（pg_search），而他们会做这个事是因为他们发版太频繁了，我实在懒得替他们打包了，所以手把手教他们应该怎么打 RPM/DEB 包。另一个会自己打包的是 pgroonga，timescaledb，citus，但是怎么说呢，打的包和 PGDG 规范不统一，而且经常缺这个缺那个 —— 比如 citus 一直就缺 ARM 的包，Timescale 则缺几个特定的发行版，PGroonga 针对的是 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 职位定义

原文：vonng.com。

1.13 - 从PG“断供”看软件供应链中的信任问题

公共镜像停止更新后，Pigsty 为什么选择自建 PGDG 镜像。

这个月发生了一起沸沸扬扬的 “开源断供”事件—— 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 官方仓库怎么突然断了？

Dave 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，总共四百多个可用扩展）。目前是 全世界 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 v0.6.1 已在中国大陆使用这个镜像，Pigsty v3.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 扩展仓库，向他们的客户去交付。老冯的软件仓库也开始成为别人的供应链的上游了。

“开源” 确实并不要求你向用户提供可靠稳定的二进制制成品，但真正重要的不是开源，而是信任 。 开源只是构建信任一种形式，持续的投入，交付的承诺，专注的热情， 面对问题的担当。 想要成为值得信赖，受人尊敬的社区参与者，有许多东西比丢一份源代码到仓库要重要的多。

原文：vonng.com。

1.14 - 卡脖子：PGDG切断镜像站同步通道

调查 PostgreSQL 关闭 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.org 幕后的基础设施

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 仓库上已经是骨灰级打包侠了。不过，主要的问题还是维护太费时间，而且国内的流量费也太贵了。不过如果有金主赞助赞助不限流量的大带宽服务器，老冯也很乐意额外用爱发发电。

原文：vonng.com。

1.15 - Postgres Extensions Day，咱们不见不散

2025 年 5 月 12 日蒙特利尔 Postgres Extensions Day 的议程与参会介绍。

一年一度的 PostgreSQL 开发者大会 PGConf.dev 即将在五月于蒙特利尔举办。大会前一天是 Postgres Extensions Day，专门讨论 PG 扩展的开发、打包与发布。议程刚刚公布，共安排了 14 场演讲。

PGEXT Day 2025 活动海报

当然这次，我就不当观众了，我的演讲是下午的首场 —— “The Missing Postgres Extension Repo and Package Manager”。即“PG 生态中长久缺失的扩展仓库与包管理器”。我会介绍 Pigsty 提供的扩展仓库和 PIG 包管理器，讨论构建、维护 PG 扩展时遇到的问题，与全球开发者分享中国开发者与数据库厂商（个体户，哈哈）的工作、教训与经验。

PGEXT Day 2025 分享主题

Postgres Extensions Day 将于 2025 年 5 月 12 日在加拿大魁北克省蒙特利尔市的 Plaza Centre-Ville 举办。PGConf.dev 2025 随后于 5 月 13–16 日在同一地点举行。

PGEXT Day 在蒙特利尔 Plaza Centre-Ville 的会场

去年 PG 开发者大会在温哥华举办，参加之后感觉收获满满，可惜来自中国的参加者寥寥无几。不知道这一届怎么样，如果您也会去现场欢迎留言，我们可以在现场碰一碰，线下面基。

准备参加的朋友，请在 pgext.day 单独注册。这是由 Postgres Extension Developers Coalition 独立组织的活动，参加免费；PGConf.dev 普通门票 则为税前 500 加元。

下面是 PG 扩展峰会的日程安排，期待在扩展峰会与读者朋友们相见！

扩展峰会的日程

PGEXT Day 2025 日程安排

1. 从 pl/v8 到 pl/<any>：迈向更容易的扩展开发

9:00 am → 25 min，Hannu Krosing

From pl/v8 to pl/<any>: towards easier extension development

pg_tle 允许开发者在没有超级用户权限的情况下，用受信任语言编写并部署扩展。它还提供一些钩子，供受信任语言的函数使用，例如强制执行密码策略。而 pl/<any> 则进一步允许使用任意语言来编写数据库函数，从而实现扩展。其主要途径是在 JavaScript 中编写 Language Handler，并利用任意可被转译到 JavaScript 的语言，成为 PostgreSQL 的嵌入式（或“pl/”）语言。

示例包括：

  • pl/jsonschema：基于 AJV JSON Schema 校验库，将 JSON Schema 定义直接变为可运行的校验函数，性能有时远超使用 Rust + PGRX 封装的 pg_jsonschema。
  • 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

（暂无内容介绍，但光看标题就很让人期待！）

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++ 技巧，你能写出简洁、高效且可维护的扩展。演讲将展示这些特性在扩展开发中的用法。

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 内部机制。

本场面向希望卸载计算、同时保留 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 扩展功能强大又灵活，大多数用户还是希望“开箱即用”，而非自己编译与手动构建。我建立了一个软件仓库，打包了 200 多个扩展，补足了官方 PGDG 仓库的缺口。这些 RPM/DEB 包覆盖五个 Linux 发行版、五个 PostgreSQL 大版本，以及 x86-64 与 ARM64 架构。

本次分享将探讨如何构建这一仓库，包括跨发行版兼容、多架构支持、版本对齐等挑战，并分享经验教训及未来改进方向，让 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 扩展的过程
  • 内存管理与性能开销的应对
  • 如何在架构层面整合两种语言的组件
  • 错误处理、监控及可维护性最佳实践

听众将了解如何把其他数据库的数据变更导入 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 内部轻量且高速的临时存储方案。演讲将讨论这种共享内存用法带来的挑战。

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 年 PGConf.dev

原文：vonng.com。

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

PostgreSQL 与 Pigsty 中长期缺失的一个包管理器 —— PIG。

微信公众号

最近我在忙一个非常有趣的新项目，这两天总算弄完了。各位朋友们，给大家介绍一下这个有趣的小东西，PostgreSQL 与 Pigsty 中久久缺失的一个命令行工具，我称之为 “pig”。

PIG 使用系统的 APT、YUM 或 DNF 安装软件包，根据 Linux 发行版、CPU 架构与 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              # 替换现有仓库配置

$ 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 大象

原文：vonng.com。

1.17 - PostgreSQL神功大成！最全扩展仓库来了！

PostgreSQL 扩展为什么难装？一个原生 RPM/DEB 软件仓库如何交付 340 个扩展。

最近没怎么更新，因为在憋大招。最近功成出关，遂发此文为贺 —— 我做了一个收录 PG 生态中 340 个扩展的仓库，让 PostgreSQL 在成为数据库全能王的道路上又往前迈出了坚实的一步！

自从我在 《PostgreSQL正在吞噬数据库世界》 一文中指出 可扩展性 对于 PostgreSQL 的重要性以来，PG 社区对此进行了热烈的讨论，并且达成了共识。 最终体现在《PostgreSQL 17 发布注记！》中。

但真正重要的事情不是认识世界，而是改变世界。既然大家都已经认清了扩展很重要，那么我们应该做什么，怎么做，就成了真正关键的问题。

那么什么是 PostgreSQL 扩展最关键的问题？在我看来，扩展用得上用不上，是 PG 扩展生态的首要问题。

PG 扩展分发现状

大家知道 PG 生态有很多扩展插件，但这些扩展插件如何安装使用？这第一道门槛就成了许多用户的拦路虎。怎么解决这个问题？ PGXN 说，用我的办法，我可以现场下载编译扩展； Tembo 说，我提前帮你打好 docker 镜像； StackGres 和 Omnigres 说，我们可以在线下载编译好的 So 文件； 八仙过海，各显神通。

大家都有很多好想法，唯独没仔细考虑绝大多数用户到底是如何安装扩展的。 作为前 DBA，我只能说什么现场编译，OCI镜像，下载so文件，在实战中都有些离谱了 —— 使用最广泛且最可靠的扩展安装方式，依然是用操作系统的包管理器安装签名二进制包。 而 yum / dnf / apt 在解决这个问题上已经做的足够好了！所以真的问题其实是，谁来把这几百个扩展插件打成开箱即用的软件包？

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 个第三方扩展插件。其中一部分由 PGDG 官方仓库提供，其余扩展由我维护、修复、编译、打包、测试与分发。上表列出了各仓库和平台的覆盖情况。

每一个扩展，我都针对最新的 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 —— 但这并非必选项。 你也可以在支持的 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！

原文：vonng.com。

2 - 设计注记

关于 PIG 关键决策、取舍与实现边界的设计注记。

设计注记解释 PIG 的决策与提案。每篇都列出日期、状态、范围、备选方案与依据。 提案介绍正在讨论的方向；已实现、已发布的记录说明已经完成的对应工作。

查命令语法与操作步骤，请读 PIG 文档；查各版本的变更，请读发布注记。

2.1 - 从面向人类到 Agent-Native：PIG 的 CLI 契约

PIG 如何分别提供终端文本、结构化结果、执行计划与环境上下文。

决策日期： 2026-02-12
状态： 随 pig v1.1.0 发布，之后随命令层演进调整。下述验收修订已实现（Implemented），纳入 v1.10.0 候选版本，尚未发布。
当前参考： pig 命令总览
范围： PIG 命令的自动化接口，以及外部工具的原生透传接口。

决策

PIG 为终端用户提供文本，为自动化提供结构化结果。产生稳定数据的命令提供 JSON 或 YAML 与状态码， 支持计划的工作流还提供执行计划。pig pt 等透明透传命令保留外部工具的输出、提示与退出码。

背景

PIG 最初是一套便捷的软件包管理 CLI。随着它扩展到 PostgreSQL、Patroni、pgBackRest、 Pigsty 与软件仓库操作，纯面向人的接口出现了几个问题：

  • 自动化只能抓取带颜色的自然语言文本；
  • 外层进程退出为零时，内层操作仍可能已经失败；
  • 破坏性工作流在执行前无法被审阅；
  • Agent 需要连续调用许多发现命令才能理解当前主机；
  • 包装器容易把子进程输出与结构化结果混在一起。

v1.1.0 引入了全局输出选择、稳定结果对象、执行计划与 pig context 快照。 后续重构明确了各命令支持的输出方式。

考虑过的方案

考虑过以下方案：

  1. 解析人类文本。 文案、翻译、颜色与上游工具变化都会让它失效。
  2. 把所有子进程输出捕获进 JSON。 这会破坏交互程序、流式输出、终端控制与原生退出语义。
  3. 设计一个万能结果模式。 软件包事务、恢复计划、指标和环境快照拥有不同的稳定语义，强行拍平只会丢失信息。

契约

长期有效的契约是：

  • 文本是面向人的默认接口；
  • 只有在 PIG 拥有稳定结果时，命令才声明支持结构化输出；
  • 结构化 stdout 只包含一个可解析结果，诊断与被包装工具的输出进入 stderr；
  • 计划描述动作、范围、风险和预期效果，但不执行动作；
  • PIG 自己拥有的破坏性操作在缺少确认时默认失败；
  • 状态码区分用法、确认、环境、依赖与执行失败；
  • pig context 提供有边界的环境快照，不要求调用方自行拼接；
  • 透明透传命令保持上游契约。

2026-10-16 修订将同一契约应用于 pig ext：

  • 可用性判断与各格式摘要共用矩阵优先级、架构别名及元数据回退规则。 macOS 只报告声明支持的 PostgreSQL 版本，不承诺存在安装包。 这里描述的是目录中的包快照；默认构建目标仍按版本元数据与本机安装规则选择， 不受包矩阵影响。
  • 部分导入失败必须返回失败，同时保留已解析、已下载和未解析的条目。 已完成的下载留在磁盘上，操作不承诺全有或全无事务。
  • pig pe 将 HTTP 4xx/5xx 视为失败。错误详情只包含状态码与标准说明， 不包含响应体或服务端自定义的状态描述。
  • pig license issue 明确交付新签发的凭据，成功时在结构化结果的 data.captured_output 中保留 Token。参数中省略签名私钥，私钥加载的原始错误在命令内部 替换为固定文案。参数错误和不含私钥的签名密钥诊断在所有输出格式中保持可读。 其他敏感命令包装器继续隐藏捕获输出与错误详情。

影响

这种分离让脚本更可靠，也让 Agent 能够依据风险与输出能力选择命令。与此同时，每个结构化字段都需要保持兼容， stdout 纯净性需要测试，包装器也不能承诺比被委托工具更高的稳定性。

输出方式由命令决定：PIG 操作使用 PIG 结果，转发工具使用原生输出。

验证与演进

v1.10.0 已提交修订的固定源码与回归测试证据包括： 可用性与计数、 部分导入失败、 exporter HTTP 失败。这些提交不构成版本发布证据。

最初框架随 v1.1.0 发布。 命令层整合提交 fb93602 随后删除重复包装器， 统一计划与输出处理。Patroni 后来改为透明透传，直接使用上游接口。

当前测试覆盖结构化 stdout 隔离、结果渲染、计划、确认门与环境上下文采集。

当前状态

按具体命令选择其支持的输出方式。结构化结果与透传行为见 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 权限原子写入。

影响

使用 sty conf 从已知模板生成新 Inventory。编辑已有 Inventory 时，使用无损的 pig inventory 工作流。

固定版本模板保留原版本；请求了冲突的版本时，命令给出告警。

验证与演进

原生 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 计算 PostgreSQL 核心参数，输出结果供用户审阅。命令探测 CPU、内存与磁盘容量， 接受用户指定的覆盖值，并按选定的工作负载类型计算。文本输出展示生成的参数；JSON 和 YAML 输出 包含输入条件与参数。用户审阅结果后，选择需要的参数，通过现有配置系统应用。

原名“七成正确的调优器”表达的是实用的起点，并非测得的准确率。

背景

新安装的数据库尚无工作负载数据，也需要一套初始配置。小型开发机与大型数据库服务器无法 共用一份固定配置。根据硬件计算参数，可以提供可复现、便于检查和调整的基线。

考虑过的方案

  • 发布一份固定配置。 内存与并行参数需要随主机规模变化。
  • 构建自适应调优器。 这需要工作负载数据、实验与反馈循环。
  • 自动应用参数。 用户需要先审阅结果，再通过现有配置流程决定如何部署。
  • 计算全部 PostgreSQL 参数。 复制、安全与可用性设置还取决于硬件探测无法确定的业务要求。

契约

  • 使用探测到的硬件，或用户明确指定的 CPU、内存与磁盘值。
  • 通过 oltp、olap、tiny、crit 选择计算公式。
  • 相同的实际输入与 PostgreSQL 版本产生相同参数。
  • 结构化结果包含实际采用的工作负载类型、硬件与 PostgreSQL 版本。
  • 文本参数按固定顺序输出，标题注明 SSD 假设。
  • 校验输入范围，并省略所选 PostgreSQL 版本不支持的参数。
  • 保持配置文件与运行中的服务器不变。

影响

用户可以将输出用于新安装或初步容量规划。先审阅参数，通过现有配置系统应用，再测量真实 工作负载。后续调整应依据查询并发、检查点行为、存储延迟与复制要求。

验证与演进

初始实现为 60eecfe。 v1.3.2 首次发布参数生成功能。 当前实现 返回结果供输出层渲染。 tune_test.go 覆盖工作负载公式、资源边界、覆盖值与版本相关参数。

当前状态

参数生成功能已经发布。 输入与输出示例见 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 提供确定的阅读起点。

审查重点是职责分工。操作逻辑应放在实现包中，闭包内的逻辑也遵循这一规则。

验证与演进

约定记录在 9eb70db， 随后由大型命令面整合提交 fb93602 落实。 Guard 测试检查别名冲突与命令注册，实现层行为则由各包测试验证。

当前状态

这仍是新工作的仓库规则。公开命令文档统一放在本站；源码布局约束继续靠近代码保留， 确保贡献者与编码 Agent 在修改前就能看到。

2.5 - 为什么 PIG 默认构建调试包

将 RPM debuginfo/debugsource 与 DEB dbgsym 从显式启用改为显式退出的构建策略决策。

决策日期： 2026-09-03
状态： Released（已发布），随 v1.8.1 交付。
当前参考： pig build
范围： pig build ext 与 pig build pkg 的调试包策略；单个包的产物仍以其配方为权威。

决策

pig build ext 与 pig build pkg 默认请求平台的正常调试包产物。普通构建时，PIG 不再传入禁用参数；只有需要更小或更快产物集合的用户，才显式使用 --nodbg 退出。

在 RPM 系统上，普通构建保留发行版的 debuginfo 与 debugsource 机制；--nodbg 把 debug_package 定义为空。在 Debian 与 Ubuntu 上，--nodbg 会在保留已有选项的同时， 向 DEB_BUILD_OPTIONS 追加 noautodbgsym。旧的 -s|--symbol 继续作为弃用的兼容空操作 被接受，因为调试产物已经不需要额外启用。

背景

旧命令通过 --symbol 显式启用 RPM 调试产物，否则主动注入 debug_package %{nil}。 这与平台惯例相反，也让默认产物不利于事后故障分析。Debian 的 Debhelper 已经在满足条件时 默认创建自动 dbgsym 包，并提供 noautodbgsym 作为显式退出机制。

调试包会增加构建时间、存储和仓库容量，但这些成本可见且可管理。等到精确源码、编译器和二进制 已经变化后，再重建匹配符号通常困难得多。

考虑过的方案

  • 继续用 --symbol 显式启用。 不采用，因为发布质量的产物默认就应保留匹配的诊断材料。
  • 强制所有构建都必须有调试包。 不采用，因为快速本地构建和受限产物流仍需要明确的退出方式。
  • 由 PIG 改写包配方。 不采用，因为 spec 与 debian/rules 负责包内容；运行时改写既意外又难审计。
  • 用 nostrip 退出 DEB 调试包。 不采用，因为它会改变主二进制，而不只是省略独立的自动调试包。

契约

  • 未指定 --nodbg 时，PIG 不添加任何禁用调试包的宏或环境选项；
  • RPM 上，--nodbg 为 rpmbuild 添加 --define "debug_package %{nil}"；
  • DEB 上，--nodbg 向 DEB_BUILD_OPTIONS 追加 noautodbgsym，且不丢弃已有的 parallel=N、nocheck 等值；
  • --symbol 为兼容继续可解析，但被隐藏、弃用且不再有必要；
  • 结构化命令结果新增 nodbg，并保留 symbol 作为实际行为的反向值；
  • 普通安装包仍是构建成功的判据；调试包是附加产物，不能替代主包；
  • 纯 SQL、noarch 或其它不满足条件的构建无需生成空调试包；
  • 包配方或操作者提供的构建环境中的显式决定仍然具有最终权威。命令默认值是一项策略请求， 不是改写配方的许可。

影响

包含编译产物的扩展通常会生成更多文件，占用更多构建与仓库存储。作为回报，默认构建可以直接用于 栈回溯、core 分析和符号服务，不必再做一次重建。已有的 --symbol 脚本仍能运行；有意保留旧式 精简产物集合的脚本应改用 --nodbg。

配方仓库应删除那些不代表具体包约束的全局调试禁用语句。这必须作为独立改动审查，因为部分包是 架构无关包、无法完成调试信息提取，或使用自定义构建系统。

验证与演进

已被取代的显式启用行为可在此前固定版本的 build 参数注册 和 rpmbuild 命令构造 中复核。替代实现由 1c6f524 固定。命令测试保证 --nodbg 可见、兼容参数已弃用；构建器测试保证默认 RPM argv 不含禁用宏、 退出模式包含该宏，并保证 DEB 环境保留已有选项且只追加一次 noautodbgsym。

平台验证应在一个 EL builder 与一个 DEB builder 上各抽样一个含编译产物的扩展，同时检查默认 调试产物以及使用 --nodbg 后不再生成调试产物。配方级例外必须单独报告，不能据此声称 PIG 忽略了自己的参数。

当前状态

已随 v1.8.1 发布。 用法与平台要求见文首链接的当前参考文档。

2.6 - 危险操作只有一套语法：PIG 运维 CLI 安全契约

PIG 如何分离底层原语与编排器、显式表达破坏性意图，并防止别名或结构化输出改变操作含义。

决策日期： 2026-07-02
状态： pg、pb、pt、pitr 已于 v1.5.0 交付；2026-08-29 的 do 与 build proxy 修订已随 v1.8.1 发布。下述验收修订已实现（Implemented），面向 v1.10.0；源码证据见验证章节，尚未发布。
当前参考： 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 拥有的完整工作流。
  • 将维护命令的库名限制为 ASCII 标识符。 这会拒绝原本支持的空格和非 ASCII 名称。 只拒绝 libpq 连接串语法，并在生成命令时保留位置参数边界。

契约

  • 同级命令名称与别名唯一；
  • 子命令别名不能遮蔽另一个顶层命令；
  • PIG 实现的破坏性操作要求显式确认，并在有意义时提供无副作用计划；
  • 命令层在产生副作用前拒绝错误或多余的位置参数；
  • 命令专用名称遵循下游 Pigsty 契约；下游 Playbook 没有显式语法时，只采用有文档说明的最窄安全边界；
  • 结构化输出与文本模式共享同一个结果和成功定义；
  • 含凭据的值不进入诊断输出；就绪或连通性失败必须保持命令失败，不能只记警告后返回成功；
  • 底层 restore 不声称管理 Patroni 或 HA 路由；
  • PITR 编排器按需停止管理器，检查 PostgreSQL 已停止，执行恢复，可选启动 PostgreSQL， 并有意保持 Patroni 停止，等待运维人员验证；
  • 额外原生参数只通过明确记录的边界传递。

2026-10-16 至 2026-10-17 的修订将相同边界用于 v1.10.0 候选版本：

  • 跨用户 DBSU 写入以排他方式创建私有临时文件，使用 0600 和执行 DBSU 的属主，拒绝符号链接与 非普通文件目标，精确替换目标路径，失败时清理暂存。Linux 使用精确目标重命名；macOS 使用系统 Perl 的 rename 系统调用，避免 BSD mv 将源文件移入目录的语义。
  • repo rm 在变更前校验完整参数列表。只有零参数代表全量备份； all 仍只表示 node、pgsql、infra。 requested_modules 保留原始请求，removed_repos 描述展开后的执行动作。 repo add、repo set、repo info 同样整次拒绝显式空名称和逗号空项；只有省略参数 才保留 add/set 默认选择 all 的行为。 add/set 还会在初始化仓库管理器前校验模块名格式。不安全名称使整次请求失败；格式正确但 不存在的名称仍保留添加模式的部分成功行为，替换模式则在变更前整次拒绝。
  • 显式指定 pg -D 时，SQL 操作和数据库枚举绑定到该目录记录的端口与 socket，元数据不明确时先失败。 省略 -D 时保留原生客户端的默认连接方式；实例操作的默认目录仍为 /pg/data。 显式空字符串或纯空白的 -D 在配置初始化和操作前失败。 计划、确认重试和验证命令保留相同的目标与操作选项，包括显式的 -D /pg/data。 VACUUM FULL 计划与执行一样要求确认。 2026-10-17 的维护命令修订要求在计划、确认和执行前拒绝连接串形式的数据库参数，且不回显原值。 否则 libpq 连接串仍能覆盖所选主机和端口，并将凭据带入输出。 vacuum、analyze、freeze 在维护任何数据库前，先校验枚举出的完整库名列表。 生成的 vacuum 和 repack 命令将全部选项放在 -- 之前、库名放在其后， 保证 --all 这样的库名仍表示单个数据库。
  • 覆盖非空非托管 fork 目标必须有明确记录目标的匹配元数据，普通非 PGDATA 目录也不例外。 空目标仍可使用，托管 fork 必须按名称替换。私有路径以 DBSU 解析；无法解析的别名仍直接失败。 2026-10-17 的复核撤销额外的 /pg/data 禁令，按目标归属、源目标关系和运行状态决定是否允许操作。 约定路径既不能识别所有主库，也可能是合法的 fork 目标。 保留受管孤儿目录的强制清理契约。 非托管 fork 删除的本地路径检查遇到权限不足时，以所选 DBSU 重试；确认目标为目录且不是 符号链接后，才允许继续删除。
  • 不能仅凭 EPERM 放行 pg init --force 或 PITR 恢复。独立的可执行程序身份可证明 PID 已被复用； 身份无法确认时仍为未知。向存活 PID 发信号或使用其连接元数据执行 SQL 前，必须确认它属于 PostgreSQL。 未知状态不提供可用于强制停止升级的 PID，fork start 也不能写入成功状态；列表显示 unknown 并在结构化结果中设置 runtime_unknown: true。 角色检测在运行状态不明时同样失败；文件中的角色证据不能推翻已确认的停止状态。 强制初始化分别报告探测失败与正在运行的冲突。 计划前置检查将无法确认的运行状态报告为 unknown，不能以 PID 零标记为检查通过。 状态查询区分权限失败（130201，退出码 3）与其他探测失败（130808，退出码 1）； 两类失败中的部分数据均不能证明实例已停止。
  • 时间线查询将 SQL 绑定到所选目录有效 PID 元数据中的端口与 socket。无法解析时，使用该目录的 pg_controldata 或报告未知时间线；promote 执行过程及必须确认主库角色的成功判据保持不变。
  • PITR 取消确认或遇到 EOF 时，在停服务、恢复与启动之前返回确认缺失（161001，退出码 7）。 验收必须执行真实确认路径，并检查生命周期操作的副作用为零。
  • PIG_NON_INTERACTIVE 和结构化执行关闭提示 stdin，并加上 sudo -n，旧式结构化包装也遵循 此规则。原生透传与显式数据 stdin 保留各自契约。
  • 敏感捕获输出和错误详情保持私有，签发密钥加载失败不回显输入。文档规定的原始导出通道仍然可用。

影响

部分历史缩写被移除，一些脚本需要采用 cluster-first 或显式目标语法。 作为回报，命令名称保留了层次边界，计划对应真实动作，恢复自动化也不会悄悄用原语替换编排器。

计划列出受影响的资源与动作，供用户在执行恢复前审阅。

验证与演进

v1.10.0 已提交修订的固定源码与回归测试证据包括： 运行身份与 SQL 目标、 fork 归属与私有路径、 PITR 取消与未知状态、 计划目标保留、 状态错误分类。这些提交不构成版本发布证据。 后续的维护数据库名与 -- 操作数边界修订 包含 Cobra 参数重解析测试与真实 libpq 目标边界回归测试。 仓库参数预检 在准备密钥或写入仓库前拒绝 不安全模块名，并保留格式正确但模块不存在时的添加部分成功行为。

规范命令契约在 c62c0f5 中进入仓库。 后续提交继续统一别名、早期校验、恢复目标、服务语义与角色检测。 Guard 测试遍历 Cobra 树，拒绝同级与跨层别名冲突；恢复测试覆盖计划、确认、停止升级、旁路恢复、 重启行为与结构化失败结果。 维护命令的回归检查应使用 Cobra 重新解析生成的命令，并让真实 libpq 客户端访问受控本地端点； 仅检查参数列表中包含 -h 和 -p 不足以证明目标绑定正确。

Patroni 后来改成透明透传，这仍遵循同一原则：PIG 只为自己拥有的工作流提供安全保证。

同一契约在 3e1603b 中扩展到 pig do 的名称与集群校验，并在 a880485 中封闭 Ansible 内置目标。软件包驱动、凭据安全且如实报告失败的 build proxy 设置进入 220ef9c， 随后由 74cb128 补齐结构化参数遮盖与机器注解，并在 de7ffd0 中把可选参数同步到机器语法。这些修改均在 Ubuntu 24.04 与 Rocky Linux 9 ARM64 Farrow 客体中完成实机测试，并在 v1.8.1 CI 通过后，从源码提交 1c6f524 正式发布。

当前状态

明确需要 pgBackRest 原语时使用 pig pb restore；需要受控恢复流程时使用 pig pitr。 当前语法与平台要求见对应命令参考页。

2.7 - 编辑声明，保留文档：无损 Pigsty Inventory

为什么 pig inventory 将 YAML 语义与源字节分离，让局部编辑能够保留注释、顺序、锚点与格式。

决策日期： 2026-07-18
状态： 已实现并随 pig v1.6.0 发布。 下述验收修订已实现（Implemented），纳入 v1.10.0 候选版本，尚未发布。
当前参考： pig inventory
范围： 静态 Pigsty Inventory 的查看、局部编辑、校验、比较与安全写入。

决策

PIG 同时把 pigsty.yml 视为配置声明和人工维护的源文档。语义解析器负责判断 Inventory 的含义， 原始字节则决定它的书写方式。局部编辑只替换指定的源范围，并在原子写入前重新解析完整候选文件。

这样可以避免 YAML 工具常见的失败模式：逻辑上正确的一次编辑，却悄悄重写整份文件的注释、键顺序、 引号、锚点、块标量或换行风格。

背景

Pigsty Inventory 是长期存在的运维资产，包含拓扑、调优、凭据、注释、示例、锚点和本地有意义的顺序。 普通的“解析—修改—序列化”流程可能生成有效但无法审阅的差异，并改变运维人员没有选择的结构。

另一方面，没有语义校验的纯文本编辑又可能把无效或自相矛盾的配置写入磁盘。 设计必须同时获得源文件格式与整份配置的正确性。

考虑过的方案

  • 使用一个 YAML 序列化器完整往返。 在真实 Pigsty 语料上，没有选定的序列化器能够逐字节保留完整源契约。
  • 用正则表达式处理 YAML。 引号、注释、别名、块标量和嵌套集合让纯文本语义判断不安全。
  • 只编辑规范化生成副本。 活跃 Inventory 属于运维人员，仍会与生成表示发生漂移。
  • 允许替换所有节点类型。 锚点、别名、标签与块标量需要比普通映射和标量更严格的处理。

契约

  • 拒绝重复键与多文档 YAML；
  • selector 只定位一个无歧义的声明片段；
  • 语义解码与源范围发现是两项独立职责；
  • 编辑从确定的源文件版本开始，文件被并发修改时失败；
  • 编辑片段只进行插入上下文所必需的规范化；
  • 提交前重新解析并校验完整候选文件；
  • 写入使用同目录临时文件、sync、rename 与目录 sync；
  • 拒绝符号链接与不安全路径变化；
  • 成功编辑后移除组和其他用户的权限，保留所有者原有的读写权限；
  • 除非命令明确属于原始文本输出接口，诊断、diff、计划与结构化结果都不输出声明值。

2026-10-16 的验收修订保留 pg_users[].roles 的角色名字符串与结构化授权对象兼容。 编辑、序列化和 CMDB 导出必须保留 YAML 1.1 字符串语义，包括 "1:30"；"010" 是回归对照， 不代表此前必然存在损坏。 2026-10-17 的修订进一步要求：作为字符串传入的日期与时间戳，经 PyYAML 加载后仍为字符串。 已有时间戳值作为不透明标量保留原始内容，不增加日期运算，也不归一化整个文档。 验收使用独立 YAML 解析器检查写出后的类型，不能仅依赖 PIG 自身的往返解析。

sty deploy 与 do 使用配置层已经解析的 Inventory 路径。 参数和环境中的相对路径以调用者 cwd 为基准，带引号的 ~/ 使用用户主目录，默认来源在执行时 也保持显式。来源缺失不得回退。静态检查仍不执行动态来源；执行边界继续由 Ansible 负责。

影响

编辑器比普通 YAML marshal 更复杂；当无法证明源文件保真时，一些语法有效的片段也会被有意拒绝。 换来的结果是可审阅差异：未选择部分逐字节稳定，无效 YAML 无法落盘，并发修改不会被静默覆盖。

Inventory 可以包含自定义凭据字段，无法仅凭字段名可靠脱敏。 因此，show 输出所选声明的原始文本；元数据与校验命令则省略声明值。

验证与演进

v1.10.0 已提交修订的固定源码与回归测试证据包括： 来源解析与角色授权、 日期形式字符串保留、 独立 YAML 消费端验收。这些提交不构成版本发布证据。

根级 Inventory 契约与既有 CMDB 边界建立于 ba6e678，实现落地于 ea43858。测试覆盖真实 Pigsty 配置语料、逐字节往返、 局部替换、受保护 YAML 形式、并发变更拒绝、原子写失败、selector、校验和无敏感值诊断。

后续重构移除了旧选项并分离校验阶段，但没有改变源文件保真模型。

当前状态

静态 Inventory 仍是主要配置来源。selector、校验 profile、结构化输出与明确标记为实验性的 CMDB 桥接， 均以当前 pig inventory 参考文档为准。

2.8 - 复用 Pigsty 已经拥有的 CMDB

PIG 如何复用 Pigsty 既有 PostgreSQL CMDB，并撤销重复的版本存储设计。

决策日期： 2026-07-18
状态： 适配器随 v1.6.0 发布，仍为实验功能；早期版本存储设计已被取代。
当前参考： 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 用匹配版本的基线替换 pigsty 与 pglog schema，并要求确认；操作前先备份现有数据库；
  • load 在事务内替换声明行，并要求显式确认；
  • dump 在没有 force 时拒绝意外覆盖；
  • enable 与 disable 只修改能够识别的 Ansible Inventory source 形式，并原子写入；
  • 无法识别的可执行 Inventory source 一律拒绝，不擅自重写；
  • 整个命令族继续明确标记为实验功能。

影响

修订移除了重复的版本存储实现，也减少了维护工作。

保留下来的适配器更小、更容易审计，也与现有 Pigsty 运维方式兼容。 它同时继承既有系统的限制：init 需要运维人员自行备份，装载声明属于替换操作，而不是协同版本控制。

验证与演进

纠正后的边界记录在 ba6e678。 废弃实现由 e0f73ed 删除， 其中包括平行 schema、snapshot、merge、revision 与 rollback 机制。 保留路径的测试覆盖 PostgreSQL 兼容性、连接信息脱敏、事务失败、摘要绑定确认、dump 安全和原子数据源切换。

当前状态

既有 CMDB 适配器已随 v1.6.0 发布，但仍为实验功能。 初始化或替换前先备份 CMDB。操作流程见 pig inventory 文档。

2.9 - 用有边界的 Grafana 客户端替代仪表盘脚本

pig sty grafana 如何通过原生 HTTP 客户端管理仪表盘与偏好设置。

决策日期： 2026-07-18
状态： 随 v1.6.0 发布；v1.6.2 加入仪表盘 schema v2 支持。
当前参考： pig sty grafana
范围： 仪表盘导入、导出、清理，以及部分组织与用户偏好设置。

决策

PIG 使用原生 HTTP 客户端管理 Grafana 仪表盘。本地 JSON 路径选择单个仪表盘、一个文件夹或 完整仪表盘目录。装载、导出与清理采用同一套选择规则，破坏性操作可以先预览。

默认目录是 Pigsty 仪表盘集合，用户也可以选择其他符合格式的目录。 清理默认按本地文件声明的仪表盘 UID 选择目标；显式指定 clean --all 时， 目标是当前 Grafana 组织中的全部仪表盘与文件夹。

背景

旧 Shell 脚本依赖本地文件布局，对部分失败的说明有限。将这些操作纳入 PIG 后， 可以统一超时、认证、路径校验与结果输出。本地声明也为默认清理提供了明确范围。

考虑过的方案

  • 继续把 Shell 脚本作为公开接口。 网络限制、脱敏与结构化结果仍会分散在各脚本中。
  • 开放任意 Grafana API 调用。 PIG 只需要仪表盘操作与少量偏好设置。
  • 按文件夹名称选择清理目标。 名称可能重复。本地 JSON 提供仪表盘 UID，文件夹仅在清空后删除。
  • 内置默认密码。 凭据应由用户配置。

契约

  • 限制请求时间与响应大小，拒绝不安全的重定向。
  • 认证前检查公开健康端点。没有密码时，info 可以仅返回健康状态。
  • 凭据来自显式输入、环境或 Inventory；诊断与结构化结果不包含凭据和响应正文。
  • list 列出当前组织的全部仪表盘。
  • load 校验并导入所选本地文件，不删除远端仪表盘。
  • boot 将已有的 pigsty 仪表盘设为首页并收藏，将组织命名为 Pigsty。
  • init 装载完整仪表盘目录，全部成功后才执行 boot。
  • dump 将所选远端内容导出为确定性的 JSON，并原子写入文件。
  • clean 删除本地声明的 UID，再删除空文件夹。--all 显式选择整个当前组织。 两种模式都显示计划，并要求确认。
  • lang 与 style 修改组织和当前用户的对应偏好。样式 auto 映射为 Grafana 的 system。
  • 读写时统一处理受支持的 schema v1 与 v2 仪表盘格式。

影响

装载与清理使用同一份本地声明，用户可以只操作一个仪表盘或文件夹。 UID 匹配用于定位目标，不代表该仪表盘最初由 PIG 创建。执行清理前应审阅计划， 尤其是使用 --all 时。

数据源配置、插件安装与用户管理继续使用 Grafana 自身工具。

验证与演进

原生工作流落地于 3060485， 67f6e3b 加入仪表盘 schema v2 支持。 已发布测试 覆盖仅查健康状态、认证、装载范围、初始化顺序、导出稳定性、偏好更新、本地 UID 清理、 显式全量清理与计划变更拒绝。HTTP 客户端测试覆盖超时、重定向、响应限制与脱敏。

当前状态

仪表盘工作流已经发布。路径选择、凭据与清理示例见 pig sty grafana。

2.10 - 让 Patronictl 自己说话

为什么 pig pt 不再镜像 Patronictl 命令树，而是只保留少量 PIG 本地辅助功能的透明启动器。

决策日期： 2026-07-21
状态： 已实现并随 pig v1.6.0 发布。
当前参考： pig pt
范围： Patronictl 集群命令，以及 PIG 拥有的配置选择、参数设置、服务、状态和日志辅助功能。

决策

pig pt 是已安装 patronictl 的透明启动器。PIG 选择配置并分派少量本地辅助命令； 其它命令词及其后的所有参数原样传递，保留原生提示、终端行为、输出格式与退出码。

PIG 不再维护一份持续变化的 Patronictl 命令树副本。

背景

镜像 Patronictl 要求 PIG 复制命令、参数、位置语法、确认方式、格式和版本相关行为。 上游接口持续演进，PIG 的副本必然漂移。同一个操作通过 patronictl 与 PIG 调用时可能出现不同语义。

包装器在 Pigsty 环境中仍有价值：以数据库操作系统用户选择正确配置，提供本地服务和日志工作流， 并把一小段参数设置便利语法翻译为一次原生 edit-config 调用。

考虑过的方案

  • 继续镜像全部上游命令。 必然滞后，并重复 Patronictl 已经拥有的校验。
  • 只允许经过测试的命令白名单。 新上游命令仍要等待 PIG 发布后才能使用。
  • 把原生输出捕获成 PIG JSON。 会破坏交互编辑、流式输出、提示、终端保真和上游 schema。
  • 完全删除 pig pt。 确定性配置选择与本地 Pigsty 辅助能力仍然有价值。

契约

  • 第一个非选项命令词决定本地分派还是透传；
  • set、本地服务快捷命令、status 与 log 由 PIG 拥有；
  • 其它命令和剩余参数原样转发；
  • pig pt -- COMMAND ... 显式绕过本地名称冲突；
  • 包装器参数必须出现在原生命令词之前；
  • 原生 help 可以在没有本地 Patroni 配置时运行；
  • Patronictl 拥有交互提示、原生 --format 和退出码；
  • 会产生原生参数歧义的 PIG 全局结构化输出被明确拒绝；
  • 配置按确定顺序解析，进程以数据库系统用户运行。

影响

自动化需要采用 Patronictl 的集群名在前的位置参数语法与原生输出参数。 部分 PIG 专有别名和结果 schema 被移除。换来的好处是：新 Patronictl 功能无需等待 PIG 发布， 行为也不再依赖滞后的包装器实现。

本地 set 辅助功能有意保持很小：它只分类 Patroni 标量键与 PostgreSQL 参数，然后执行一次原生 edit-config。

验证与演进

重写提交为 6cbc23b。 测试覆盖 token 边界、argv 原样保留、配置优先级、数据库用户执行、原生退出码、无配置 help、 输出模式拒绝、-- 逃逸与本地辅助命令冲突。最终 help 路径修正在 v1.6.0 前完成。

当前状态

透传命令语法以 Patronictl 自身文档为准；PIG 的配置选择与本地辅助功能以 pig pt 为准。 透传命令需要 JSON 输出时，使用 Patronictl 原生 --format json 参数。

2.11 - PIG 2.0 产品方向

PIG 2.0 提案：统一 Pigsty 初始化入口，校验 Catalog，固定项目所用版本，并保留独立部署步骤。

决策日期： 2026-08-13
状态： 提案，待审议，尚未实现。
当前参考： PIG 文档与发布历史
范围： 未来 PIG 2.0 / Pigsty 5.0 的候选产品边界与验证门槛。

决策

提案方向是让 PIG 成为从空白控制节点到经过校验、可以部署的 Pigsty Inventory 的统一初始化入口。 PIG 负责 Catalog 选择与解析、执行计划、流程编排、结构化结果与脱敏执行记录； 软件包事务、配置应用与基础设施状态继续委托给 DNF/APT、Ansible 和未来的基础设施工具。

提案有意保留 PIG 的独立价值：repo、ext、install 在没有 Pigsty 项目时也必须可用。 它也保留独立部署步骤：未来的 pig sty setup 可以下载、引导与生成配置，但不能在用户没有单独调用部署时 自动执行多节点 deploy。

背景

到 v1.8.0，PIG 已经能够下载 release、原生引导控制节点、编译 Inventory、管理仓库与扩展， 并执行部分运维操作。产品仍有以下问题：

  • 仓库、包别名、扩展、路由与 Pigsty 元数据可以独立变化；
  • 项目没有明确 Catalog 身份，无法防止后续解析受全局更新影响；
  • 路由选择与仓库安全还不是一套可见产品契约；
  • 初始化路径上的执行结果还没有形成持久、脱敏的执行记录；
  • PIG、Pigsty、Catalog schema、操作系统与 Ansible 的兼容性需要统一发布矩阵，而不是分散假设。

提案将 2.0 的重点放在元数据一致性与可重复的初始化流程上。

考虑过的方案

  • 把 PIG 变成单体配置与状态引擎。 Inventory、Catalog 编写工具、包管理器、Ansible 与基础设施工具 已经分别拥有不同事实，因此否决。
  • 让 Pigsty 运行时依赖 PIG 或 pgext checkout。 Pigsty release 必须依靠版本化生成产物独立工作。
  • 让 setup 自动部署。 生成并校验配置与修改远程节点属于不同的同意边界。
  • 重新实现 DNF/APT failover 或 Ansible 执行。 PIG 应选择输入并解释结果，而不是成为另一个包管理器或配置引擎。
  • 让 Vagrant/Terraform 统一阻塞 2.0。 实验环境工具的状态语义不同，也不决定核心初始化路径。
  • 立即发明万能 sty plan。 至少两个 PIG 自有工作流证明同一计划 schema 可复用后再讨论。

契约

如果获得批准，产品方向将遵循以下边界：

  • 每类事实只有一个权威：Inventory 负责集群声明，Catalog 编写来源负责产品元数据， 项目锁定文件负责选中的快照身份，执行记录负责观测结果，基础设施工具负责实时状态；
  • PIG 拥有 Catalog schema、校验、客户端、解析器与选择逻辑，但不拥有所有元数据编写数据库；
  • sty setup 组合既有 init、boot、配置流程，不复制实现；
  • setup 在 Inventory 校验后停止，deploy 继续显式执行；
  • 独立命令跟踪兼容 Catalog 发布通道，Pigsty 项目在成功 setup 或 conf 提交后锁定当时的快照；
  • 普通命令不隐式改写已有项目锁定文件；
  • 路由选择来自显式配置或有边界的首次判断，不构建持续 GeoIP、云 IMDS 或后台测速服务；
  • 软件包下载重试与下载端点切换由 DNF/APT 负责；
  • 执行产物按版本管理并脱敏，raw 上游模式保持原生输出流与退出语义；
  • doctor 保持诊断角色，不获得默认修复权限；
  • 未来 lab 支持只做薄适配，PIG 不拥有 Terraform state。

影响

提案会让首次使用路径更清晰，也让元数据选择可以审计。与此同时，它会新增快照身份、 项目锁定文件、迁移规则、信任策略、执行记录和兼容矩阵等持久契约。 这些契约会显著增加测试与发布负担，不能作为松散功能各自交付。

Ansible 事件桥接需要先通过脱敏与兼容实验。诊断与支持包、实验环境适配器推迟到首版发布之后； EL7 支持级别仍待决定。

验证与演进

提案成为发布契约前需要以下证据：

  • 覆盖声明支持的 Linux 平台，验证原生初始化流程；
  • Catalog 签名、过期、回滚、混装与离线场景的对抗测试；
  • 证明 Pig、Pigsty、pgext 生成消费者不会漂移的语义差异检查；
  • no_log 与秘密零泄露的 Ansible 回调实验；
  • 全球、中国、代理和受限网络环境的路由选择测试；
  • 修改安全默认值前的仓库签名矩阵；
  • 1.x 到 2.0 的布局、lock 与混合版本迁移演练；
  • 与明确兼容矩阵绑定的 schema 和结构化输出测试样例。

这份提案采用的实现基线是 v1.8.0。 该版本已经包含原生 boot 与 configure，但没有实现提案中的 Catalog v2、项目版本锁定、setup 命令、 事件执行记录或 2.0 迁移契约。

当前状态

提案仍待审议。Catalog 安全机制、覆盖规则、路径、EL7 支持与 Ansible 事件桥接需要继续决策。 已发布命令的用法见当前文档。

2.12 - Catalog v2 提案：不可变的分类快照

用分类数据文件组成可验证的 Catalog 快照，支持原子激活、项目版本锁定与离线导入。

决策日期： 2026-08-13
状态： 提案；安全机制、覆盖规则、打包方式与路径布局待定。
当前参考： pig ext 与 pig repo
范围： PIG 2.0 产品元数据的发布与读取模型。

决策

Catalog v2 将产品元数据分成多个有类型的数据文件，组成一份不可变、可验证的快照。 清单文件（manifest）记录平台、仓库、路由、包别名、扩展、兼容性、Pigsty 版本与公钥数据的 长度和哈希。所有文件一起校验，通过同一个指针激活，避免混用不同版本的仓库与扩展矩阵。

快照以内容摘要标识。系统、用户、便携环境与项目都选择完整快照，并从各自的存储位置读取。

背景

v1 Catalog 的相关信息分布在内嵌 CSV、仓库 YAML、Pigsty 变量、生成站点与更新流程中。 部分字段可以推导，却仍需重复维护；扩展矩阵也把项目、版本与包等不同对象压在同一条记录里。 独立更新后，很难确认这些数据来自同一次发布。

Catalog v2 要解决的是数据如何一起发布、校验和启用。

考虑过的方案

  • 扩大 extension.csv 或改用一个大 YAML。 不同数据类型需要独立的结构和校验规则。
  • 立即使用 SQLite、protobuf 或定制二进制格式。 当前数据量尚不需要增加这类运行和调试成本。
  • 按字段合并系统、用户与项目基础快照。 合并结果缺少单一发布者、摘要、兼容声明与签名。
  • 只在缓存中保存当前快照和项目锁定版本。 清理缓存会破坏持久选择。
  • 让用户文件覆盖官方信任根。 用户偏好不应削弱系统的安全策略。
  • 后台静默更新并启用。 元数据变化会改变包解析结果，用户需要知道何时发生了更新。

契约

提案规定：

  • 清单与小型数据文件使用确定性的 UTF-8 JSON，大型稀疏数据使用 JSONL。
  • 直接校验清单原始字节，以及数据文件的长度和哈希，避免重新序列化产生歧义。
  • 清单包含格式版本、单调递增的安全版本、创建与过期时间、发布通道及 PIG/Pigsty 兼容范围。
  • 内嵌一份可用于恢复的基础快照。
  • 将包管理器维护的基础快照、持久快照存储、可变状态指针与下载缓存分开存放。
  • Linux 遵循 FHS/XDG，macOS 使用 Application Support 与 Caches。便携模式下的 PIG_HOME 也分别存放配置、数据、状态、缓存与运行文件。
  • 项目锁定文件记录快照身份与有序覆盖层；项目自身持久保存已验证的快照数据。
  • 将“选择哪个摘要”与“到哪里读取对应数据”分成两个步骤。
  • 用户与项目只能收紧系统安全策略。
  • 更新先下载到私有暂存目录，逐层校验并同步到磁盘，再移入按内容寻址的存储，最后原子替换激活指针。
  • 更新失败保留原快照；用户或系统通道更新不改变项目锁定版本。
  • 离线导出包含验证元数据和公开信任材料，不包含私钥。
  • 在一个兼容周期内，ext reload 与 repo reload 可以映射到完整快照更新；各数据文件统一激活。

Inventory、凭据、实时探测、已安装包状态、Ansible 事件、基础设施状态、操作确认与短期指标 继续由各自的系统管理。

影响

分类数据文件便于确定维护职责和校验规则，内容寻址便于回滚与离线导入。 项目自带所需快照后，部署不再依赖某个用户的全局缓存。系统软件包更新基础快照时， 用户已选择的快照保持不变。

这需要同时设计密钥轮换、过期、回滚保护、垃圾回收、路径权限、迁移、包管理器生命周期、 覆盖冲突与跨仓库生成流程。

扩展模型还需区分 SQL 扩展、上游项目、构建单元、发布版本、操作系统软件包、目标平台可用性 与展示规则。平台支持汇总、required_by 等派生字段由生成器计算。

验证与演进

实现前需比较 go-tuf 与最小签名清单方案，记录安全机制的选择。 两者均需通过错误签名、元数据过期、回滚、文件替换、快照混装、下载截断与离线验证测试。

其余测试覆盖各平台路径、root 与普通用户权限、只读目录、符号链接替换、磁盘写满、并发激活、 包升级与卸载、删除全局缓存后的项目运行，以及现有扩展和可用性数据的完整迁移。

本提案形成时的源码基线为 v1.8.0。 v1.9.0 仍使用内嵌与可独立更新的 v1 Catalog。

当前状态

Catalog v2 尚未实现。安全机制、路径与覆盖规则需要先完成决策和验证。 如果覆盖层的冲突与信任规则尚不成熟，可以先采用完整的自定义签名通道。 当前用法见 pig ext 与 pig repo。

2.13 - 一键配置 Xray 客户端与服务端

以现有可工作的客户端与服务端为参考，为 build proxy 增加配套的 VLESS、REALITY 与 Vision 初始化能力。

决策日期： 2026-10-05
状态： Released（已发布），随 v1.9.0 交付。 下述验收修订已实现（Implemented），纳入 v1.10.0 候选版本，尚未发布。
当前参考： pig build、运维安全契约与发布历史
范围： 一键配置 Xray 客户端与服务端；Linux 客户端和服务端，以及 macOS 客户端。共享 Nginx 入口仍是独立部署边界。

决策

为 pig build proxy 增加明确的 client 与 server 子命令。新工作流采用 VLESS + RAW + REALITY + xtls-rprx-vision。服务端首次设置生成配套凭据，重复设置保留 已有客户端连接契约，并提供相同的标准 URI； 客户端直接接收 URI 或命令行参数、安装 Xray、配置本地监听、启动服务，并验证连接。 文件传递是可选方式，不是初始化的前提。

保留现有命令路径与 x 别名。无参数调用改为安装或确认 Xray。兼容期内，历史形式 id@host:port [local] 继续通过 V2Ray 使用 VMess，并保留默认端口。

背景

此前实现 安装 vray，将 HTTP 到 VMess 的配置写入 /etc/v2ray.json，赋予 v2ray 组读取权限， 写入 Shell 别名，重启 v2ray，再检查 HTTPS 请求。现有测试覆盖参数解析、包管理器选择与凭据脱敏。

已检查的参考配对使用 Xray 26.3.27。运行中的 macOS 客户端在回环地址的 8888 端口同时提供 HTTP 与 SOCKS，出站使用 VLESS/RAW/REALITY/Vision，采用 Chrome 指纹、关闭 multiplexing， 并启用 ML-DSA-65 验证。检查期间 HTTP 与 SOCKS 请求均成功；客户端 UUID、short ID 与 SNI 匹配服务端相应字段。

参考 Linux 服务端监听回环地址的 9443 端口。Nginx 占用公网 443，按 SNI 选择后端， 并转发 PROXY protocol 头。Xray 接收该头，连接 REALITY target，使用 freedom 出站， 阻断匹配 geoip:private 的目的地址。此部署由 Nginx 提供公网入口。

检查过的 Pigsty RPM 与 DEB 制品覆盖两种架构，均提供 /usr/bin/xray、权限为 0640 且归属 root:xray 的 /etc/xray.json、xray:xray 服务账户、xray.service，以及 /usr/share/xray 中的地理数据。安装脚本只重载 systemd，不自动启动或启用服务。 公开仓库索引列出了 26.3.27-1PGSTY。运行测试范围见下文。

考虑过的替代方案

  • 只替换 V2Ray 名称，继续只支持 VMess。 无法满足服务端初始化与参考协议需求。 旧模板可以通过 Xray 配置校验，但 Xray 会输出 VMess 弃用警告。
  • 建设通用代理管理器。 暂缓：订阅、协议目录、TUN、透明代理、流量统计与任意配置导入 超出了本次配套初始化需求。
  • 立即新增顶层命令。 暂缓：现有 build proxy 可以容纳两个角色，无须变更根命令语法或维护第二套实现。
  • 原样复制参考服务端。 否决：要求 PROXY protocol 的回环监听不能直接接收公网连接， 也必须尊重现有 Nginx 对端口的占用。
  • 要求客户端必须通过文件初始化。 否决：粘贴一条 URI 或直接指定参数是主要用法； 受保护文件与标准输入仍适用于自动化。
  • 在普通成功输出中打印生成的凭据。 否决：结构化结果和日常日志应可以安全保留； 显式请求的导出可以将 URI 交付到终端。

契约

已经实现的角色语法如下：

# 在 Linux 服务端执行，显式打印连接 URI 供复制。
pig build proxy server --host proxy.example.com --target www.example.net:443 --export -

# 在 Linux 或 macOS 客户端粘贴服务端返回的 URI。
pig build proxy client 'vless://[email protected]:443?encryption=none&security=reality&type=tcp&flow=xtls-rprx-vision&sni=www.example.net&fp=chrome&pbk=PUBLIC_KEY&sid=SHORT_ID&pqv=VERIFY_KEY'

# 也可以逐项指定连接参数。
pig build proxy client --server proxy.example.com:443 --id UUID --sni www.example.net --public-key PUBLIC_KEY --short-id SHORT_ID --pqv VERIFY_KEY

# 可选的受保护文件输入。
pig build proxy client --from ./client.uri

# 复用运行中 Linux 服务端的凭据，不改变它的部署。
pig build proxy server --host proxy.example.com --export-only --export -

# 使用默认客户端监听 127.0.0.1:12345 做无变更预览。
pig build proxy client --from ./client.uri --plan

# 显式使用已检查的本地客户端监听地址。
pig build proxy client --from ./client.uri --listen 127.0.0.1:8888

# 位于已配置可信入口后的 Xray 后端，默认监听 127.0.0.1:9443。
pig build proxy server --host proxy.example.com --target www.example.net:443 --proxy-protocol --export ./client.uri

服务端输入与默认值。 必须指定对外公布的 --host 与 REALITY --target。 公网 --port 默认 443，直连模式默认在所有 IPv4 接口监听该端口。 首次设置指定 --proxy-protocol 时，改为默认监听 127.0.0.1:9443。 显式 --listen 改变绑定地址，不改变公布的公网端口。重复设置未指定 --listen 时，保留已有 受支持配置的监听地址，不使用首次设置的默认值替换它。首次设置时，除非指定 --sni，否则从 target 主机名推导 SNI；重复设置保留已有 SNI，不重新推导替代值。应用配置前检查 target 的 TLS 兼容性， 不静默选择无关的伪装站点。

生成 UUID、X25519 密钥对、随机八字节 short ID，以及独立的 ML-DSA-65 seed 与验证密钥。 重复设置复用已有 PIG 管理的材料，普通重跑不轮换凭据。轮换与多用户管理需要后续明确契约。 使用 warning 日志、关闭访问日志、decryption: none、Vision flow，并明确阻断私网目的地址。 地理数据环境变量指向软件包提供的资源目录。

服务端幂等。 用相同输入重复设置，必须让已有客户端继续可用，无须修改客户端配置。 保留 UUID、X25519 私钥及对应客户端认证材料、short ID、ML-DSA seed 与验证密钥、SNI，以及 协议默认值。公布的 host 与公网端口相同时，导出同一条规范 URI。只在首次创建服务端配置时 生成凭据，不能因为再次执行设置而重新生成。

已有受管理配置和服务设置满足请求，且服务已运行并启用时，只执行检查，不重写文件或重启服务。 若仅服务停止或自动启动被关闭，则使用原有凭据恢复请求的服务状态。已有认证材料缺失、损坏或 存在歧义时必须报错，不能通过静默重新生成凭据来修复。新输入与已有认证或 SNI 契约冲突时， 普通设置拒绝执行；此类变更需要明确的迁移或轮换契约，不能作为普通重跑处理。

复用已有服务端。 server --export-only --host HOST --export DESTINATION 读取现有软件包 服务端配置，使用当前 UUID、SNI、short ID，以及派生的客户端验证材料，导出连接 URI。 公布的公网端口仍默认 443，不能从回环后端端口推断。要求存在唯一、无歧义且受支持的 VLESS/REALITY 入站、客户端账户、SNI 与 short ID；遇到歧义或错误材料时拒绝，不任意选择条目。 此模式不安装、不重写服务端或服务配置、不重启、不启用服务、不轮换凭据；显式请求的文件导出 是唯一持久写入。在进程内派生验证材料，避免将已有私钥或 seed 放入子进程参数。 这个分支执行只读查询与显式凭据导出；共享的 server 命令保留保守的 action 注解。

客户端输入与默认值。 主要用法是直接传入一个带引号的 vless:// 位置参数。 同时支持参数模式：--server host:port、--id、--sni、--public-key、--short-id； 服务端使用 ML-DSA 验证时，通过 --pqv 提供验证密钥。参数模式指定连接字段，REALITY、RAW、 Vision 与 Chrome 采用下述默认值。所有输入形式进入同一份经过验证的连接模型与配置生成器。 保留 --from FILE 与 --from -，作为可选的文件与标准输入方式。拒绝混用不同连接输入， 不静默用 flags 覆盖 URI 字段；--listen 等本地选项可用于所有输入方式。

client.uri 是普通 UTF-8 文本文件，内容只有一条标准 vless:// URI，可带结尾换行； 文件名可以任意指定，它不是新的 PIG 配置格式。 只支持参考组合 REALITY + Vision + TCP/RAW。URI 中的 type=tcp 映射为 JSON network: raw，pbk 映射为 password，sid 映射为 shortId，pqv 映射为 mldsa65Verify。保留 ML-DSA 验证字段，不静默丢弃。拒绝重复参数，以及会改变连接语义的 不支持参数。映射遵循上游分享链接规范。

首次设置使用 socks 入站，默认绑定 127.0.0.1:12345，沿用现有 PIG 客户端默认地址。 可通过 --listen 127.0.0.1:8888 显式使用已检查的本地客户端地址。重复设置未指定 --listen 时， 保留已有受管理客户端的监听地址。同一端口提供 HTTP，启用 UDP，关闭 multiplexing。 出站使用 encryption: none、Vision flow、Chrome 指纹与 spiderX: /。 上游 Socks 参考明确说明支持 HTTP。 分别验证 HTTP 与 SOCKS，不能仅以 TCP 端口开启认定代理工作。

命令行字段与现有参考配置的对应关系如下。客户端路径相对于 VLESS 出站，服务端路径相对于 VLESS 入站。

命令行字段 客户端配置 服务端配置或导出
服务端 --host、--port；客户端 --server settings.vnext[0].address 与 .port URI 对外连接地址，不一定是绑定地址
各角色的 --listen 本地入站的 listen 与 port VLESS 入站的 listen 与 port
客户端 --id settings.vnext[0].users[0].id 匹配 settings.clients[0].id
--sni streamSettings.realitySettings.serverName 属于 streamSettings.realitySettings.serverNames
客户端 --public-key streamSettings.realitySettings.password 从 streamSettings.realitySettings.privateKey 派生
客户端 --short-id streamSettings.realitySettings.shortId 属于 streamSettings.realitySettings.shortIds
客户端 --pqv streamSettings.realitySettings.mldsa65Verify 从 streamSettings.realitySettings.mldsa65Seed 派生
服务端 --target 没有直接对应字段，SNI 需兼容 streamSettings.realitySettings.target
服务端 --proxy-protocol 无对应字段 streamSettings.rawSettings.acceptProxyProtocol: true

参考服务端保持 realitySettings.xver: 0：接收 Nginx 的 PROXY 头，与向 REALITY target 发送 PROXY 头是不同设置。模板默认值保留参考配对的 flow、传输安全、日志、关闭 multiplexing、 服务端私网目的地址阻断，以及客户端指纹。公网连接地址、绑定地址与 target 各自承担不同角色。

平台与服务所有权。 Linux 使用已经配置的软件仓库，以及上述软件包账户、配置路径与 unit。 macOS 客户端使用 Homebrew Xray、权限为 0600 的用户配置 ~/.config/xray/pig-proxy.json， 以及专用用户 LaunchAgent com.pigsty.xray-proxy；不接管其它 Xray daemon 或 Homebrew 服务。 Linux 设置需要 root 与运行中的 systemd；macOS 客户端使用普通用户，并需要已有 Homebrew。macOS 服务端不属于本次变更范围。

新角色设置明确启动服务并启用自动启动；仅安装时不启动或启用服务。Linux 下，PIG 管理有边界的 pig-proxy.conf systemd drop-in，用于资源目录和 capabilities。直接绑定特权端口时， 先清空 bounding 与 ambient 集合，再按需授予 CAP_NET_BIND_SERVICE，避免 systemd 将正向设置 与软件包 unit 的权限叠加；回环地址上的非特权端口后端 不需要该能力。不能依赖宽松的主机 sysctl，也不能为了监听 443 改为以 root 运行 Xray。

应用与恢复。 变更前完成参数解析，检查路径、端口所有权、服务冲突与已有配置。 通过完整的受支持配置形态识别 PIG 管理的配置，不能只凭一个入站 tag 判断。 替换不同或不支持的客户端配置需要 --replace --yes。不支持的服务端配置，以及使用其他账户、显式指定其他服务组或加载额外配置的服务 unit 会被拒绝。 --plan 支持预览，不安装、不生成凭据、不写文件、不重启服务。

通过 Go 序列化生成 JSON。暂存受保护的候选配置，以实际服务身份执行 Xray 校验，再原子应用 配置和服务变更。判断是否需要应用变更时，同时检查内容、所有权与权限。 macOS 将持久禁用状态与已加载状态分别检查，启动时启用自己的 LaunchAgent，失败时恢复两种状态。 保存原始内容、所有权、权限、服务启用状态与运行状态，用于有边界的回滚。 服务健康与连通性检查通过后，才交付 Shell 别名或连接导出。客户端要求 HTTP 与 SOCKS 访问 https://www.google.com/generate_204 均返回 HTTP 204，因此服务端外网访问该端点是验收条件。 应用失败返回非零，并说明哪些 恢复步骤成功；安装过的软件包可能保留。

不删除或自动停止 V2Ray。端口冲突在预检阶段停止，并给出迁移指引；保留原 V2Ray 配置供操作者 控制回滚。保留 po、px、pck 便利命令，同时覆盖构建工具需要的小写代理环境变量。 当前 Shell 激活仍需要 source 生成的 Shell 文件并执行 po；子进程不能修改父 Shell 的环境。

秘密与导出。 --export FILE 将显式请求的连接导出写入权限为 0600 的文件， 不包含服务端私钥或 ML-DSA seed。--export - 明确将一条完整 URI 交付到标准输出， 非秘密的初始化诊断写入标准错误。凭据导出模式要求文本输出，与 JSON/YAML 同时指定时在变更前 拒绝，不把 URI 放进结构化结果。普通初始化输出仍脱敏。允许命令行输入，同时明确调用者的 Shell 历史或进程检查可能保留这些凭据；需要避免留存时仍可选择文件或标准输入。

将整个 URI 视为凭据，包括 UUID 与认证字段。默认日志、计划、JSON/YAML 结果与失败详情只包含 脱敏摘要及导出路径。密钥材料在进程内生成和派生。校验器输出必须私下捕获：上游配置错误 可能直接包含错误的秘密值，不能将通用子进程输出捕获视为安全凭据边界。重复导出到已有受保护文件时，若内容是 同一条规范 URI，则成功返回而不重写；内容不同时报告冲突，不能静默覆盖或在诊断中打印原内容。

入口与验证边界。 一键服务端设置默认使用直连模式。显式 --proxy-protocol 后端模式 要求绑定回环地址，并已有可信前端。本次不重写 Nginx 或防火墙、云安全组规则。 公网端口已被占用时明确失败，不停止端口拥有者。后端就绪不能证明公网入口正常；服务端设置 分别报告本机检查，并将外部可达性保持为待验证，直到客户端握手与 HTTPS 请求实际成功。

生成等价的 Xray 配置应覆盖参考配对的全部协议与认证字段。复现完整参考部署还需要 Nginx 的 SNI map、接收 PROXY 头的网站后端，以及操作系统特定的服务注册。当前实现管理 Xray 及其服务设置， 不宣称可从一个服务端 URI 还原这套 Nginx 组合。配置等价不要求逐字节保留 tag、字段顺序或安装专属名称。

2026-10-16 的兼容修订接受旧渲染器生成、配置与二进制路径匹配的完整无 marker macOS plist。 管理注释本身不足以证明归属。修改过或外来的文件需要显式替换；Linux 识别也限制为完整生成的 两种 capability 配置。一次性迁移注释后，相同执行必须保留运行中的服务。

无 marker 测试样例来自实际执行旧渲染函数。其源文件与公开可访问的 v1.9.0 源码 9eb54888 逐字节相同。这证明旧源码格式，不代表验证了某个已发布二进制。

影响

用户通过一条标准 URI 衔接两次初始化操作，或直接指定客户端参数，配套参数自动生成， 无须手改 JSON，也无须创建连接文件。 新客户端与历史 VMess 形式首次设置都默认使用 127.0.0.1:12345。直连服务端默认在所有 IPv4 接口监听公网端口，PROXY protocol 后端默认监听 127.0.0.1:9443。重复设置未指定 --listen 时 保留已有监听地址。配置与服务管理明确区分角色、操作系统、所有权和外部入口。

实现保留在 cmd/build.go 与 cli/build 下的聚焦文件中，复用现有计划、输出、确认、特权写入 与日志辅助函数。

验证与演进

v1.10.0 已提交修订的固定源码与回归测试证据包括： 完整旧服务定义识别。这些提交不构成版本发布证据。 下列 v1.9.0 运行验证针对原始实现。

实现提交为 d090b7c， 5d8660c 补齐文件归属与服务状态恢复。测试覆盖角色语法、输入形式等价、脱敏、监听默认值、凭据复用、 导出冲突、受保护文件、capabilities 选择与执行计划。完整 Go 测试、vet、静态分析、死代码与 复杂度检查，以及命令/build 包重复竞态测试均在本地通过。

运行测试使用 Xray 26.3.27：

环境 已验证行为
全新 Debian 13 ARM64 客户端 软件包安装；以 xray 身份运行；HTTP/SOCKS 健康检查；重复设置保持配置和 PID；错误 UUID 后回滚
全新 Debian 服务端 直连特权端口；0640 配置与 0600 导出；重复设置保持凭据、文件与 PID；导出失败后回滚
macOS 已有 Homebrew Xray 独立 LaunchAgent；HTTP/SOCKS 连通性；无变更重跑；失败后恢复配置与持久禁用状态
已有参考服务端 只读导出与客户端测试期间，配置哈希和 PID 保持不变

新服务端导出的 URI 成功建立 REALITY/Vision 连接，并使用 ML-DSA 验证。 HTTP 与 SOCKS 访问可达的 TLS 网站均返回 HTTP 200。该服务器的网络无法访问 Google 健康检查端点， 因此这组配对的完整客户端设置失败并回滚。完整客户端设置在连接已有参考服务端时通过， 使用的是该服务端已有的 Nginx/PROXY 入口。

运行测试未覆盖 RPM 安装、全新 Homebrew 安装、UDP 转发、其他 Xray 版本或新建 PROXY protocol 前端。

当前状态

已随 v1.9.0 发布。 Nginx 入口自动化与凭据轮换留待后续设计。

2.14 - 把 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 已就绪时跳过仓库工作。 用户明确指定离线来源时，仍需要准备该仓库。
  • 把所有收尾检查设为硬失败。 locale 便利、本机 SSH 修复或目录初始化失败，不一定让控制节点不可用。

契约

  • 显式本地路径和 URL 必须校验，失败时不能悄悄回退到在线模式；
  • 自动发现的离线来源必须通过所有者与权限检查；
  • 已提交的本地仓库可以优先于选定的软件包；
  • 下载与受限归档解压使用原生有边界实现；
  • 离线包必须包含 pigsty/repo_complete 完成标记；附加根目录先预检并在 pigsty 前 rename， 冲突与中断残留都会使操作停止，由用户检查并清理；
  • 来源解析完成后只进行一次提权，并可禁止或要求非交互提权；
  • 软件包准备失败时，被替换的仓库定义可以恢复；
  • 就绪检查实际执行 Ansible，并验证它会使用的 Python 模块；
  • 结果区分 ready、offline、online 与 existing 模式；
  • 硬失败和收尾告警使用不同结构化字段；
  • bootstrap 不声称 Pigsty 部署已经成功。

影响

原生工作流比脚本启动器更大，但副作用与回滚状态可见。 它能够在已经可用的控制节点上继续准备离线内容，也能为自动化提供稳定结果而不隐藏可选问题。

控制节点准备好后，生成 Inventory、部署所选服务，再检查服务状态。

验证与演进

原生实现落地于 222616e， 并在 74e084e 中继续收敛。 测试覆盖来源优先级、权限检查、受限解压、sudo 自重启、仓库回滚、locale 修复、Ansible/Python 就绪、 本机 SSH、初始化、告警分类与结构化结果。v1.8.0 发布页记录了交付状态。

离线包改进提交 8fa3abb 保留多个通过校验的顶层仓库，继续使用 repo_complete 完成标记。 该改进已随 v1.8.1 发布。

当前状态

pig sty boot 准备控制节点。配置 Inventory 后，单独执行部署。 来源模式、环境控制与后续步骤见 pig sty 文档。

2.15 - 自动安装 Pigsty 仓库公钥

配置 Pigsty 仓库时准备内嵌公钥，明确默认失败处理与显式密钥要求。

决策日期： 2026-10-04
状态： Released（已发布），随 v1.9.0 交付。
当前参考： pig repo
范围： 配置仓库时安装已有的内嵌 Pigsty 公钥。

决策

当所选模块包含当前平台可用的 pigsty-infra 或 pigsty-pgsql 仓库时，先准备内嵌 Pigsty 公钥，再修改仓库定义。该逻辑放在共享配置流程中，使 repo add、repo set 以及复用此流程的调用方保持一致。已有公钥文件直接复用，自动安装尽最大努力； 所选仓库元数据显式引用签名密钥时，安装失败才必须终止。

背景

基线实现 只在调用方指定 GPGCheck 时安装公钥，原生 sty boot 使用了这一选项。 因此，普通 repo add/set 没有安装 PIG 已经内嵌的公钥。

两个 Pigsty 仓库都使用此公钥，而它们分布在 pigsty、infra、pgsql 和默认的 all 选择中。只检查命令参数是否包含字面量 pigsty 会遗漏正常用法。

APT 不会自动发现 /etc/apt/keyrings 中的文件，仓库必须通过 signed-by 引用准备好的 公钥，否则即使文件写入成功，刷新缓存时仍会出现 NO_PUBKEY 警告。

降级时删除 signed-by，可能与保留的同源 APT 定义冲突，因此成功和失败时都保持默认引用一致。 显式元数据指定的是它实际需要的密钥，准备一个无关的默认文件不能满足要求。

备选方案

  • 运行时下载默认公钥。 现有内嵌发布输入已经提供公钥，支持离线使用，无须增加网络或外部工具依赖。
  • 每次仓库操作都安装公钥。 无关仓库不应触发 Pigsty 公钥写入，应先解析模块成员与平台可用性。
  • 自动安装公钥失败就阻止仓库操作。 可选的公钥准备不应阻止已有兼容模式工作，因此拒绝这种处理。 显式签名密钥元数据仍是严格边界。
  • 同时开启所有签名校验。 发布者身份、RPM 包签名和 APT 元数据认证是不同的契约。 自动安装公钥不能证明所有软件包或镜像都具备对应签名。

契约

  • 安装前校验请求的模块。被拒绝的仓库替换请求不会安装公钥或移动仓库文件。
  • 检查展开后模块中的两个 Pigsty 仓库标识符，包括自定义模块；不凭 URL 主机名选择签名身份。
  • EL 写入 /etc/pki/rpm-gpg/RPM-GPG-KEY-pigsty，Debian/Ubuntu 写入 /etc/apt/keyrings/pigsty.asc；仅在需要安装时写入内嵌公钥，权限为 0644。
  • 先检查公钥普通文件是否存在，包括能解析到普通文件的符号链接；存在时复用，不修改内容或权限。 存在性检查失败时仍尝试安装。
  • 父目录缺失时使用已有 sudo 回退机制创建，并通过原子文件写入逻辑安装。 检查目标时遇到权限不足，仍应进入提权安装并再次检查目标。目标被目录或悬空符号链接占用属于安装错误。
  • 未显式指定密钥时，安装失败只告警并继续；仅所选 Pigsty 定义降级为 APT trusted=yes， 或 RPM gpgcheck=0 与 repo_gpgcheck=0。成功和失败时均补齐默认的 gpgkey 或 signed-by 引用，不通过改写已保留的仓库文件实现降级。
  • 显式密钥准备针对实际引用。APT 的 signed-by 接受已有普通密钥文件的绝对路径，多个路径以 逗号分隔；显式引用默认路径时可安装内嵌公钥。EL 按需准备显式引用的默认公钥文件，再把 gpgkey 中的路径或不含变量的 URL 交给原生 rpm --import。
  • 显式密钥准备失败会在备份、写入仓库、刷新缓存之前终止。保留其引用，绝不降级该定义。 有效自定义密钥不依赖默认路径；其他所选仓库的默认密钥失败只使对应的默认定义降级。
  • 普通操作成功准备公钥后保留签名校验设置。sty boot 在公钥准备成功时请求启用校验， 默认公钥失败时采用同样的降级规则。
  • 降级警告同时写入 stderr 和 repo add/set 的 data.warnings，sty boot 也保留在自身告警中。 默认安装不导入 RPM 数据库，EL 显式密钥配置会导入；两种情况都不修改 APT 全局信任库。
  • 仓库回滚恢复仓库定义，已经安装或导入的公钥保留。

影响

添加 Pigsty 仓库时会一并尝试准备公钥文件，离线主机也适用。默认公钥失败不再阻止仓库配置。 降级会关闭这些 Pigsty 定义的签名校验，并明确报告。存在性检查成功后保留管理员已有文件， 不校验其内容；第三方仓库的信任策略保持不变。 密钥不可用时，APT 可能告警并沿用此前认证过的索引，因此仓库配置成功不能证明每个索引都刚刚下载。 当前默认行为和路径以仓库参考页为准。

验证与演进

自动公钥准备实现 与仓库回归测试 已记录在源代码提交 56f7353 中。本地回归测试覆盖 EL、Debian、Ubuntu 及两种支持的架构，并检查默认选择、组合模块、已有公钥复用、存在性检查被拒、自定义模块、 不可用仓库、默认公钥降级，以及显式密钥安装失败时不修改仓库。已有仓库替换测试继续验证回滚行为。

本地 EL9、EL10、Debian 12 和 Ubuntu 24 ARM64 虚拟机中的实际 CLI 测试使用独立挂载命名空间，验证普通用户通过 sudo 创建缺失的密钥目录、内嵌公钥字节与权限一致、重复执行、组合模块、可解析的结构化输出， 以及默认公钥失败时告警并继续、显式密钥失败时在替换仓库之前停止。测试使用真实 DNF/APT， 使用隔离缓存，并查询生成索引中的可用包。APT 还验证成功安装后的密钥引用 消除了 NO_PUBKEY 警告，以及显式配置 signed-by 与 trusted=no 时能完成元数据认证。 这些检查不安装软件包，也不验证 RPM 包签名。虚拟机原有仓库定义、公钥与缓存保持不变。

后续回归补充了保留旧 APT 源与已认证缓存、自定义密钥缺失时阻止添加和替换、默认路径不可用时 有效自定义密钥仍能工作，以及显式与默认密钥混合配置的场景。权限测试禁止普通用户遍历密钥目录， 验证提权安装和隐藏符号链接拒绝行为。RPM 导入测试使用虚拟机 RPM 数据库的隔离副本。

当前状态

已随 v1.9.0 发布。 用法与平台要求见文首链接的当前参考文档。

2.16 - 官网与 CLI 统一按目录条目计数

官网、扩展列表、可用性摘要和目录刷新结果统一统计全部目录记录。

决策日期： 2026-10-16
状态： Implemented（已实现），纳入 v1.10.0 候选版本，尚未发布。
当前参考： pig ext 目录计数
范围： 目录总数与默认列表成员；包安装和 SQL 启用方式仍由各条目定义。

决策

统一用目录记录数表示扩展总数，包括已打包的 SQL 工具与保留的生命周期记录。 CLI 根据实际加载或下载的目录计算总数。

背景

目录同时服务于软件包发现和 PostgreSQL 扩展发现。已打包的 SQL 工具即使没有控制文件， 不支持 CREATE EXTENSION，也仍然有用。将它从默认列表和总数中排除，会让 CLI 与 官网、目录文件的统计不一致，即使按名称搜索仍能找到它。

考虑过的方案

  • 只统计被分类为 PostgreSQL 扩展的记录。 不采用，因为同一目录会在 CLI 与官网产生不同总数。
  • 为每种条目类型新增独立的公开计数。 当前列表契约不需要这些额外字段。
  • 在 CLI 中写死对外公布的总数。 不采用，因为下载的目录可能与内嵌目录不同。

契约

  • 无筛选的默认列表包含全部目录记录，包括 SQL 工具和已移除记录。
  • 文本行数与 JSON/YAML 的 data.count 等于实际返回的记录数。
  • 搜索统计匹配条目；--pkg 继续统计主导包记录。
  • 全局可用性文本摘要使用完整目录总数。
  • 目录刷新结果的 data.extension_count 和消息使用实际下载的记录数。
  • 官网总数跟随内嵌目录；更新后的下载目录可以有不同总数。
  • 计入总数不会改变条目的 DDL 要求、生命周期状态或平台可用性。

影响

SQL 工具同时出现在默认列表和按名称搜索的结果中。输出字段的名称和类型保持稳定。 调用方应将扩展总数理解为目录覆盖范围；它不表示某个数据库已启用的扩展数， 也不表示某台主机可以安装的扩展数。

验证

v1.10.0 已提交修订的固定源码与回归测试证据包括： 目录条目计数与可用性。这些提交不构成版本发布证据。

此前的分类规则保留在 v1.9.0 目录源码 中。验收检查将解析得到的记录数与默认列表、可用性摘要、目录刷新结果逐一比较， 覆盖已打包的 SQL 工具和已移除记录，并确认搜索和包计数仍对应各自返回的行。

状态

此决策于 2026-10-16 接受，已实现并包含回归测试。v1.10.0 候选版本内嵌 603 条记录，尚未发布。 计数契约见当前参考，版本边界见发布注记。

2.17 - 分类别名按目标 PostgreSQL 大版本解析

动态分类别名选择扩展软件包时，使用请求的 PostgreSQL 大版本。

决策日期： 2026-11-06
状态： 已在源码提交 7c069dc 中实现，已随 v1.10.4 发布。
当前参考： pig ext 分类别名
范围： 解析扩展软件包组的动态 pgN-* 与 pgsql-* 分类别名。

决策

稳定版本的分类别名使用请求的 PostgreSQL 大版本判断软件包可见性。pgN-<category> 从别名中取得大版本， pgsql-<category> -v N 使用同一个目标大版本。完成可见性判断后，软件包模板也按请求的大版本渲染。

目录仍是软件包名称与平台可用性的事实来源。这样，目录刷新后可以直接描述软件包拆分和按版本变化的支持情况， 无需在别名解析器中加入扩展专用分支。当前目录将 EL PG14/15 的 pgaudit 描述为 pgaudit_14/pgaudit_15， 将 PostGIS 3.7 描述为 postgis37_N，并将地址标准化器和 PG16 以上的 Tiger Geocoder 描述为独立条目。

当前 Beta PostgreSQL 占位版本继续使用兼容策略：借用最新稳定版矩阵，并只保留 PGDG 来源的条目，因为目录还没有 该目标自己的矩阵行。

背景

在本次修改之前，pgsql-* 分类别名会使用最新稳定版目录行判断稳定目标。于是 pgsql-gis -v 14 可能带入只在 PG18 矩阵中存在的软件包，例如 Tiger Geocoder。编号形式 pg14-gis 已经使用请求的大版本，因此两种别名会得到 不同的软件包组。

同一个解析器还包含 EL 上 PG14 和 PG15 的 pgaudit 硬编码改名。这一规则对应历史软件包名称，而当前 pgaudit 配方和 目录已经使用 pgaudit_$v。当软件包元数据修正后，继续把这个规则留在代码中就会使别名结果过时。

考虑过的方案

  • 所有 pgsql-* 别名都继续使用最新稳定版模板。 否决，因为显式 -v N 必须遵守请求的 PostgreSQL 大版本支持矩阵。
  • 继续添加扩展专用的软件包特例。 否决，因为 pgaudit 和 PostGIS 的软件包名称与支持行都是目录数据，通用解析器可以直接渲染。
  • 只使用 RPM/DEB 版本元数据。 否决，因为软件包矩阵还记录操作系统、架构、来源仓库、隐藏状态和不可用单元格。
  • 删除 Beta 借用机制。 否决，因为当前 Beta 目标没有自己的目录行，仍需要稳定版模板以及原有的 PGDG-only 限制。

契约

  • 稳定版本的 pgN-<category> 别名按 PostgreSQL 大版本 N 判断可见性。
  • 稳定版本的 pgsql-<category> 别名按命令传入的目标版本判断；显式 -v N 时，它与 pgN-<category> 的结果相同。
  • 如果没有目标版本传入解析器，继续沿用现有命令探测与操作默认值；分类别名解析器收到零值时使用最新稳定大版本。
  • 软件包模板按请求的目标大版本渲染。可见的主导非 contrib 条目按渲染后的软件包名称去重。
  • 已知操作系统缺少矩阵单元时，仍视为不可用。现有未知操作系统的软件包元数据回退行为不变。
  • Beta 目标借用最新稳定版矩阵，并只保留 PGDG 来源条目。这是唯一借用稳定模板的例外。
  • 已配置的操作系统软件源必须提供目录命名的软件包；解析器不会把已安装的软件包从历史名称迁移到新名称。

影响

pig ext add pgsql-gis -v 14 --plan 与 pig ext add pg14-gis --plan 现在选择相同的 PG14 矩阵。PG14/15 不再继承 PG18 独有的 Tiger Geocoder 条目。修正后的 pgaudit 目录行会让 EL 上的 PG14/15 解析为 pgaudit_14 和 pgaudit_15； PostGIS 3.7 目录行会在矩阵允许时解析为 postgis37_N，并分别解析地址标准化器和 PG16 以上的 Tiger Geocoder 软件包。

这样更容易通过刷新目录更新行为，因为软件包专用名称已经回到目录中。用户仍需配置包含所选软件包的软件源，尤其是 EL 上 PG14/15 pgaudit 的 Pigsty 来源条目。

验证与演进

源码提交 7c069dc 在 cli/ext/category_alias_test.go 中增加了目标版本、编号别名、默认版本、Beta 与未来大版本路径的回归测试。 cli/ext/catalog_embedded_test.go 覆盖 EL8/9/10 与两种架构上的 pgaudit，以及 EL 和 Ubuntu 上 PG14-18 的 PostGIS、 地址标准化器与 Tiger Geocoder 软件包解析。目录变更位于 cli/ext/assets/extension.csv。

已提交源码通过 git diff --check、go test -shuffle=on -count=1 ./...、go vet ./...、 go test -race -shuffle=on -count=1 ./cli/ext ./cli/install、staticcheck ./...、配置的复杂度检查和 deadcode ./...。发布标签 v1.10.4 包含上述实现；对应 发布注记 记录了交付内容。

当前状态

目标版本行为已在上述源码提交中实现，并写入 pig ext 参考文档。发布注记和部署状态 与本实现记录分开维护。

3 - 发布注记

pig 每个版本的发布注记

最新稳定版本是 v1.10.4。

pig 每个已发布版本的发布注记，从新到旧。安装包与校验和见各版本的 GitHub 发布页。

升级方法与各平台安装说明见安装文档。

3.1 - pig v1.10.4

新增七个目录条目，刷新包元数据，修复目标版本别名解析，目录增至 626 个条目。

PIG v1.10.4 将内嵌 PostgreSQL 扩展目录从 620 个条目更新到 626 个，并修复分类别名未按指定 PostgreSQL 大版本选择软件包的问题。2026 年 11 月 6 日的目录快照新增七个条目，移除已退役的 pgcontext_pgvector 记录，净增六个。

新增目录条目

扩展 版本 PostgreSQL 支持 说明
pg_warren 0.8.0 15–18 基于 PostgreSQL 表的版本化图遍历与图计算
pg_statecharts 0.1.0 16–18 层次状态机与事务性事件处理
pg_statecharts_dev 0.1.0 16–18 pg_statecharts 的 SCXML 导入与迁移开发工具
pg_lion 0.3.0 16–18 用于过滤、计数与聚合的 Roaring 位图倒排索引
pg_lion_citext 0.3.0 16–18 为 lion 索引提供大小写不敏感的 citext 运算符类
pg_lion_vector 0.3.0 16–18 为 pgvector 的 vector 与 halfvec 提供带过滤的近邻索引
opencc 0.1.0 14–18 基于 OpenCC 的简繁中文、地区用语与日文新字体转换

实际可安装性取决于目标 PostgreSQL 大版本、操作系统、架构与已配置的软件源。

版本与包元数据更新

部分目录版本变化如下：

扩展 版本变化
postgis 3.6.4 → 3.7.0
timescaledb_toolkit 1.26.0 → 1.27.0
vchord 1.1.1 → 1.2.0
vchord_bm25 0.3.0 → 1.0.0
pg_tokenizer 0.1.1 → 1.0.0
pg_search 0.26.3 → 0.26.5
pg_duckdb 1.1.1 → 1.2.0
pg_lake 3.5 → 3.6
anon 3.2.3 → 3.3.2
pg_integrity_checksums 2.0.0 → 2.1.0

本次还刷新了软件包可用性、依赖、描述与源信息。PostGIS 3.7 使用 postgis37_N RPM 包系列，地址标准化器与 Tiger Geocoder 使用独立软件包。EL 上 PostgreSQL 14、15 的 pgaudit 包名分别为 pgaudit_14、pgaudit_15。

分类别名遵循目标版本

对于稳定版 PostgreSQL，pgsql-<category> -v N 现在与 pgN-<category> 使用相同的平台及 PostgreSQL 大版本矩阵。例如，pig ext add pgsql-gis -v 14 --plan 不再混入仅适用于较新 PostgreSQL 大版本的软件包。软件包名称统一从目录取得，解析器中旧的 pgaudit 特殊改名规则已移除。Beta 目标仍沿用借用最新稳定版矩阵、仅保留 PGDG 来源的回退策略。

目录口径与构建版本

内嵌目录包含 626 条记录，其中 624 条可用、2 条为保留的已移除记录。包含 PostgreSQL contrib 模块时，共对应 518 个不同包名；非 contrib 包系列共 457 个。详见 目录条目计数口径。

Go 保持 1.27.3，内嵌 Pigsty 保持 4.5.0，默认 cargo-pgrx 保持 0.19.3。升级 PIG 请参阅 安装文档。

校验和

文件校验和
pig-1.10.4-1.aarch64.rpm Linuxarm64SHA-256 4981a060779423ab4d6c5baaa8fe6c26adb972fc34b9515119b9e5d4723513ce
pig-1.10.4-1.x86_64.rpm Linuxamd64SHA-256 d1624bbcec5d3f4715d223acca8311182ef1ee36542c16bcf82602674ee82b07
pig-v1.10.4.darwin-amd64.tar.gz macOSamd64SHA-256 9384759851af53f5cddc381007f78de9a226b43b914848291df86ec41096119e
pig-v1.10.4.darwin-arm64.tar.gz macOSarm64SHA-256 d0f876a518b82f021c83914c5909f1ac914cbe8c0aa0957cef37c83d69b79b0d
pig-v1.10.4.linux-amd64.tar.gz Linuxamd64SHA-256 1caa6f4af13e1f40f5faa9752628efe1dd85190b344bf1597cb3c8d23e99fe0b
pig-v1.10.4.linux-arm64.tar.gz Linuxarm64SHA-256 756b7c94936a4c8cca1b0a15f3bcac8eee9669480b8d6af205e920b673a680ba
pig_1.10.4-1_amd64.deb Linuxamd64SHA-256 98bbfce9dc263e94d4025debdd9bf0e137d9ec12afff4d57e4e08530b1255bf3
pig_1.10.4-1_arm64.deb Linuxarm64SHA-256 18447ccff10fd31c90ae16b34f2885a0415bc6efca5d0ff78f435e68ba6438e1

v1.10.4 ·

3.2 - pig v1.10.3

新增四个扩展，刷新目录元数据，扩展条目增至 620 个。

PIG v1.10.3 更新内嵌 PostgreSQL 扩展目录，从 616 个条目增至 620 个， 新增四个扩展，并刷新软件包、版本、兼容性与可用性元数据。

新增扩展

扩展 版本 PostgreSQL 支持 说明
oai_fdw 1.16 14–18 通过 HTTP/HTTPS 采集 OAI-PMH 元数据的只读外部数据包装器
pg_agent_gate 0.3.0 18 面向 Agent 角色的 SQL 提议、校验、受控执行与人工审批门
pg_integrity_checksums 2.0.0 14–18 为 PostgreSQL 页面、行、表、索引和数据库提供物理与逻辑校验和
pg_stat_tcpinfo 1.1 14–18 Linux TCP 连接统计、延迟与重传观测

这些记录描述的是目录与软件包可用性；实际可安装性仍取决于目标 PostgreSQL 大版本、操作系统、架构和软件仓库快照。

版本与元数据更新

本次更新现有扩展的软件包与版本信息，包括 pg_nanotime 0.2.0 → 0.3.0、 supautils 3.4.4 → 4.0.0、pg_ducklake 1.0.2 → 1.0.3、 pg_improv 0.10.0 → 0.12.1、wrappers 0.6.3 → 0.6.4、 edtf_postgres 1.2.3 → 1.3.2、hypopg 1.4.3 → 1.4.4、 rdf_fdw 3.0 → 3.1。同时刷新维护目录中的包矩阵、兼容范围、描述和源信息。

扩展目录口径

目录现在包含 620 个条目：617 条可用记录和 3 条保留的已移除记录。 目录计数口径 包含 SQL 工具与生命周期保留记录， 具体可用性仍取决于平台。

Go 保持 1.27.3，内嵌 Pigsty 保持 4.5.0，默认 cargo-pgrx 保持 0.19.3。 升级 PIG 请参阅 安装文档。

校验和

文件校验和
pig-1.10.3-1.aarch64.rpm Linuxarm64SHA-256 2068ca8150df3ee837d0ba6e533ba651703c7223c14c522703ee1be9c41666ea
pig-1.10.3-1.x86_64.rpm Linuxamd64SHA-256 97ff1c1799262650a92d669dafc905d498d5ab3cf58619198322bc2d274b4ceb
pig-v1.10.3.darwin-amd64.tar.gz macOSamd64SHA-256 16203993bbba93dee16a38eac3eedbf67ed2cce3c7894cedbba613e95578004c
pig-v1.10.3.darwin-arm64.tar.gz macOSarm64SHA-256 0eb3f0447107734ae7decf3bc16caf99087e86119e83ce34987ebb376285fb14
pig-v1.10.3.linux-amd64.tar.gz Linuxamd64SHA-256 a3e61d0d71b9226ac89aa3b1e29baa8c92e5109ecaa2c7e26343f474e5832e04
pig-v1.10.3.linux-arm64.tar.gz Linuxarm64SHA-256 5f25ff6cf634f708d5f70bde39a07d83fe9c7d1ef7d944395eb294eb64554ecf
pig_1.10.3-1_amd64.deb Linuxamd64SHA-256 dfabbcf4fcdf612d79a7cce76db08d36683e00bd2b0f27c7e78258f54fcb721a
pig_1.10.3-1_arm64.deb Linuxarm64SHA-256 4065ed14209a4857b26fa1c7e19adbeee2e5be68df41710db33b64b18159045f

v1.10.3 ·

3.3 - pig v1.10.2

新增 pg_nanotime，更新扩展版本与软件包信息，目录增至 616 个条目。

PIG v1.10.2 更新内嵌 PostgreSQL 扩展目录，从 615 个条目增至 616 个， 新增 pg_nanotime，并刷新扩展版本、兼容性与软件包可用性信息。

新增扩展

收录 pg_nanotime 0.2.0， 提供纳秒时间戳与固定时长间隔类型。目录包含 PostgreSQL 17、18 的 RPM 与 DEB 软件包信息；上游将 0.2.0 标记为测试版本。

版本更新

扩展 原版本 新版本
citus、citus_columnar 14.2.0 14.3.0 软件包
duckdb_fdw 2.0.1 2.0.2
pg_mentat 1.17.2 1.18.0
pg_tre 4.5.1 4.5.2

Citus 的目录扩展版本为 14.3-1，对应 RPM / DEB 软件包版本为 14.3.0。 本次还补充了 pg_tre 在 PostgreSQL 17、18 上的 DEB 包可用性信息。

目录信息

  • 刷新 PostgreSQL 兼容范围、包可用性、许可证与扩展描述。
  • 将 duckdb_fdw 的目录兼容范围调整为 PostgreSQL 15–18， pgcontext_pgvector 调整为 PostgreSQL 17。
  • 扩展数量统一按 616 个目录条目 计：613 条可用记录与 3 条保留的已移除记录。 目录计数口径 包含 SQL 工具与生命周期保留记录， 具体可用性仍取决于平台和 PostgreSQL 大版本。

Go 保持 1.27.3，内嵌 Pigsty 保持 4.5.0，默认 cargo-pgrx 保持 0.19.3。 升级 PIG 请参阅 安装文档。

校验和

文件校验和
pig-1.10.2-1.aarch64.rpm Linuxarm64SHA-256 f07992b20b0b397d1e4bb286656b404e3c911775e98e5fc7d940ef91439f62ed
pig-1.10.2-1.x86_64.rpm Linuxamd64SHA-256 372f4fe8d54a1ad888c91976d011d8b95de3e10286966cfc94b0ab91e2170b20
pig-v1.10.2.darwin-amd64.tar.gz macOSamd64SHA-256 a54be0a4ceadf1e047b74fdb187ff57e9f97b81907c8d66795e7787de88ad864
pig-v1.10.2.darwin-arm64.tar.gz macOSarm64SHA-256 60df049a38e109bccb3089d74fa41e0d22606ce4df0e4fadae39530d546ca731
pig-v1.10.2.linux-amd64.tar.gz Linuxamd64SHA-256 686c5d6cf682a5a5a1d70cc09a86fecc441b22456f79bb84f192c4730ac2bd8a
pig-v1.10.2.linux-arm64.tar.gz Linuxarm64SHA-256 e1e84d5afcddc8e474d130de638bc400bb965f887bdc9face842f111fb94afeb
pig_1.10.2-1_amd64.deb Linuxamd64SHA-256 38b9634be544a1ee462926f74f3c647c2fc1b21eeffb43e41c24a9033a03a63b
pig_1.10.2-1_arm64.deb Linuxarm64SHA-256 4034cebd3a51839ecb0cb8bdf325d783f1ebb88e19b4664ab21fbf31316eae58

v1.10.2 ·

3.4 - pig v1.10.1

升级 Go 1.27.3 修复安全问题，更新工具依赖，扩展目录增至 615 个条目。

PIG v1.10.1 是一次安全与扩展目录维护版本：升级 Go 至 1.27.3， 更新工具依赖，并将内嵌 PostgreSQL 扩展目录从 603 个条目增至 615 个。

安全更新

  • Go 工具链从 1.27.2 升级到 1.27.3。CI 与发布构建使用 go.mod 指定的版本。
  • 纳入 crypto/x509 的 CVE-2026-111943 / GO-2026-6809 修复。 Go 证书验证器会拒绝包含特定不再受信任的中间证书的证书链。

根据 Go 官方发布公告， Go 1.27.3 相比 1.27.2 新增 1 项安全修复。 更早的 Go 安全修复已包含在 PIG v1.10.0 使用的 1.27.2 基线中。

依赖更新

通过限定原版本的模块替换，更新间接工具依赖：

模块 原版本 新版本
github.com/cpuguy83/go-md2man/v2 v2.0.6 v2.0.7
github.com/stretchr/objx v0.1.0 v0.8.0
golang.org/x/mod v0.41.0 v0.42.0
golang.org/x/tools v0.51.0 v0.52.0

扩展目录

内嵌目录现包含 615 个条目，相比 v1.10.0 新增 12 个：

  • codesystem、encsearch、hdr_histogram、pg_improv
  • pg_kv、pg_lease、pg_synonym、pg_table_range
  • pg_tre、pg_try_cast、stannum、tin

本次刷新还更新了已有扩展的版本与软件包可用性元数据。 总数沿用 目录条目计数口径，包含已打包的 SQL 工具和已移除扩展的保留记录。 615 不表示所有条目都支持 CREATE EXTENSION，也不表示它们在每个平台上都可安装。

兼容性

命令、参数与配置保持和 v1.10.0 兼容。 内置 Pigsty 保持 4.5.0，默认 cargo-pgrx 保持 0.19.3。

从源码构建需要 Go 1.27.3 或更高版本。使用预编译软件包无需在本机安装 Go。 请按 安装文档 升级 PIG 可执行文件，以使用更新后的 Go 标准库； 仅升级主机上的 Go 不会更新已经安装的 PIG 二进制。

校验和

文件校验和
pig-1.10.1-1.aarch64.rpm Linuxarm64SHA-256 fbd58de4cd1fa767c6d2b15d4fcb029fe38c90a0d12db2e387b7f698b5c8a69d
pig-1.10.1-1.x86_64.rpm Linuxamd64SHA-256 7955e93744fcc2d4cce9044102c2bd7ca470388a0556d3220a624f78e38c629b
pig-v1.10.1.darwin-amd64.tar.gz macOSamd64SHA-256 31fea0e9513e551e2be8dc99a8fc0f77de4bdfe40e66dadc206e227254bb7942
pig-v1.10.1.darwin-arm64.tar.gz macOSarm64SHA-256 1177f3b616279100ce97d23eb4fa6bc2e8daf02dbd23780a8dd5025240082c5a
pig-v1.10.1.linux-amd64.tar.gz Linuxamd64SHA-256 0e837098d45b080ddf9205681709dbc38318d2b65cbdaed711246fd5834c3b50
pig-v1.10.1.linux-arm64.tar.gz Linuxarm64SHA-256 6658242816263ea4f5e3abeb3454665098c7100c75c76a3e45386a15faf6f397
pig_1.10.1-1_amd64.deb Linuxamd64SHA-256 37f5dca9407010c56d8c5747c8ddcef101d7f07602296e0bb89620c633692eab
pig_1.10.1-1_arm64.deb Linuxarm64SHA-256 f385d1c6fac40a6cf648505d349a72e7e3eadf2948024f086efe81733c2a9be5

v1.10.1 ·

3.5 - pig v1.9.0

600 条扩展目录记录、一键 Xray 客户端与服务端、自动准备仓库公钥，以及 cargo-pgrx 0.19.3。

Pig v1.9.0 新增一键配置 Xray 客户端与服务端、自动准备 Pigsty 仓库签名公钥， 并将内置扩展目录更新为 600 条记录。cargo-pgrx 默认版本升级到 0.19.3， 内置 Pigsty 版本保持 4.5.0。

Xray 客户端与服务端

  • pig build proxy 安装或检查 Xray；pig build proxy client 配置 VLESS/REALITY/Vision HTTP/SOCKS 客户端；pig build proxy server 配置 Linux 服务端。 Linux 使用 systemd，macOS 客户端使用独立的用户 LaunchAgent。
  • 客户端支持标准 VLESS URI、--from FILE/- 或显式连接参数。首次客户端监听 127.0.0.1:12345，首次直连服务端监听 0.0.0.0:443；重复执行保留已有监听端点与服务端凭据。
  • 配置、属主、权限与服务状态一致时不改写文件、不重启服务。客户端连通性检查失败会恢复 原有受管文件与服务状态。替换不同的客户端配置需要 --replace --yes；两种角色均支持 --plan。
  • server --export-only --host HOST --export - 只导出已有连接，不改变部署。导出文件权限为 0600； 显式导出到 stdout 要求文本输出。普通结果与计划不包含凭据。历史 VMess 位置参数形式 继续使用 V2Ray。
sudo pig build proxy server --host proxy.example.com --target www.sraoss.co.jp:443 --export ./client.uri
sudo pig build proxy client --from ./client.uri

在服务端执行第一条命令，将 client.uri 安全传到客户端，再在客户端执行第二条命令。 前置条件与 macOS 配置见 pig build。

仓库签名公钥

  • repo add、repo set 与 sty boot 在选中仓库需要时准备内置 Pigsty 公钥。 已有普通公钥文件直接复用；缺失的默认公钥离线写入 /etc/pki/rpm-gpg/RPM-GPG-KEY-pigsty 或 /etc/apt/keyrings/pigsty.asc。
  • 隐式默认公钥准备失败时给出警告，仅对选中的 Pigsty 仓库回退签名检查。 默认公钥引用保持稳定，包括 APT 的 signed-by。
  • 显式指定的签名公钥引用必须有效；无效或不可用的公钥在仓库替换、缓存刷新之前报错。 EL 通过 rpm --import 导入显式引用。仅选择其他仓库时，不准备 Pigsty 公钥。

签名检查默认值、公钥准备与元数据刷新的区别见 pig repo。

扩展目录与构建默认值

  • 内置目录共 600 条记录，相较 v1.8.1 快照新增 22 条。新增条目包括 edtf_postgres、plphp、pg_lexo、pg_money、istore、colnames、 pg_statkit、pgtelemetry、pg_rusage、pgexporter_ext、pg_statvfs 与 libx509pq， 同时刷新软件包版本与平台可用性元数据。
  • 目录总数包含保留的生命周期记录。能否安装取决于扩展状态与操作系统、架构、PostgreSQL 版本矩阵。使用 pig ext avail NAME 检查目标平台。
  • pig build pgrx 默认使用 cargo-pgrx 0.19.3；显式 -v 与扩展目录中的专用版本要求继续有效。
  • 延续 v1.8.1 的平台调试包默认策略。--nodbg 可禁用 RPM 的 debuginfo/debugsource 与 DEB 的 dbgsym；-s|--symbol 保留为已弃用的兼容空操作。

兼容性

没有移除已有命令或参数。新增 Xray 角色命令使用 VLESS/REALITY/Vision，历史 VMess 位置参数命令保持 V2Ray 行为。服务端设置检查本地监听与服务。 按所选公网端口配置防火墙、云安全组和所用的 Nginx 前端，再从客户端验证连接。

验证

经过验证的 v1.9.0 标签 指向源码提交 9eb5488。该精确提交通过 完整 CI，覆盖随机顺序测试、命令 race 回归、 vet、静态分析、漏洞扫描与发布 snapshot。Release 工作流 生成八个 Linux/macOS 压缩包与 RPM/DEB 安装包，下载后已逐一验证 SHA-256。

校验和

文件校验和
pig-1.9.0-1.aarch64.rpm Linuxarm64SHA-256 d0d80bd23a654308598f265ce4b4d4f78d6156c113ce6aa00f82bfc9519a180f
pig-1.9.0-1.x86_64.rpm Linuxamd64SHA-256 e3b25640c9e528f2b883f7e5f4838640a8897857fa22dc1324aca69b72966a7c
pig-v1.9.0.darwin-amd64.tar.gz macOSamd64SHA-256 d7eb266e1b8ab60d20ac582c6b0e3741b7e8516ce1a56df447c0285b3e5dcab9
pig-v1.9.0.darwin-arm64.tar.gz macOSarm64SHA-256 096284577d0493ddba871b51e820654b358c7f4eb9c11175674a1d21b2718824
pig-v1.9.0.linux-amd64.tar.gz Linuxamd64SHA-256 a4b5ffca540bc4f924f86398bcad6cb7221ac7520b54b1d3fd32c9877d9cafd2
pig-v1.9.0.linux-arm64.tar.gz Linuxarm64SHA-256 ddfa80fbb34f6738dd68e0d04cd92355711330f6896cd650df7d71b012788def
pig_1.9.0-1_amd64.deb Linuxamd64SHA-256 3d955a24a8ff805ee2b6da6428e2b882f97104e2fb597785225269443071d93a
pig_1.9.0-1_arm64.deb Linuxarm64SHA-256 c175b37552147e64590309801800826a0075ae8285ed78178c2adcaec3741471

v1.9.0 ·

3.6 - 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，以及覆盖不可变制品。

工具链与扩展目录

  • pig build ext 与 pig build pkg 默认保留平台调试包；使用 --nodbg 显式省略。 -s|--symbol 保留为已弃用的兼容空操作。

  • 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 覆盖与可用性矩阵。

验证

本版本从源码提交 1c6f524 构建。该精确提交通过完整 CI 工作流， 覆盖随机顺序测试、命令 race 回归、vet、静态分析、死代码检查、漏洞扫描与 GoReleaser snapshot。 随后 tag 通过 Release 工作流，生成并发布 RPM、DEB、macOS 与 Linux 制品。

兼容性提醒

  • 本版本没有移除 CLI 命令或参数。
  • 如果旧脚本依赖只读命令顺便创建本地配置，应改为显式准备所需状态。
  • pgrx 默认值变为 0.19.2；构建特定扩展时，仍以该扩展的目录元数据为准。

校验和

文件校验和
pig-1.8.1-1.aarch64.rpm Linuxarm64SHA-256 4154b3e49cb499e57d7c7b1ab4ae5e45d03d5d0c2ffe26d6ade64e46db6923cf
pig-1.8.1-1.x86_64.rpm Linuxamd64SHA-256 35c398f409d9293b4f8c0cdf949b19c62d06016ec7e724472143d2327199869d
pig-v1.8.1.darwin-amd64.tar.gz macOSamd64SHA-256 6c08b6a698191b8b6494a0f60880fb17cafa535bad12d5c544333e4625048455
pig-v1.8.1.darwin-arm64.tar.gz macOSarm64SHA-256 0fb6c86cc18a29aeb74e9d12e717c104087c6ecf5a43250dfcc71cd7681fb868
pig-v1.8.1.linux-amd64.tar.gz Linuxamd64SHA-256 9219e87433ebd239e0773ae7417fdd08e97bb511312e6747542bf46b6b1bbf2b
pig-v1.8.1.linux-arm64.tar.gz Linuxarm64SHA-256 b30924880f21126ece3afc77ca75794a0ceb77964cdfd8bc20da72d9d3273078
pig_1.8.1-1_amd64.deb Linuxamd64SHA-256 6fc304501671921b18439223c630c7d4635b10ac75493d5c12a5987ff80c618e
pig_1.8.1-1_arm64.deb Linuxarm64SHA-256 1a70cd71f6c1f443812fe30535427891513c0ba03be219ac21f1a3d6fd450051

v1.8.1 ·

3.7 - 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.8 - 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.9 - 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.10 - 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.11 - 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.12 - 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.13 - 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.14 - 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.15 - 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 cbfbb04b9640dcf39fcd9ccfa49e500dd0e65b72c0326c0d166e6f43e52b6dc3
pig-1.4.1-1.x86_64.rpm Linuxamd64SHA-256 c3325c7c68559b3149567eddd5963c4bc3bb4b39622740ca469f9d5d274e462b
pig-v1.4.1.darwin-amd64.tar.gz macOSamd64SHA-256 c82e8a5e010aed198748576a3740479ac73eaa4a05f50cd4afc82fbcc9075d4d
pig-v1.4.1.darwin-arm64.tar.gz macOSarm64SHA-256 a62e223a9f3fb6755cfeabfed2b9241d1be8aad42251917ddb2a4757fa5df6bd
pig-v1.4.1.linux-amd64.tar.gz Linuxamd64SHA-256 65938e1158deb8a795c32ae99ff09178b7dec6b09743f8bdfbd9fd09a522e89f
pig-v1.4.1.linux-arm64.tar.gz Linuxarm64SHA-256 0fe4172dd1f03ac1b6ac73a28cdfe78b70c6613996252a230710b291faf8db58
pig_1.4.1-1_amd64.deb Linuxamd64SHA-256 bdcc318ed50bff505f193f3a265d8fd2c7b093a104d5e5728b8c070e3580827e
pig_1.4.1-1_arm64.deb Linuxarm64SHA-256 1a1acb69d41bcfb9df8fb86c8d3c076050df5a242b639c1215833cd6394e112d

v1.4.1 ·

3.16 - 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.17 - 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.18 - 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.19 - 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.20 - 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.21 - 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.22 - 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.23 - 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.24 - 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.25 - 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.26 - 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.27 - 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.28 - 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.29 - 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.30 - 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.31 - 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 83e1b491b58793859caaccb0600a8ad7f7c0ea71dfcbc1dc348bf4666f7dc742
pig-0.7.3-1.x86_64.rpm Linuxamd64SHA-256 00671775c22918b6e92c8f39972fa2e6e78536ba0ca1e23f9bb9752a2910a974
pig-v0.7.3.darwin-amd64.tar.gz macOSamd64SHA-256 d6ac6164a09a7b2aac210b898c8729df6cbcef6462207a896caf08b1511c9cdb
pig-v0.7.3.darwin-arm64.tar.gz macOSarm64SHA-256 c595df851cc76b93fe2692e880909aed316db00cfdcd75c0c5667141915e49b7
pig-v0.7.3.linux-amd64.tar.gz Linuxamd64SHA-256 baa875895623f073204d0ff8fbcb76bd37da6e5806e70aae43aaa2cb14355186
pig-v0.7.3.linux-arm64.tar.gz Linuxarm64SHA-256 b6d75f7e0474341990e2cf64b5006fb7b145839f8b54c12f70657c166bfeeb14
pig_0.7.3-1_amd64.deb Linuxamd64SHA-256 5ddfd410c6d6c2546804bf948aab3b7978fa719d92c1477d7a33889e7b1006dd
pig_0.7.3-1_arm64.deb Linuxarm64SHA-256 2996c06fda272e01fea72bb8eec51dca8f4b9e8526d9833dcda1cf7549d1e01a

v0.7.3 ·

3.32 - 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 080dd93c33faf81e8f9d3b9d543b9949604b834ccd55331cce697df79049a9af
pig-0.7.2-1.x86_64.rpm Linuxamd64SHA-256 b91056230d3a790ab0190b3680fc5dbc3eb1306b7a1c2416fb6ef421bf48dcf7
pig-v0.7.2.darwin-amd64.tar.gz macOSamd64SHA-256 9b294e58b8c3629066b905e25dda4f51eacc1eb4b6d5d87fab32d17fb13a9cb7
pig-v0.7.2.darwin-arm64.tar.gz macOSarm64SHA-256 74f3276752d826c8130ca22a791da48548608378a453908e7cdd095c0564a1eb
pig-v0.7.2.linux-amd64.tar.gz Linuxamd64SHA-256 0c9f6e6bf930e70206df2c6d58d1296f1a7a77ca7d89d27d47112bc44544cda4
pig-v0.7.2.linux-arm64.tar.gz Linuxarm64SHA-256 f62842217be958569ca09051e8cad0d674ee9446245e45655b91f9918927b340
pig_0.7.2-1_amd64.deb Linuxamd64SHA-256 091d12d5d5c3c8e52b8b60ab180b88b7aeaff512aa344af0e039c7d4b73c75a0
pig_0.7.2-1_arm64.deb Linuxarm64SHA-256 53346bd96538a20b0bb3bb4161ba117bca7b5cf6633f5d3c357fe9e560b06ff5

v0.7.2 ·

3.33 - pig v0.7.1

新网站，改进容器内的使用体验
  • 上线全新的 PGEXT.CLOUD 扩展目录
  • 修复了不必要的 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.34 - 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.35 - 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.36 - pig v0.6.1

CI/CD, el10 存根，PGDG 中国镜像
  • 新增 el10 与 debian 13 trixie 的支持存根
  • 上线独立的 PIG 文档站
  • 使用 go 1.25 重新构建，新增 CI/CD 管道
  • 在中国大陆使用 PIGSTY PGDG 镜像
  • 移除空的 pgdg-el10fix 仓库
  • 使用 Pigsty Babelfish 镜像
  • 修复 EL 10 专用的 EPEL 仓库
  • pig version 输出构建环境信息

v0.6.1 ·

3.37 - 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.38 - 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.39 - 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.40 - pig v0.4.1

414 个扩展，pg18 别名支持
  • 将扩展列表更新至 414 个
  • 在 pig ext scan 映射中添加 citus_wal2json 和 citus_pgoutput
  • 添加 PG 18 beta 仓库
  • 添加 PG 18 包别名

v0.4.1 ·

3.41 - 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.42 - pig v0.3.4

常规更新
curl https://repo.pigsty.io/pig | bash -s 0.3.4
  • 常规扩展元数据更新
  • 使用阿里云 epel 镜像代替损坏的清华大学 tuna 镜像
  • 升级 pigsty 版本字符串
  • 在仓库列表中添加 gitlab 仓库

v0.3.4 ·

3.43 - pig v0.3.3

别名、仓库、依赖
  • 添加 pig build dep 命令安装扩展构建依赖项
  • 更新默认仓库列表
  • 为 mssql 模块（babelfish）使用 pigsty.io 镜像
  • 将 docker 模块合并到 infra
  • 从 el7 目标中移除 pg16/17
  • 允许在 el7 中安装扩展
  • 更新包别名

v0.3.3 ·

3.44 - pig v0.3.2

新扩展

增强功能

  • 新扩展
  • 使用 upx 减少二进制大小
  • 移除嵌入的 pigsty 以减少二进制大小

v0.3.2 ·

3.45 - pig v0.3.1

轻微错误修复

常规错误修复

  • 修复仓库格式字符串
  • 修复扩展信息链接
  • 更新 pg_mooncake 元数据

v0.3.1 ·

3.46 - pig v0.3.0

新主页和扩展目录

本次发布为 PIG 项目 增加了主页，并提供 PostgreSQL 扩展目录。

v0.3.0 ·

3.47 - pig v0.2.2

404 个扩展

Pig v0.2.2 中提供 404 个扩展

v0.2.2 ·

3.48 - pig v0.2.0

新增 DocumentDB、VectorChord-bm25 等扩展，更新 Citus、TimescaleDB、PGroonga 等版本。

新增扩展

扩展更新

  • citus 13.0.0 -> 13.0.1
  • pg_mooncake 0.1.0 -> 0.1.1
  • timescaledb 2.17.2 -> 2.18.1
  • supautils 2.5.0 -> 2.6.0
  • VectorChord 0.1.0 -> 0.2.0
  • pg_bulkload 3.1.22 (+pg17)
  • pg_store_plan 1.8 (+pg17)
  • pg_search 0.14 -> 0.15.1
  • pg_analytics 0.3.0 -> 0.3.2
  • pgroonga 3.2.5 -> 4.0.0
  • zhparser 2.2 -> 2.3
  • pg_vectorize 0.20.0 -> 0.21.1

v0.2.0 ·

3.49 - pig v0.1.4

新增 DocumentDB、VectorChord-bm25 等扩展，更新 Citus、TimescaleDB、PGroonga 等版本。

新增扩展

扩展更新

  • citus 13.0.0 -> 13.0.1
  • pg_mooncake 0.1.0 -> 0.1.1
  • timescaledb 2.17.2 -> 2.18.1
  • supautils 2.5.0 -> 2.6.0
  • VectorChord 0.1.0 -> 0.2.0
  • pg_bulkload 3.1.22 (+pg17)
  • pg_store_plan 1.8 (+pg17)
  • pg_search 0.14 -> 0.15.1
  • pg_analytics 0.3.0 -> 0.3.2
  • pgroonga 3.2.5 -> 4.0.0
  • zhparser 2.2 -> 2.3
  • pg_vectorize 0.20.0 -> 0.21.1

v0.1.4 ·

3.50 - pig v0.1.3

390 个扩展

v0.1.3，常规更新，现在可用 390 个扩展！

v0.1.3 ·

3.51 - pig v0.1.2

anon 扩展和其他 350 个扩展

351 个 PostgreSQL 扩展，包括强大的 postgresql-anonymizer 2.0

v0.1.2 ·

3.52 - pig v0.1.1

更新扩展列表

更新扩展列表。

v0.1.1 ·

3.53 - pig v0.1.0

repo、ext、sty 和自更新

pig CLI v0.1 发布

v0.1.0 ·

3.54 - pig v0.0.1

创世发布

创世发布

v0.0.1 ·

3.55 - pig v1.10.0

603 条目录记录、PostgreSQL 目标验证、恢复与 fork 安全修复、Inventory 保真，以及一致的自动化结果。

Pig v1.10.0 集中修复现有命令的正确性与安全边界：操作前验证 PostgreSQL 目标， 保留 Inventory 来源与 YAML 类型，让仓库、扩展及自动化结果准确反映实际执行情况。 内嵌目录从 600 条增至 603 条记录。内置 Pigsty 保持 4.5.0，默认 cargo-pgrx 保持 0.19.3。

PostgreSQL 目标与维护命令

  • 显式 -D 将 psql、ps、kill、vacuum、analyze、freeze、repack 绑定到所选实例， 包括 --all 枚举数据库的连接。启动 SQL 客户端前，PIG 检查 PID、数据目录、端口、socket 与进程身份。运行元数据无效、过期、来自其他目录或无法确认时直接失败，不回退到另一实例。
  • 未指定 -D 时，这些 SQL 命令保留原生客户端的连接默认值。pg clone 与 pg fork 继续使用各自的端口参数。提升后的时间线检查使用所选实例或其控制数据；无法解析时保留未知状态。
  • 计划与确认重试命令保留数据目录、PostgreSQL 版本、操作系统用户和维护选项。 VACUUM FULL 计划正确标明必须确认。
  • 维护命令的位置参数只接受数据库名称。包含 = 或以 postgres://、postgresql:// 开头的值在规划或执行前被拒绝，错误信息不回显该值。空格和非 ASCII 名称继续受支持。 生成的命令将名称放在 -- 后，避免把名为 --all 的数据库解释成命令选项。
  • vacuum、analyze、freeze --all 在开始维护前验证完整数据库列表。 需要连接串或被此边界拒绝的数据库名时，请使用原生客户端。

目标选择见 pig pg，数据库名称规则见 维护命令。

运行状态、恢复与 fork 安全

  • 权限失败、PID 元数据损坏、进程身份无法验证时，报告错误或未知状态，不能据此授权强制初始化、 恢复或 fork 替换。pg status 对权限失败返回 130201（退出码 3），其他运行探测失败 返回 130808（退出码 1）。计划将无法确认的前置条件标为 unknown。
  • 拒绝 PITR 确认或输入到达 EOF 时，在停止服务、恢复、启动之前返回 161001（退出码 7）。 未知状态不能提供可用于强制终止的 PID，也不能视为启动成功。恢复后的 SQL 检查要求目标已验证。
  • 替换非空的非托管 fork 目录，需要有效的归属元数据，且其中显式记录的目标路径必须匹配。 缺失、损坏或不匹配的元数据不能授权删除。运行中目标以及源目标路径关系的保护继续有效。
  • Clone 与 fork 必要时以所选数据库操作系统用户执行路径检查，支持权限为 0700 的私有数据目录。 无法访问或解析的路径不能绕过校验。托管孤儿副本仍可通过其托管名称清理。
  • 以数据库用户写文件时，使用私有的同目录临时文件并精确替换目标。新文件权限为 0600； 拒绝目录与符号链接目标，替换时不会覆盖指向旧文件的其他硬链接所见的内容。

PITR 参考介绍托管恢复流程；pig pb restore 仍是独立的恢复原语。

Inventory 与 Pigsty

  • sty deploy 与 do 显式向 Ansible 传递已解析的 Inventory 路径。命令行和环境变量中的 相对路径以调用者工作目录为基准；带引号的 ~/ 路径在解析前展开。选中的来源缺失或无效时， 不会静默回退到其他清单。
  • pg_users[].roles 同时保留角色名称字符串与结构化授权，包括授权状态及可选的 admin、set、inherit 属性。
  • 编辑、序列化与 CMDB 导出保留可能被 YAML 消费端解释成数字、日期或时间戳的字符串。 已有时间戳标量保留原始源码表示。独立 PyYAML 检查验证输出仍为字符串类型。
  • sty conf --proxy 接受 HTTP、HTTPS、ALL、NO 代理变量的大写与小写形式；HTTP、HTTPS 缺失时都会回退到 ALL_PROXY。版本补全按点分段匹配，指定 1.1 不会误选 1.10。

详情见 Inventory 来源选择与 pig sty。

软件仓库与扩展

  • 仓库命令在改文件前验证完整操作数列表。空值、逗号列表中的空项、不安全的仓库名在修改前失败。 只有真正不带参数的 repo rm 才备份全部仓库文件；repo rm all 展开为 node、pgsql、 infra 三个模块。删除结果保留原始请求，区分不存在的目标和实际删除的文件。 备份全部仓库后也会按 --update 刷新缓存。
  • 创建仓库时保留文档 RPM。调试包仍通过 --nodbg 排除，包名含 -docs 或 -doc 本身不会将其判为调试包。
  • 默认扩展列表、可用性摘要、刷新结果统计全部目录记录，包括 SQL 工具和保留的生命周期记录。 总数表示目录覆盖范围，不表示某台主机可以安装或能通过 CREATE EXTENSION 启用的扩展数。
  • 文本、JSON、YAML 共用可用性规则。已覆盖的 Linux 平台以包矩阵为准，矩阵缺项即不可用， 架构别名统一处理。macOS 状态仅表示声明的 PostgreSQL 版本支持，不承诺存在 RPM/DEB 包。 ext list -v 选择判断状态时使用的版本，不会过滤掉不可用记录。
  • ext import 在任何请求包无法解析或下载时返回失败，同时保留已成功下载的文件，报告完成与 失败部分。APT 虚拟依赖标记不再进入下载包名列表。已安装库扫描也能识别没有控制文件的目录条目。
  • 目录新增 pg_icu_parser、pg_vectorsearch、textsearch_intl 三条记录，同时刷新已有条目的 版本和平台元数据。安装前可用 pig ext avail NAME 检查目标。

详情见 pig repo与 pig ext。

构建与自动化

  • 多版本构建依赖按每个选定的 PostgreSQL 大版本展开包名，去重后安装。默认构建目标继续遵循 扩展元数据与本地安装规则，不会因包矩阵缺包而丢失。
  • Debian/Ubuntu 构建保留继承的 PATH 顺序，当前用户的 ~/.cargo/bin 存在时追加到末尾， 保留用户已选工具链的优先级。
  • Xray 设置识别完整旧服务定义，包括旧渲染器生成的无 marker macOS plist。 注释本身不能证明归属；被修改或外来的定义仍需要显式替换。配置一致的重复执行保留运行中的服务。
  • JSON/YAML 输出及 PIG_NON_INTERACTIVE=1 在 PIG 管理的适配器中一致禁用提示输入， 使用非交互 sudo。明确的数据输入通道仍可用；原生 Patronictl 转发保留交互和退出契约。
  • CMDB 连接串、旧 VMess 凭据、许可证密钥不会进入常规参数与失败详情。 显式凭据导出与 Inventory 原文显示保留文档约定的敏感输出行为。
  • Exporter HTTP 4xx/5xx 返回失败，仅包含数字状态码与标准说明，不包含响应体或自定义状态文本。 pig update 在不支持的平台上明确报错。命令帮助与中英文参考文档同步校准。
  • 更新 Go 依赖与验证工具。CI 增加 Linux 权限、实例边界和独立 YAML 消费端验收。

详情见 pig build、pig pe与全局命令行为。

升级注意事项

已有命令名和参数继续可用。自动化脚本需要处理部分导入失败、HTTP 错误、恢复取消和 PostgreSQL 状态无法确定时纠正后的失败状态。仓库操作数必须有效，需要确认的操作仍须显式确认， 维护命令应传入数据库名称。名称以 - 开头时，把全部选项放在前面，再写 -- 和数据库名。

按安装文档升级。

v1.10.0 ·