标签

PostgreSQL

PostgreSQL data_checksums:一个只读 GUC 背后十三年的数据完整性故事

来源: postgr.es 40
在 PostgreSQL 里, 只会返回 或 ——和 一样,它是个只读的预设参数,初始化集群时就定了,之后无法通过 修改。但这个看似平淡的开关,背后是一场持续了十三年、至今仍在演进的数据完整性战役。 PostgreSQL 的数据文件由一个个固定大小的页面(默认 8KB)组成。每次读写页面时,操作系统和硬件并不保证内容完好——磁盘静默损坏、内存位翻转、内...

在 Kubernetes 里跑 PostgreSQL 19 Beta:用 CloudNativePG 快速上手

来源: postgr.es 49
PostgreSQL 19 已进入 beta 阶段,社区开放了 beta 测试计划,邀请用户提前验证新特性与兼容性。如果你的工作负载已经跑在 Kubernetes 上,CloudNativePG operator 是目前最顺手的路径——它原生支持指定 PostgreSQL 版本镜像,一条声明就能拉起一个完整的 PG 集群,不需要手动拼 PVC、Conf...

PostgreSQL 补丁为什么没人审——以及你可以怎么做

来源: postgr.es 32
三月份,Lucas Draescher 向 PostgreSQL 提交了他的第一个补丁,修复了使用 时文件描述符泄漏的问题。补丁干净、动机明确,已经迭代到第三版。然后它在 commitfest 里静静躺了两个月——零评审。 这不是例外,这是常态。PostgreSQL 靠志愿者运转,核心提交者人数有限,补丁队列却很长。一个写得不错的补丁等上几个月没人看,...

文件描述符耗尽:那个把 PostgreSQL 拉垮的内核限制

来源: postgr.es 58
大多数被归咎于"数据库挂了"的 PostgreSQL 宕机,真正的故障点在更底层——内核的文件描述符(file descriptor)用完了,PostgreSQL 只是第一个倒下的进程。这篇文章拆解整个故障链路:从连接数膨胀到 FD 耗尽,从日志特征到诊断命令,再到根治方案和临时止血手段。 Linux 内核把几乎所有 I/O 对象都抽象为文件描述符:T...

pgBackRest + pg_tde:加密数据库的备份还原实测

来源: postgr.es 39
Percona 之前发过一篇博客,说 pgBackRest 配合 pg_tde(透明数据加密扩展)时,异步归档不可用——原因是对加密的 WAL 段做归档会出问题。Stefan Fercot 在会议走廊里听到这个说法后觉得不对劲:pgBackRest 应该能透明处理加密 WAL。于是他亲手搭了一套环境跑了一遍,结论是:异步归档完全可用,之前说的限制并不成...

PostgreSQL 游标查询的隐藏代价:cursor_tuple_fraction 如何拖慢全量扫描

来源: postgr.es 42
在 PostgreSQL 里声明一个游标(cursor)然后逐行 fetch,看起来是再正常不过的操作。但很多人没意识到:一旦查询走游标路径,优化器会默认假设你只打算读取结果集的 10%,并据此选择"快速返回前几行"的执行计划。如果你实际上会把游标拉到底,这个假设会让整条查询跑得比普通 SELECT 还慢。 PostgreSQL 对普通 和游标查询的规...

TimescaleDB 2.27.2:压缩策略与刷新策略冲突的修复,建议尽快升级

来源: oschina.net 50
TimescaleDB 作为 PostgreSQL 扩展,让时序数据既能享受自动分区(hypertable)的性能红利,又不丢失完整的 SQL 能力。但 2.27.1 中一个策略管理缺陷可能导致数据刷新静默失效——2.27.2 修复了这个问题,官方建议尽快升级。 核心修复是 issue #9895:当用户对 hypertable 添加列存储(colum...

PostgreSQL 19 的 SQL/PGQ:在关系表上直接写图查询

来源: postgr.es 32
关系数据库里存的是表,但很多业务问题本质上是图——"谁认识谁的朋友"、"订单经过哪些环节流转"。过去要么把数据导到专门的图数据库,要么手写多层 JOIN 把自己绕晕。PostgreSQL 19 引入了 SQL/PGQ(ISO/IEC 9075-16 (2023) 标准),让你在现有的关系表上定义图语义,然后用图模式匹配语法来查询。不需要安装扩展,不需要...

pg_stat_statements 的沉默盲区:那些它看不到、记不住、悄悄丢掉的东西

来源: postgr.es 44
每个用 PostgreSQL 的人都会开 。它便宜、即时、不用装额外组件——查一下就知道哪个查询最慢、哪个调用最多。但用久了你会发现一些诡异的事:昨天还在列表里的关键查询今天消失了;p99 突然飙升但平均值纹丝不动;一个跑了 30 秒然后超时崩溃的查询,在视图里根本找不到踪迹。 这些不是 bug,而是 作为"一堆聚合计数器"的固有边界。上一篇文章讲了它...