PostgreSQL JIT 排障：两个开关定位编译 bug

PostgreSQL 的 JIT 编译器承担两项工作：编译表达式和元组变形（tuple deforming）。jit_expressions 和 jit_tuple_deforming 这两个布尔参数分别控制这两项功能，默认开启，属于 Developer Options 类别，官方文档明确警告不建议在生产库上修改。

表达式编译把执行器对 WHERE 子句、目标列表、聚合转换的解释执行替换为针对具体表达式生成的原生代码。元组变形则是在此之前，把存储元组的压缩字节转换为执行器所需的 datum 和 null 数组。JIT 会为特定元组描述符生成专用变形函数，省去通用逻辑。

这两个参数看似对称，实则不然。关闭 jit_tuple_deforming 后，JIT 块中只是少了变形函数；但关闭 jit_expressions 后，整个 JIT 块完全消失——因为变形代码只在编译消费它的表达式过程中生成，没有表达式编译就无处挂载变形器。

这正是它们作为排障工具的价值：怀疑 JIT 导致崩溃或结果错误时，先 SET jit = off 确认问题是否消失；再开启 JIT 并关闭 jit_tuple_deforming，若问题解决则变形编译器是元凶，否则就是表达式编译器。两个开关、三种结果、一个嫌疑对象，全程无需重启。

注意这不是调优旋钮。若 JIT 编译开销大于收益，应调整成本阈值或直接关闭 JIT，而不是逐个关功能。日常保持两者开启，排障时用 SET 临时切换即可。

#DevOps #运维 #PostgreSQL #JIT #数据库 #性能调优 #故障排查
@DevOpsTalkCN

pgsonify：把 PostgreSQL 健康状态变成大象叫声

一个实验性的 MIT 许可开源工具，用真实大象录音来“播放” PostgreSQL 的健康状态。它监控实例，将指标实时映射为声音：一切正常时是低沉的隆隆声，出问题时则是喇叭声。作者明确表示，这是面向本地、开发与 QA 环境的实验，用于培养对数据库负载行为的直觉，而非替代正式监控。

工具用 Go 编写，声音来自已发表的生物声学研究录音。它通过一个 [0, 1] 区间的连续压力分数驱动三种状态：平静（深沉缓慢的隆隆声）、警报（音调与脉冲率上升，伴随短促喇叭声）、恐慌（快速混乱的喇叭声）。每种具体问题都有独立声音：锁等待与长事务是咕噜声，临时文件溢出是喷鼻声，复制延迟与 XID 回卷是联络叫声，WAL 压力导致的检查点是沉重脚步声，死锁与连接饱和则是恐慌喇叭声。控制台会同步打印触发声音的指标与阈值。

映射逻辑基于标准统计视图，无需扩展或超级用户权限。启动时读取 pg_settings 建立声音基线（如 shared_buffers 越大，隆隆声越低），默认每 5 秒采样 pg_stat_activity、pg_locks、pg_stat_database 等视图。检查点计数器按版本区分：PG 17+ 用 pg_stat_checkpointer，更早版本用 pg_stat_bgwriter。复制状态在主库读 pg_stat_replication，在备库读 pg_last_wal_replay_timestamp()，角色由 pg_is_in_recovery() 判断。

早期版本用合成大象叫声，效果很差。当前版本使用开放许可的真实野外录音：警报声来自 King et al. 2010（PLOS ONE, CC BY 2.5），喇叭声来自 Fuchs et al. 2021（PLOS ONE, CC BY 4.0），另有 Wikimedia Commons 与 Freesound 的 CC0 录音。一个诚实的例外：真实大象的隆隆声多为次声波（约 20-30 Hz），笔记本扬声器无法还原，因此连续背景隆隆声是在可听频段合成的，事件叫声则全部为真实录音。

仓库附带 pgchaos 负载生成器，可故意触发连接激增、锁队列、死锁、临时文件溢出、回滚风暴、idle-in-transaction 等场景，几分钟内听完全部声音。make demo 可用 Docker 一键启动 postgres + pgchaos。Herd 模式支持通过多个 -dsn 参数连接主库与备库，每个实例有独立音高与立体声位置，可听出是哪台服务器在报警。兼容性经过实测：PG 10 到 18 每个版本线均通过端到端冒烟测试。

作为监控工具它替代不了 Prometheus 和告警系统，但作为理解数据库负载响应（锁队列如何堆积、检查点风暴如何跟随 WAL 突发、部署出错时回滚率如何飙升）的辅助手段，它能让数据库行为变得可感知，适合演示与教学场景。

GitHub

#DevOps #运维 #PostgreSQL #pgsonify #可观测性 #数据库运维 #开源工具 #声音监控
@DevOpsTalkCN

PostgreSQL JIT 阈值：按成本触发，但成本衡量的不是表达式复杂度

PostgreSQL 的 JIT 编译是否触发，取决于规划器对查询的估算成本，而这个成本衡量的是数据量，不是表达式复杂度。jit_above_cost（默认 100000）、jit_inline_above_cost（默认 500000）和 jit_optimize_above_cost（默认 500000）三个 GUC 决定 JIT 何时启动，全部以规划器成本单位计价（seq_page_cost = 1.0 为锚）。成本超过 jit_above_cost 就编译表达式和元组反序列化；超过 jit_inline_above_cost 还内联内置函数和操作符；超过 jit_optimize_above_cost 再跑 LLVM 优化。任一设为 -1 即禁用该层，jit_above_cost = -1 直接关掉整个 JIT。

这个设计有三个叠加后果：决策基于估算成本，误估可能让一个 2 毫秒的查询也触发编译；编译结果不缓存，每次执行、每个进程、每个并行 worker 都各自编译一份；成本单位衡量的是页数和行数，而 JIT 的收益取决于表达式执行次数和复杂度——两者只在 JIT 设计目标场景（大扫描 + 重谓词）下相关，其他场景基本无关。

实测演示（默认配置，未调任何参数）：550MB 表分 64 个 hash 分区，跑最简单的 SELECT sum(id)，估算成本 112620 超过阈值，JIT 触发。64 个扫描节点导致编译了 130 个函数（未分区版本只需 5 个），每次执行都付编译费。同一查询 jit = off 时热执行 844–878ms，开 JIT 后 871–938ms 外加 36–49ms 编译——JIT 收了入场费但没加速任何东西，因为 sum(id) 几乎没有表达式工作可加速。分区是典型放大器，同时抬高估算成本和函数数量；任何成本来自数据量而非表达式复杂度的查询都吃同样的亏。阈值全设为零强制触发时，编译耗时 2.8 秒内联 + 0.25 秒优化（并行 leader 加两个 worker 合计），只为加速一个执行仅 1.3 秒的查询。

是否受影响一条 SQL 就能查：PostgreSQL 15 起 pg_stat_statements 带每条语句的 JIT 计数器，对比 jit_generation_time + jit_inlining_time + jit_optimization_time + jit_emission_time 与 total_exec_time，若事务型负载中 JIT 耗时占比明显，就是在为不需要的查询付编译费。

结论不是调阈值——阈值衡量的东西本身就不对，移动它们只是挪动错误生效的位置。应在工作负载层面决策：事务库 ALTER DATABASE oltp_db SET jit = off，数仓库 jit = on，两边都不用重启。单库混合负载时把 jit_above_cost 提高一个数量级是可行的粗暴方案；把两个 500000 阈值拆开几乎不值得。唯一绝对不该做的是调低任何阈值——默认值已经会让分区 sum(id) 触发 JIT，不需要再鼓励。

#DevOps #运维 #PostgreSQL #JIT #性能调优 #数据库 #LLVM #pgstatstatements
@DevOpsTalkCN

CNCF 治理指南：按项目规模与阶段选对治理结构

CNCF 技术监督委员会基于 72 个毕业、孵化及归档项目的治理审查，总结出不同成熟度阶段的结构选择规律。数据显示，进入沙箱时维护者来自多个组织的项目，毕业率是单一组织项目的 2.07 倍（59.1% 对 28.6%）。仅有书面治理文档而缺乏结构性机制，往往挡不住权力集中——多个治理文档写得不错的项目，最终仍因缺少组织平衡投票或指导委员会限制而出现维护者集中。

数据还显示，20% 的毕业项目在毕业后出现治理集中，且这些项目在孵化期都缺少组织平衡机制。一个已归档的孵化项目在治理委员会设了组织多样性规则，维护者层面却没有。组织平衡机制要覆盖实际干活的地方，而不只是治理层。贡献者数量本身不能预测项目健康度，治理结构、组织多样性和贡献者路径更重要。

项目模板仓库提供三种治理模型：

1. 维护者委员会：适合范围聚焦、单一仓库或小规模紧密协作的项目。3-10 名活跃维护者直接沟通，默认懒共识决策，分歧或治理变更时正式投票。关键要素包括 MAINTAINERS 文件、维护者增删流程、荣休状态、安全响应团队。当单一组织通过招聘、收购或外部贡献者流失主导维护者名单时，应考虑引入组织平衡投票或转向选举制指导委员会。

2. 选举制指导委员会：适合贡献者社区成熟、领导层需对社区负责的大型项目。委员会由合格贡献者选举产生，负责战略方向，技术工作下放给工作组或 SIG。任期限制（通常 1-2 年）和公司代表上限（每组织不超过 1-2 人）保障视角多样性。将治理与执行分离的项目能更长久维持组织多样性，因为委员会的组织限制独立于代码贡献者构成。项目收缩或委员会职责重叠、协调成本高于决策收益时，合并冗余机构、减少席位是正当的治理转型。

3. 联邦式子项目治理：适合由多个半独立子项目组成的伞形项目。各子项目有自己的维护者和发布节奏，指导机构负责共享基础设施、品牌、安全响应和子项目间冲突解决。需要明确的子项目增删流程、健康标准和生命周期（活跃/维护/归档）。失去活跃贡献者或已完成使命的子项目应归档或合并，空壳 SIG 会造成治理广泛的假象，实际工作却集中在少数群体。

组织投票是可与任何模型配合的结构性机制：按组织而非个人分配治理投票权，通常每组织限 1-2 票，防止单一公司靠维护者人数主导治理。它保护治理决策，但不保证维护者构成平衡——多数维护者仍可来自一家公司，只是这种多数不会转化为相应的治理控制权。实践中该机制适用于指导委员会选举、治理变更和战略方向，技术决策（代码审查、合并权限、发布）仍由维护者在懒共识下处理。超过两票的上限已被证明无效。

对正在选型或演进治理结构的项目，核心判断是：结构要与当前规模匹配，文档之外要有硬性机制兜底，且治理结构要能随项目收缩而简化。

#DevOps #运维 #CNCF #开源治理 #Kubernetes #云原生 #社区管理
@DevOpsTalkCN

Kubeflow 正式毕业，成 CNCF 首个 AI 原生毕业项目

CNCF 宣布 Kubeflow 从孵化项目正式毕业，成为云原生 AI/ML 平台在 Kubernetes 上的事实标准。该项目覆盖数据预处理、交互式开发、分布式训练、微调、推理与模型服务全生命周期，支持公有云、私有云与混合云环境。

Kubeflow 于 2017 年在 Google 诞生，2023 年进入 CNCF 孵化。目前拥有超过 6600 名贡献者、来自 1000 多家组织，GitHub 累计星标超 33000，Python 包在 PyPI 下载量近 2.6 亿次。Bloomberg、NVIDIA、Red Hat、LinkedIn、Spotify 等企业均在其上标准化 AI 工作负载。

毕业前，Kubeflow 完成了第三方安全审计，成立了正式指导委员会，并采用 CNCF 行为准则，同时持有 CII 最佳实践徽章。

项目与 CNCF 生态深度集成：Prometheus 负责监控，KServe 处理模型服务，Feast 管理特征存储，Kueue 做任务排队，Istio 保障服务间安全通信。

后续路线图聚焦扩展 LLM 编排、增强微调等后训练能力、大规模数据工程，以及面向 Data & AI 生命周期的 agentic 工作负载。

对平台团队而言，Kubeflow 毕业意味着 AI 基础设施选型有了一个经过 CNCF 治理体系验证的 Kubernetes 原生底座——跨云可移植、厂商中立，适合需要把 AI 工作负载从实验推向生产的组织。
@DevOpsTalkCN

Flyway validate 绿了，不代表库和迁移一致

很多人把 flyway validate 通过当作「数据库和迁移文件一致」的证据，这个结论不成立。validate 只做文件完整性校验：对本地迁移文件重算 CRC32 校验和，和 flyway_schema_history 表里存的比对，再检查已应用的迁移是否还在、有没有待执行的迁移。

它从不看真实 schema。手动在库里执行 ALTER TABLE、别的工具加了索引、事故中有人删了约束——这些都不会改文件和历史表，validate 照样绿。repair 也一样，只修历史表，不碰 schema。

真正的漂移检测在 Flyway 里是付费能力：check -drift 用快照对比目标库和迁移应产生的状态，还能在每次成功部署后用 -saveSnapshot 存快照，下次运行发现库外变更，甚至可以直接中止部署。PostgreSQL 有 Community Drift Check，但结果要通过 Redgate 的托管服务 Flyway Pipelines 查看。

Liquibase 免费层更慷慨：diff 对比两个库或库与快照，diff-changelog 能生成修复用的 changeset，都在开源版里。但官方文档明确说 diff-changelog 输出需要人工检查，部分对象和依赖无法自动表达；把「发现意外对象」变成 CI 退出码这类策略能力是 Pro 功能。Liquibase 5.0 已把 OSS 和 Pro 拆成独立发行版，OSS 核心被精简，扩展改为按需安装。

结论：大家都在跑的 validate 查的是文件不是 schema，真正查 schema 的命令要么付费、要么绑托管平台、要么有 setup 成本。漂移检测在多数团队里「技术上可用，实际上没人跑」——没人 nightly 跑，没人部署前跑，第一次跑往往是在事故复盘时。绿色 validate 只说明文件和历史一致，不是数据库的证据。

#DevOps #运维 #Flyway #Liquibase #数据库迁移 #SchemaDrift #PostgreSQL #CICD
@DevOpsTalkCN

Kubeflow 正式毕业，Kubernetes 上跑 AI 有了 CNCF 最高级别背书

CNCF 宣布 Kubeflow 正式毕业，这是该开源 AI/ML 平台获得的最高成熟度认定。Kubeflow 运行在 Kubernetes 上，覆盖数据处理、模型开发、分布式训练、微调、推理和模型服务等 AI 工作负载，支持公有云、私有云和混合环境部署，避免 AI 运维绑定单一厂商。

项目数据方面，Kubeflow 的 Python 包在 PyPI 上累计下载近 2.6 亿次，来自 1000 多家组织的 6600 多名开发者参与贡献，GitHub 星标超 3.3 万。NVIDIA、Red Hat、Spotify、Bloomberg 等公司都在使用其子项目。Kubeflow 2017 年始于 Google，2023 年进入 CNCF 孵化。

毕业意味着项目通过了独立安全审计、建立了正式指导委员会，并持有 Core Infrastructure Initiative 最佳实践徽章。平台与 Prometheus、KServe、Feast、Kueue、Istio 等云原生组件集成。

路线图已指向企业 AI 最吃算力的方向：加强 LLM 编排、训练后处理与微调、高级数据工程和 AI Agent 支持。Kale 2.0 SDK 计划把带注解的 Jupyter notebook 转成生产流水线并支持 Apache Spark；KServe 将支持通过 OpenAI 兼容 API 做分布式 LLM 推理；Kubeflow Notebooks v2 正围绕声明式架构重做，目标是改善安全性和多租户隔离。

对运维团队来说，这意味着 AI 工作负载的交付路径正在向 Kubernetes 生态收敛。如果公司已经在用 K8s 管理容器化应用，Kubeflow 毕业意味着这套基础设施可以顺理成章地延伸到 AI 全生命周期，而不必为 AI 单独引入一套专有平台。

#DevOps #运维 #Kubeflow #Kubernetes #CNCF #MLOps #LLM #KServe
@DevOpsTalkCN

多平面架构：把云主权从“选区域”变成“控边界”

讨论云主权时，大家常从区域说起：工作负载跑在哪、数据存在哪。但选区域只是故事的一部分，平台架构同样关键——尤其是如何跨集群分离控制、运行时、构建和可观测性职责。

在欧盟数据法案、NIS-2、DORA 和英国数据使用与访问法案等监管下，平台团队不仅要说明工作负载运行位置，还要证明平台如何被运营、保护和治理，直至控制平面。审计方真正关心的问题几乎都与位置无关，而是：控制权和状态在哪里、谁能触达它们。

单一共享 Kubernetes 集群很难干净地回答这些问题：一个 API server、一个 etcd、一套控制器和准入 webhook 服务所有租户，审计时难以指出清晰的架构边界。租户集群模式通过给每个边界独立的控制平面解决此问题，而多平面平台则在更高一层解决同一问题，两者可协同工作。

OpenChoreo（CNCF Sandbox 项目，开源内部开发者平台）将平台拆分为多个平面，每个平面是独立集群，有自己的生命周期、扩缩容行为和安全边界：控制平面通过声明式 API 持有期望状态并运行协调控制器，不运行租户工作负载；数据平面是运行工作负载的合规 Kubernetes 集群，各有独立 API server 和状态；可观测性平面收集并提供日志、指标和链路；工作流平面执行 CI 和 GitOps 流程；体验平面提供开发者门户、CLI 和 API/MCP 接口。

对主权而言，连接模型是最关键的细节：数据、可观测性和工作流平面各自向控制平面网关发起出站、双向认证（mTLS）连接，控制平面从不主动拨入。这带来两个结果：持有受监管工作负载的集群 API server 永不暴露到互联网；控制平面持有期望状态而非租户运行时状态，数据平面即使失去与控制平面的连接也能继续服务流量。

这套拓扑如何回应审计问题？采用“一个司法辖区一个数据平面”模型，答案可直接体现在架构中。每个数据平面向区域可观测性平面报告，门户直接查询该平面，遥测不绕经控制平面，租户运行时状态和日志都不离开所在区域。每个数据平面是完整合规的 Kubernetes 集群，断开连接也能运行，底层基于 Argo Workflows、Cloud Native Buildpacks、OpenSearch、Prometheus、OpenTelemetry、Flux、cert-manager、Cilium 等开源项目，无单一托管服务处于关键路径。出站-only mTLS 模型使敏感集群无法从互联网触达，密钥存放在团队选择的 External Secrets Operator 兼容存储或 vault 中，授权细粒度到命名空间、项目和组件级别。工作负载以标准 Kubernetes 资源表示，可在公有云、本地或裸金属上运行，环境间提升是一等概念，更换基础设施只是拓扑变更而非迁移项目。

平台层与基础设施层的结合也值得关注：租户集群模式在基础设施层给每个租户虚拟控制平面（运行在共享宿主集群内的独立 API server 和数据存储），租户间互不可见、互不影响，成本远低于专用集群。但它不决定司法辖区边界——这正是多平面平台层补充的部分。两种模式解决主权问题的不同层面，可叠加使用。

#DevOps #运维 #云原生 #Kubernetes #多平面架构 #云主权 #OpenChoreo #CNCF #mTLS #数据驻留
@DevOpsTalkCN

Postgres 19 旧建议哪些仍有效，哪些该更新

Crunchy Data 回顾了多年来关于数据加载、存储、索引和分区的建议，对照即将发布的 Postgres 19 逐条验证。结论是核心建议没变，但实现路径大幅改善：异步 I/O、更抗错的 COPY、默认 LZ4 压缩、更丰富的 BRIN 形状、skip scan 和更顺滑的分区操作。

异步 I/O 与并行维护

Postgres 18 引入异步 I/O，后端可排队多个磁盘读取而不用逐个等待，顺序扫描、bitmap heap scan 和 vacuum 都受益。社区基准测试显示冷存储上最高约 3 倍提升。19 在此基础上让 I/O worker 可自动扩缩（io_min_workers / io_max_workers），并新增并行 autovacuum worker（autovacuum_max_parallel_workers）。注意 JIT 在 19 中默认关闭，大型分析查询若依赖它需显式开启并复查执行计划。

COPY 更抗错
19 用 SIMD 加速文本/CSV 解析，新增 ON_ERROR SET_NULL（坏字段置 NULL 而非丢整行）、跳过多个表头行、COPY TO 直接输出 JSON 且可带 FORCE_ARRAY，还能直接导出分区父表。配合 17 的 ON_ERROR ignore 和 18 的 REJECT_LIMIT，脏数据导入不再需要预清洗。

TOAST 默认 LZ4
19 起 default_toast_compression 从 pglz 切到 lz4，新写入的 toasted 值自动用 LZ4，无需额外配置。升级后旧值保持原算法，可用 pg_column_compression() 确认。19 还引入原生 REPACK（CONCURRENTLY 模式），重写表不再需要长时间排他锁，但需主键或基于索引的 replica identity，且不能在分区父表上运行，期间需约 2 倍表空间。

BRIN 与覆盖索引
BRIN 在 14 获得 minmax_multi 和 Bloom opclass，17 支持并行构建，19 主要继承异步 I/O 收益。覆盖索引方面，18 的 skip scan 让多列索引在省略前导列时也能被使用，低基数列（status、region、tenant）场景可考虑删掉多余的独立索引。

分区操作更顺滑
19 新增原生 MERGE PARTITIONS / SPLIT PARTITION，可直接在 SQL 里合并或拆分分区。但两者都持 ACCESS EXCLUSIVE 锁且物理复制元组，高吞吐表建议仍用 CONCURRENTLY detach/attach 做在线轮转。COPY TO 现在可直接作用于分区父表，省掉 SELECT 包装的开销，逻辑复制的初始同步也受益。

升级后用 EXPLAIN (ANALYZE, BUFFERS, IO) 重新验证执行计划，尤其是 BRIN 与并行顺序扫描的对比。旧建议的骨架仍然成立：批量加载用 COPY、JSON 存 jsonb、按需建 GIN 索引、热数据别塞 TOAST、分区优先服务生命周期管理。

#DevOps #运维 #Postgres #Postgres19 #数据库 #索引 #分区 #COPY #TOAST #BRIN
@DevOpsTalkCN

CNCF 项目治理选型指南发布

CNCF TOC 基于 72 个毕业、孵化与归档项目的治理审查，发布了一份项目治理结构选型指导，帮项目按规模和阶段选择或调整治理模式。

数据层面的几个发现：
进入沙箱时维护者来自多个组织的项目，毕业率是单一组织项目的 2.07 倍（59.1% 对 28.6%）。
有指导委员会或组织平衡投票机制的项目，维护者多样性维持得更久；仅靠写得很好的治理文档，往往挡不住权力集中。
20% 的毕业项目在毕业后出现治理集中化，且这些项目在孵化期都缺少组织平衡机制。
贡献者数量本身不能预测项目健康度，治理结构、组织多样性和贡献者路径更关键。

模板仓库提供三种治理模型：
1. Maintainer Council（维护者委员会）：适合范围聚焦、3-10 名活跃维护者的小项目，维护者自选、懒共识决策，代码与治理不分家。当单一组织通过招聘、收购或外部贡献者流失主导维护者名单时，就该考虑加组织平衡投票或转向选举制。
2. Elected Steering Committee（选举制指导委员会）：适合贡献者社区较大、需要向社区负责的项目。委员会由合格贡献者选举产生，设任期（通常 1-2 年）和公司代表上限（每组织 1-2 人），技术工作下放给工作组或 SIG。治理与执行分离，组织多样性维持得更久。
3. Federated Subproject Governance（联邦式子项目治理）：适合由多个半独立子项目组成的伞形项目，各子项目自治，指导机构负责共享基础设施、品牌、安全响应和冲突仲裁。失去活跃贡献者或范围已完成的子项目应归档或合并，而不是留空壳。

组织投票是可与任一模型搭配的结构机制：按组织而非个人分配治理票，每组织通常限 1-2 票，防止单一公司靠维护者人数主导治理。它保护的是治理决策，不保证维护者构成平衡——多数维护者仍可来自一家公司，只是无法转化为成比例的治理控制权。技术决策（代码评审、合并、发布）仍由维护者按懒共识处理。

对维护或参与开源项目的团队，这份指导的价值在于：治理结构要匹配项目当前规模，该简化时简化，该加组织平衡机制时别只靠文档。

#DevOps #运维 #CNCF #开源治理 #云原生 #组织投票 #开源项目 #治理模型
@DevOpsTalkCN