文章

发布于

PostgreSQL Hot Standby 查询冲突处理

冲突原因（4种）

  1. 主库 VACUUM 清理了备库查询需要的多版本数据（最常见）
  2. 主库 LOCK/DDL 产生的排他锁与备库查询冲突
  3. 主库删除表空间，但备库查询需要在其上存放临时文件
  4. 主库删除数据库，而备库仍有 session 连接

处理方式（2种）

  • 等待：让备库 WAL 应用进程等查询结束再应用 WAL
  • 取消：强制取消备库正在执行的查询

关键参数

  • max_standby_archive_delay — 归档模式最大等待延迟，默认 30s，-1 表示一直等
  • max_standby_streaming_delay — 流复制模式最大等待延迟，默认 30s，-1 表示一直等
场景 建议设置
备库用于高可用 设小值，保证不延迟
备库用于大查询 设大值

减少冲突的配置

  • hot_standby_feedback = on：备库告知主库哪些多版本数据还需要，防止 AutoVacuum 清理（推荐方案）
  • vacuum_defer_cleanup_age 调大：延迟清理多版本数据（辅助方案）

注意事项

  • 即使配置了以上参数，仍可能因冲突被取消查询
  • 备库应用应检测 canceling statement due to conflict with recovery 错误并自动重试
  • 冲突可通过 pg_stat_database_conflicts 视图查询
发布于

GLM-5.2：Z.ai 发布旗舰开源模型，1M 可用上下文挑战闭源长程任务

Z.ai 发布 GLM-5.2，1M 可用上下文 + 多级思考力度控制，开源模型首次挑战闭源旗舰长程任务能力

一、GLM-5.2 是什么

GLM-5.2 是 Z.ai 面向长程任务时代的旗舰模型。核心亮点是一个真正可用的 1M token 上下文窗口——不是在评测指标上好看，而是在真实的工程场景中能稳定工作。它能在单次任务中处理项目级别的工程上下文、可靠执行长时间运行的任务、一致性遵循工程规范，并且完成从需求到多平台部署的完整开发工作流。

二、三大新特性

  • Solid 1M 上下文：1M token 的前置上下文，能稳定支撑长程工作，不只是接受更多 token，而是在混乱的代码轨迹中保持质量。
  • 多级思考力度控制：更强的编程能力，提供 High 和 Max 两个思考努力级别，让用户在性能、延迟和计算成本之间自由平衡。
  • 纯粹开源：MIT 开源许可证——技术无国界。

三、长程任务能力：开源最强，紧追闭源旗舰

GLM-5.2 在三个长程编码基准测试中表现亮眼，全部位列开源模型第一：

基准测试说明GLM-5.2 表现排名
FrontierSWE衡量 Agent 完成数小时到数十小时的开放式技术项目落后 Opus 4.8 仅 1%，领先 GPT-5.5 1%，领先 Opus 4.7 11%开源第一，整体第二
PostTrainBench给 Agent 一块 H100 GPU，评判其对小模型的后训练改进能力超越 Opus 4.7 和 GPT-5.5仅次于 Opus 4.8
SWE-Marathon超长程任务，包括构建编译器、优化内核、开发生产级服务落后 Opus 4.8 13%仅次于 Opus 系列

这三个基准的共性在于：它们测试的不是模型能接受多少 token，而是模型在数万 token 的真实工程轨迹中能否持续保持高质量输出——这正是 GLM-5.2 的 1M 上下文训练的落脚点。

四、更强编程能力：开源标杆

在标准编程基准上，GLM-5.2 大幅领先前代 GLM-5.1，并显著缩小了与闭源前沿的差距：

基准测试GLM-5.2GLM-5.1Claude Opus 4.8Gemini 3.1 Pro
Terminal-Bench 2.181.062.085.0低于 GLM-5.2
SWE-bench Pro62.158.4——

Terminal-Bench 2.1 上 81.0 的成绩距离 Claude Opus 4.8 的 85.0 仅差 4 分，而 Gemini 3.1 Pro 已被甩在身后。

GLM-5.2 benchmark table

GLM-5.2 引入的 effort level 控制是一大亮点。在同等 token 预算下，GLM-5.2 的 Agent 编程能力显著强于 GLM-5.1，能力定位大致介于 Claude Opus 4.7 和 Opus 4.8 之间。当你遇到高难度任务时，切换到 Max 力度级别可分配更多计算资源，换取更高性能。

五、总结判断

GLM-5.2 是截至目前 开源模型在长程 Agent 任务上的最强选手。它的 1M 上下文不是噱头，而是在 FrontierSWE、PostTrainBench、SWE-Marathon 三个真实工程场景中验证过的能力。在标准编程能力上，它稳坐开源第一把交椅，并首次让开源模型与闭源旗舰的差距缩小到个位数百分比。

对于 AI Agent 开发者、长程自动化场景和需要高质量代码生成的团队，GLM-5.2 是目前开源阵营中最值得关注的选择。配合 MIT 开源协议和 Ollama 一键部署，上手几乎没有门槛。

发布于

pg_basebackup 报错：no pg_hba.conf entry for replication connection

pg_basebackup 执行报错 “no pg_hba.conf entry for replication connection” 的解决方法——别忘了 replication 虚拟库也需要一条规则

一、问题现象

执行 pg_basebackup 时报错：

[postgres@pg01 tools]$ pg_basebackup -h 10.0.0.101 -U postgres -F p -P -X stream -R -D $PGDATA -l postgresbackup20260616
2026-06-16 10:17:31.017 CST [1577] FATAL:  no pg_hba.conf entry for replication connection from host "10.0.0.101", user "postgres"
pg_basebackup: error: could not connect to server: FATAL:  no pg_hba.conf entry for replication connection from host "10.0.0.101", user "postgres"

明明 pg_hba.conf 里已经配置了 all 规则，为什么还会被拒绝？

二、问题原因

pg_basebackup 走的是 replication 连接，而 replication 并不是一个真实的数据库，它是一个虚拟库。pg_hba.conf 中的 host all all ... 规则只覆盖普通数据库连接，不覆盖 replication 连接。

因此即使配置了：

host    all             all             0.0.0.0/0               trust

pg_basebackup 依然会因为找不到 replication 规则而拒绝连接。

三、解决方案

在 pg_hba.conf 中添加 replication 规则：

host    replication     all             0.0.0.0/0               trust

重启 PostgreSQL：

pg_ctl restart

再次执行 pg_basebackup：

[postgres@pg01 backup]$ pg_basebackup -h 10.0.0.101 -U postgres -F p -P -X stream -R -D $PGDATA/backup -l postgresbackup20260616
65502/65502 kB (100%), 1/1 tablespace

备份成功。

四、总结

pg_hba.conf 中至少需要两条规则才能同时支持普通连接和 pg_basebackup 备份：

host    all             all             0.0.0.0/0               trust
host    replication     all             0.0.0.0/0               trust
  • 第一条：允许 普通数据库连接（所有数据库、所有用户、任意 IP，trust 认证）
  • 第二条：允许 复制连接（特殊的 replication 虚拟库、所有用户、任意 IP，trust 认证）

两条规则缺一不可。

发布于

追忆父亲

逝去的日子里，父亲的身影或许还在某个午后的光影中，在某句熟悉的话语里，在某个你下意识想拨电话的瞬间——他已经融入了时间的深处，却从未真正离开你的记忆与生命。

现在的生活正在发生，这可能是父亲最想看到的：你带着他给予的力量、教诲、甚至是他未曾说完的期望，继续走在阳光下。每一次你做出善良的选择，每一次你勇敢面对困难，都是与他最深情的对话。

未来的未来，从某种角度来说，并不遥远。因为当你在未来成为更好的自己，当你把父亲的爱传递给下一代，当你在某个人身上看到他的影子——那个未来，就是现在；那份重逢，一直都在。

对父亲的追忆，不是要把逝去的人拉回现在，而是让他们的光，继续照亮前行的路。

发布于

小米 MiMo-V2.5 系列 vs DeepSeek V4 性价比分析

Pro 旗舰级定价完全一致，标准级小米凭多模态实现差异化优势

小米 5 月 27 日降价与 DeepSeek 5 月 22 日宣布的永久降价！！！

一、降价后完整定价对比

计费项MiMo-V2.5-ProDeepSeek V4-ProMiMo-V2.5（标准版）DeepSeek V4-Flash
输入（缓存命中）0.025 元0.025 元0.020 元0.02 元
输入（缓存未命中）3 元3 元1 元1 元
输出6 元6 元2 元2 元
上下文窗口1M1M1M1M
多模态纯文本纯文本图像/音频/视频纯文本
开源协议MITMITMITMIT

数据来源：MiMo 官方调价公告 DeepSeek 官方定价页

两个层级的定价几乎完全镜像：Pro 级别三项单价完全一致，标准/Flash 级别也完全一致。但这里有一个关键差异——MiMo-V2.5 标准版是原生全模态模型（支持图像、音频、视频理解），而 DeepSeek V4-Flash 只是轻量级纯文本模型。同样的价格，小米给了多模态能力。

二、小米独有的成本优化机制

Token Plan 计费体系升级是小米本次降价的隐性加分项，很容易被忽略：

  • 同等价格下可用 tokens 提升至原方案的 5-8 倍
  • 引入 Credits 统一计量，计费规则”所见即所得”
  • 所有有效期内的 Token Plan 用户 Credits 于 5 月 27 日 0:00 全量重置
  • 北京时间 00:00~08:00 期间，所有模型 Credits 消耗速率再打 8 折

这意味着如果你使用 Token Plan 订阅制，小米的实际单位成本还会进一步降低。DeepSeek 目前没有同等规模的订阅优惠体系。

上下文窗口不再区分定价也是重要改进。此前小米对 256K 以上的长上下文窗口收取双倍价格，现在一律同价，这对 Agent 场景（经常需要长上下文）是直接利好。

三、性能与能力对比

根据独立第三方 Artificial Analysis Intelligence Index v4.0（截至 2026 年 5 月 6 日）的数据：

评测维度MiMo-V2.5-ProDeepSeek V4-Pro优势方
AA Intelligence Index54 分（并列开源第 1）52 分（并列第 2）MiMo
GDPval-AA Agent并列开源第 1并列开源第 1持平
ClawEval（长程 Agent）63.8%59.8%MiMo
τ³-bench（跨任务协作）72.9%71.8%MiMo
SWE-bench Verified78.9%80.6%DeepSeek
SWE-bench Pro（复杂工程）57.2%55.4%MiMo
LiveCodeBench Pass@1—93.5%DeepSeek
Codeforces Rating—3206（人类第 23）DeepSeek
Terminal-Bench 2.068.4%67.9%MiMo
幻觉率（AA-Omniscience）暂无数据94%（极高）MiMo 无数据但 DS 确认高

数据来源：CSDN 技术博客 搜狐

Token 效率是 MiMo 的重要差异化优势。MiMo-V2.5-Pro 在 Agent 长程任务中比 Kimi K2.6 节省约 42% Token，在 ClawEval 评测中比 Claude Opus 4.6、Gemini 3.1 Pro 节省 40%~60%。由于 Agent 任务 token 消耗指数级增长，省 token 直接等于省真金白银——在相同定价下，MiMo 完成同等任务的实际花费更低。

四、场景化性价比结论

场景 1：Agent 自动化与长程工作流（多步工具调用、代码工程 Agent）
推荐 MiMo-V2.5-Pro。Agent 能力在第三方评测中领先，Token 效率更高意味着实际成本更低，响应速度更快。小米取消上下文窗口差异化定价后，Agent 场景的长上下文调用不再有价格惩罚。

场景 2：竞赛编程与深度数学推理
推荐 DeepSeek V4-Pro。LiveCodeBench 93.5% 和 Codeforces 3206 分是开源最强，思考时间更长但推理深度更深。不过需要注意 94% 的幻觉率在可靠性要求高的场景中是硬伤。

场景 3：多模态任务（图像理解、音视频处理、办公自动化）
推荐 MiMo-V2.5（标准版）。DeepSeek V4 全系为纯文本模型，而 MiMo-V2.5 标准版原生支持图像/音频/视频理解，输出价格仅 2 元/百万 tokens，同等价位下 DeepSeek V4-Flash 只能处理文本。

场景 4：高频轻量调用与批量处理
MiMo-V2.5 标准版与 DeepSeek V4-Flash 定价完全相同（0.02 / 1 / 2），但 MiMo-V2.5 多模态能力覆盖更广，且 Token Plan 订阅可进一步压低成本。如果纯文本且高频调用，V4-Flash 也是可靠选择。

场景 5：订阅制与大用量部署
MiMo 占优。Token Plan 体系下同等价格可用 tokens 提升 5~8 倍，加上凌晨 8 折优惠和 Credits 全量重置，大规模部署的实际单位成本显著低于按量计费的 DeepSeek。

五、总结判断

在 Pro 级别，两家定价完全相同，性价比之争完全回归到能力差异：MiMo-V2.5-Pro 综合评分更高（54 vs 52），Agent 和 Token 效率领先；DeepSeek V4-Pro 在纯编程和数学推理上更强，但幻觉率是重大隐患。

在标准级，同样是相同定价，但 MiMo-V2.5 标准版凭多模态能力实现了真正的差异化——同样的 2 元输出价格，小米给的是图像/音频/视频全模态模型，DeepSeek V4-Flash 只是轻量纯文本模型。

叠加 Token Plan 5~8 倍加量、取消上下文窗口差异化定价、凌晨 8 折等优惠机制，小米 MiMo-V2.5 系列在整体性价比上略胜一筹，尤其对于 Agent 场景、多模态需求和订阅制用户。但如果你是竞赛编程或需要极致数学推理深度的用户，DeepSeek V4-Pro 仍然是更专业的工具。

发布于

NGINX 曝 9.2 分高危漏洞：潜伏 18 年，威胁全球约 1/3 服务器

IT之家 5 月 14 日消息，科技媒体 cyberkendra 昨日（5 月 13 日）发布博文，报道称 NGINX 被曝一组高危漏洞，已潜伏约 18 年，威胁全球约三分之一的网络服务器。

本次曝光的漏洞：

  • CVE-2026-42945 — 9.2 Critical
  • CVE-2026-42946 — 8.3 High
  • CVE-2026-40701 — 6.3 Medium
  • CVE-2026-42934 — 6.3 Medium

核心风险： 攻击者无需登录认证，只需发送一条特制 HTTP 请求，就能让 NGINX 工作进程崩溃；在合适条件下，还可能拿到服务器远程代码执行权限（RCE）。

漏洞原理： 最严重的 CVE-2026-42945 可追溯到 2008 年，长期存在于几乎所有标准 NGINX 构建版本中。问题出在 ngx_http_rewrite_module 的处理逻辑——某个内部标志位被设为参数转义状态后没有清掉，后续长度计算按原始字节数估算，但真正写入时却再次转义。攻击者 URI 中的 +、%、& 等字符会从 1 字节膨胀到 3 字节，导致缓冲区溢出。

depthfirst 已做出概念验证，显示在关闭 ASLR 的条件下可实现未认证 RCE。报告还提到理论方法称攻击者可通过重复请求逐步覆盖指针字节，绕过 ASLR。更麻烦的是 NGINX 的多进程架构反而给了攻击者反复试错机会：某工作进程崩溃后主进程会拉起新进程，且堆布局可能保持一致。

修复建议：

  • NGINX Open Source：升级到 1.31.0 或 1.30.1
  • NGINX Plus：升级到 R36 P4 或 R32 P6
  • 重启服务加载修复后的二进制文件
  • 临时缓解：将受影响 rewrite 规则中的未命名正则捕获改成命名捕获（不会走到有问题的转义路径）

这个漏洞影响面很大——NGINX 承载全球约 1/3 的网站，而且已存在 18 年之久。建议如果服务器有使用 NGINX rewrite 规则的尽快升级版本或采用临时缓解措施。