PostgreSQL 博览 2026-08-14 RSS 订阅

PostgreSQL 18 的异步 I/O 落地后，由谁执行 I/O 取决于 io_method 和 io_workers。sync 退回同步行为，只用于排查；默认的 worker 走后台进程池；io_uring 交给 Linux 内核最快，但需要 liburing 构建与放行的安全策略，容器里常被禁止，此时服务器会直接启动失败。io_workers 默认 3、上限 32，可在线调整，冷读负载建议提到 CPU 线程数的四分之一到一半。

work_mem 按操作而非按查询生效，一条语句里的多个排序、哈希节点各占一份，哈希节点还要乘 hash_mem_multiplier，预估总量没有趁手工具。作者用 raw_parser() 解析、planner() 生成计划，再遍历计划树累加倍率乘上 work_mem 得到最坏情况，做成扩展 querymem 挂在 ExecutorStart 钩子上，可记日志或拒绝超限查询。在 pgbench 上，含两个哈希的连接估到 28 MB。

TimescaleDB 的连续聚合靠 invalidation 日志和定时刷新保持同步，start_offset 是回溯窗口，end_offset 是新鲜度下限。Damaso Sanoja 指出一个容易忽略的坑：迟到写入若落在已物化且超出回溯窗口的 bucket 上就永远不会重算，聚合结果静默保持错误值，而 real-time aggregation 只覆盖 watermark 之后尚未物化的部分，救不了这种情况。

PostgreSQL 19 计划引入的 MERGE/SPLIT PARTITIONS 在合并拆分时会静默丢弃分区级属性，包括 RLS 策略、ACL、索引等。多位审阅者认为静默丢弃 RLS 是安全隐患，文档也只用「等等」一笔带过。Alexander Korotkov 提议 pg19 先对涉及 RLS 的操作直接报错，完整支持推迟到 pg20，实现该检查的补丁已经提交。

Andrey Borodin 的 WAL 压缩补丁系列更新到 v9：复用 zstd 上下文加快压缩解压、在按 FPI 压缩之外增加整条记录压缩，跨记录流式压缩仍在开发。审阅者指出 v8 与新提交冲突。v9 完成变基，修掉 EXEC_BACKEND 下 XLOGShmemAttach() 的 Windows bug，文档同步注明 wal_compression = on 默认优先选用 zstd。