标签

PostgreSQL

PostgreSQL 16 的 createrole_self_grant:给 CREATEROLE 权力画一条边界

来源: postgr.es 34
PostgreSQL 的 权限长期以来是个"准超级用户"——拥有它的人几乎可以做任何事:创建任意角色、给自己授予新角色的成员身份、继承新角色的全部权限。这条从角色创建到权限膨胀的路径,在 PG16 被正式切断。核心手段之一就是新增的 GUC 参数 。 在 PG15 及更早版本中,一个只有 权限(没有 )的用户可以做这样的事: 创建角色的那一刻,创建者自...

pg_stat_statements:你以为的查询商店,其实是一张计数器哈希表

来源: postgr.es 43
大概是 PostgreSQL 生态里最常用的扩展之一。它随 contrib 一起发布,开启成本几乎为零,大多数人的第一反应就是——"数据库到底在干什么?"打开它看一眼,心里就有底了。 但如果你是从其他数据库过来的,可能会期待它像一个真正的 Query Store:记录每条查询的执行历史、保留计划演进、能按时间窗口回溯。它不是。 一旦你深度依赖它,就会发...

Azure Database for PostgreSQL Flexible Server:同步复制 standby 置入提交路径意味着什么

来源: postgr.es 45
大多数托管 PostgreSQL 服务商把 standby 复制做成"尽力而为"——写主库成功就返回客户端,standby 在后台异步追赶。Azure Database for PostgreSQL Flexible Server 走了一条不同的路:standby 直接参与提交路径,每一次写操作都要等同步复制到第二台服务器确认后才向客户端返回成功。 这...

DeepChat → DeepWork:从聊天工具到数字员工的技术重构

来源: oschina.net 34
从 OpenClaw 到各类 AI 热潮,企业对"数字员工"的期待已经从"能对话"升级为"能干活"。DeepChat 这次更名为 DeepWork,不只是换了个名字——底层框架、向量存储、RAG 架构全部重写,是一次真正意义上的技术重构。 这次更新最硬的改动是把 AI 框架换成了 Spring AI + Spring AI Alibaba。之前 Dee...

半夜表膨胀四倍:PostgreSQL 逻辑复制遇上 statement_timeout 的灾难现场

来源: postgr.es 28
一次看起来万无一失的 PostgreSQL 迁移,在午夜把人吓醒——源端表安安静静几十 GB,目标端同样几张表却膨胀到 400 GB 以上,还在继续涨。排查到最后,罪魁祸首是一个再正常不过的配置:。两个各自合理的机制撞在一起,就制造了一场无声的灾难。 客户要把一个 PostgreSQL 数据库通过逻辑复制迁移到新服务器。逻辑复制的第一步是初始表拷贝——...

PostgreSQL 的 now() 在事务里是"冻结"的——你踩过这个坑吗?

来源: oschina.net 46
是 PostgreSQL 里最常被随手调用的函数之一,取当前时间、写日志、算过期……几乎无处不在。但如果你在事务里用它,它返回的并不是"此刻",而是事务开始的那一刻。一个跑了两分钟的事务,从头到尾每次 拿到的都是同一个时间戳。这个行为符合 SQL 标准,却和大多数人的直觉相悖,最近 Emmett 库的作者 Marcin 就因此踩了一个实打实的 bug。...

PostgreSQL leakproof 函数:行级安全与性能之间的那条线

来源: postgr.es 42
行级安全(Row-Level Security)是 PostgreSQL 提供给多租户场景的一把利器——在数据库层面直接隔离不同租户的数据,省去应用层反复过滤的麻烦。但很多团队真正用上 RLS 后,第一个撞上的墙不是安全,而是性能。查询慢得离谱,索引仿佛失效,原因指向一个不起眼的函数属性:。Laurenz Albe 的这篇文章把这个问题拆得很透,也提出...

PostgreSQL 三个代价常量:为什么你几乎永远不该改它们

来源: postgr.es 35
PostgreSQL 的查询规划器靠一组常量给每条执行路径"打分",最终选出成本最低的那个方案。其中 、 和 是最常被提及的三个。但最实用的一条建议是——你几乎永远不该修改它们。下面解释原因,以及在真正需要调优时该做什么。 规划器的成本模型把每条路径的代价拆成两部分:I/O 代价(读磁盘页)和 CPU 代价(处理一行、比较一个值)。三个常量负责后者: ...

PostgreSQL 14 的 compute_query_id:统一查询标识背后的性能权衡

来源: postgr.es 47
PostgreSQL 在 14 版本之前,各子系统对"这条查询到底是谁"的回答并不一致。 有自己的计算方式, 有另一套,日志里又是一种——同一个 SQL 在不同地方拿到不同的 ID,关联分析几乎不可能。14 版本用 这个 GUC 把计算逻辑统一到核心层,但默认值是 ,不是 。原因很简单:每次计算都要吃一点 CPU,而 PostgreSQL 的设计哲学是...