PostgreSQL 博览 RSS

AI 写出来的 SQL 看着对，却不知道生产库长什么样。Radim Marek 举了 2025 年 7 月的例子：一个编码代理在封网期抹掉了生产库，随后还谎报经过；更常见的是锁表迁移、基于错误假设的查询和凭感觉加的索引。他还提到 Anthropic 的参考 PostgreSQL MCP 服务器曾因允许分号而被 SQL 注入。他给的路子是离线优先：把模式与统计导成 JSON 快照提交进版本库并每晚更新，让代理拿到结构而不碰生产连接。

PAX 把页内数据按列切成 minipage，定长列用位图加密集数组，变长列用偏移数组，为的是减少缓存污染。Lætitia AVROT 指出这套设计和 PostgreSQL 的 MVCC 打架：论文里删除要立刻压紧 minipage，而 PostgreSQL 必须把旧版本行留在原地。她提出单独留一个存放 xmin、xmax、ctid 的元数据 minipage，删除时只做标记。文章没有基准数据，也还不是补丁。

要给分析备库、QA 和沙箱送生产数据，又不想让它们连上主库。Richard Yen 建议回到 PostgreSQL 8.2 就有的日志传送：用 archive_command 把 WAL 推到集中归档，各消费端用 restore_command 取回并持续恢复。他把这个集中归档叫作 WAL Hub。这样不占复制槽，也没有流复制的背压；代价是有一点延迟，备库不会出现在 pg_stat_replication 里。

Doug Pagnutti 用工业物联网负载测了加硬件的边界。当索引超出内存之后，再加内存和 CPU 对写入几乎无益，瓶颈落在磁盘 I/O 上，而索引更新基本是串行的，用不上多核。查询这边完全不同：内存变大能缓存数据并在内存里建哈希表，多核能让聚合走并行，收益明显。结论是靠硬件优化查询有效，救摄取无效；摄取吃紧时应考虑 TimescaleDB 这类专用时序方案。

pg_clickhouse 让 PostgreSQL 直接查询 ClickHouse。0.1.10 把 JSON 与 JSONB 的 -> 和 ->> 映射成 ClickHouse 的子列语法下推，补上 clock_timestamp 等时间函数，并支持 ROW_NUMBER、RANK、LEAD、LAG 等一批窗口函数。HTTP 驱动改为流式返回结果集，读 1GB 表时内存峰值从 1GB 以上降到 73MB。

从 ctid 里取块号，此前只能写成 (ctid::text::point)[0] 这种绕路的写法。Andres Freund 推送了 tid_blockno() 与 tid_offset() 两个访问器函数，把这件事变成一次普通的函数调用；提交前他做了小幅调整，包括在文档里把 TID 从类型标记改为缩写标记，因为 TID 并不是真正的类型名。他自己在做性能验证、需要从索引扫描里取块号时又撞上这个限制，才把补丁推完。