Skip to content

[Tracking]: main → 4.2-dev 重要修复回迁评审清单（2026-09-04～11-04） #32157

New issue
New issue
Open
Open
[Tracking]: main → 4.2-dev 重要修复回迁评审清单（2026-09-04～11-04）#32157
Assignees
LeftHandCold
Labels
kind/tech-requestNew feature or request

Description

@LeftHandCold
LeftHandCold
opened on Nov 4, 2026

目的与当前结论

对近两个月 main 上的重要修复做一次 main → 4.2-dev 回迁评审跟踪，优先减少稳定性、正确性、内存及异常清理问题，同时避免把 main 的新架构、被撤回的策略或不适用的补丁带入稳定分支。

这是候选清单，不是已批准的 cherry-pick / 发布清单。 下文“优先评审”表示建议先投入评审资源，不代表已设定仓库 severity，也不代表零风险。每项仍需负责人确认适用场景、最小依赖、回迁方案和 4.2 上的验证结果。本 issue 不替代各原始 bug issue；不重复创建这些已有根因的问题。

当前建议：

  • 先评审相对集中的 RPC / 内存引用 / frontend / lock-error 修复。
  • WAL、锁生命周期、存储去重、HNSW、ISCP、CDC 等单独形成专项回迁方案。
  • FileService 性能项按实际后端及 cache 配置选择。
  • 已覆盖、已撤回、与当前工具链不适用或大范围重构的项不直接回迁。

1. 固定对照范围与证据边界

项目 固定基线
审计日期 2026-11-04（Asia/Shanghai）
main 合并 PR 时间窗口 2026-09-04 至 2026-11-04
main 0a7847abed712ed893d841a3c5fa415327eec761
4.2-dev a3cfb7551431d7e9d87c33383fb13c44e3757873
共同祖先 2758eb1d3f812759c03c7c8a7463e2757dacb633

创建 issue 前已再次核对远端，以上两条分支 SHA 未变化。后续分支会继续前进，执行回迁前必须重新核对实际目标 SHA、是否已存在等价修复以及 main 的后续修正/回退。

方法与限制：

  1. 对合并 PR 元数据/标题筛选，再重点阅读候选 PR、相关 issue 及固定 4.2 生产代码；不是对两个月所有变更完成了逐行审计。
  2. 判断缺口不只依赖 merge SHA 是否存在，还检查 4.2 的旧路径、等价实现及后续修复。
  3. 下文“main 测试/真实 SQL/现场记录”指相关 PR/issue 中记录的证据；不表示本轮重新执行了那些测试，更不表示已在 4.2 复现或验收。
  4. 本轮只做静态核对和部分补丁文本适用性检查；没有实际 cherry-pick、编译、UT/BVT、生产操作或发布。
  5. 客户的 4.2.1 hotfix 与 4.2-dev 是不同基线。本清单不能直接当作客户 hotfix 缺陷清单，也不能据此断言当前客户某条错误已经定位。
  6. CN / TN / Proxy / 共享组件要分别确认。尤其 TN、ISCP owner 接管、native 索引兼容问题，不能默认“只升级一个 CN”就闭环。

2. 建议评审顺序

分组 PR 排期依据 / 注意事项
A：优先评审，稳定性与内存 #30761、#29586、#29559、#30536、#28384、#29352、#29725、#29448、#29199 4.2 保留具体旧路径；#29559 与 #30536 联合检查；#29199 优先级取决于大参数 prepared 使用情况
B：核心专项，不能机械 CP #29283、#31380、#30321、#29397、#29558、#29066、#30823、#28176、#29801 事务/锁/存储/native/任务生命周期变化；须拆清语义、依赖和混版本风险
C：按配置选择的 I/O / cache 项 #32053、#32137、#30519、#29092 MinIO、关闭 diskcache、COS、FIFO 回收分别核对；#29092 仅取适用子问题，排第二批
D：第二批或待补证据 #30109、#32022、#29860、#31574 不全部按严重现场故障处理；#31574 尚未完成独立分支适用性确认
E：当前不直接迁入 #30117、#29692、#28525、#28265 分别为后续撤回、工具链不适用、已有更完整覆盖、大型重构

以上共 30 条记录，包含候选与明确排除项；不是发现了 30 个已实测的 4.2 生产 bug。

3. 逐项评审记录

以下代码链接均固定在上述 4.2-dev SHA。每项合并日期为 UTC；main merge SHA 用于准确定位原补丁，不表示可原样 CP。

A. 优先评审

#30761 — 首次 catalog replay 期间 logtail 断流后，receiver 等 resume、connector 无重连信号，CN bootstrap 可卡住超时
  • 原 PR：#30761；main 合入：2026-10-21T18:06:31Z；merge 1362ffba7090。
  • 相关原 issue：#30760。
  • 本轮分类：优先排期；排期参考：高（非 severity 标签）。
  • 固定 4.2 位置：pkg/vm/engine/disttae/logtail_consumer.go:1055。
  • 4.2 代码证据：仍直接发布 ready/first=false；没有 firstReplayDone/completeFirstConnect。
  • 影响 / 升级范围：CN。
  • 回迁风险与必要验证：中：重连状态机适配；验证首次回放中断、恢复、SQL readiness。
  • 证据边界：原问题在4.2.6升级现场出现；main有确定性真实服务测试。

补充评审要点：原问题出现在 4.2.1 → 4.2.6 的升级过程中：首次 catalog replay 与 TN 重启/断流交叠，receiver 暂停，而 connector 没有继续重连的信号，最终 bootstrap 等待超时。应复用 PushClient 已有首次连接责任，避免再造一套 ready 状态机。验证首次回放前/中/后断流、恢复、关闭和 SQL readiness；既不能永久卡住，也不能在 catalog 尚不可读时提前接流量。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#29586 — 长耗时 unary RPC 尚未响应却被 idle GC 回收；checkpoint/备份等可能 backend connection closed
  • 原 PR：#29586；main 合入：2026-10-03T13:12:44Z；merge ff4468a7849c。
  • 相关原 issue：#29582。
  • 本轮分类：优先排期；排期参考：高（非 severity 标签）。
  • 固定 4.2 位置：pkg/common/morpc/client.go:1829。
  • 4.2 代码证据：只按 Locked/LastActive 判断，缺少 markIdle 的活跃 Future 检查。
  • 影响 / 升级范围：RPC客户端所在组件。
  • 回迁风险与必要验证：较小；长请求+空闲GC+取消+清理队列满。
  • 证据边界：main有真实socket反例；完整补丁 apply-check 通过，未编译。

补充评审要点：必须区分“连接很久没活动”和“仍有未完成的 unary Future”。验证请求超过 idle 阈值但未超过自己的 deadline、取消、正常完成、清理队列满等组合。本 PR 还含 ISCP 逻辑行数相关改动，落地时逐项核对，不能把整个 PR 描述成仅一个 RPC 判断。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#29559 — FinishStream 持 streamStateMu 同步等发送，writer退出清理也需此锁，可能清理死锁
  • 原 PR：#29559；main 合入：2026-10-01T15:21:36Z；merge 32f54981401f。
  • 相关原 issue：#29560。
  • 本轮分类：优先排期；排期参考：高（非 severity 标签）。
  • 固定 4.2 位置：pkg/common/morpc/server.go:917。
  • 4.2 代码证据：仍在 streamStateMu 内 cs.Write；Close 同样取锁。
  • 影响 / 升级范围：共享MORPC，重点CN流水线。
  • 回迁风险与必要验证：中：与#30536一起核对writer/terminal/message所有权；不可直接照抄main周边。
  • 证据边界：main有确定性死锁反例和两CN测试。

补充评审要点：重点检查 FinishStream → Write/等待 writer → writer 退出 → Close → streamStateMu 的等待环。与 #30536 一起评审 terminal claim、message/Future 和连接缓冲的唯一清理责任；不能只把一把锁挪走而留下 double terminal、消息丢失或新等待。验证双 CN 流水线、FIN/错误/取消并发、断链和 writer 退出。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#30536 — session Close 提前释放仍被 writer Encode/Flush 使用的连接缓冲
  • 原 PR：#30536；main 合入：2026-10-18T22:26:31Z；merge 2508ce7029b0。
  • 本轮分类：优先排期；排期参考：高（非 severity 标签）。
  • 固定 4.2 位置：pkg/common/morpc/server.go:693。
  • 4.2 代码证据：Close仍调用conn.Close；未推迟到writer finalizer。
  • 影响 / 升级范围：共享MORPC。
  • 回迁风险与必要验证：较小改动但必须验证并发Close/Write；与#29559合并验证。
  • 证据边界：完整补丁 apply-check 通过，未编译。

补充评审要点：需要把“断开连接、打断 I/O”与“释放 writer 尚在使用的缓冲”分开，由 writer finalizer 完成最终释放。验证 Close 与 Encode/Flush 并发、重复 Close、启动失败和异常退出；与 #29559 联合回归，不能仅凭单个补丁无冲突判断安全。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#28384 — 未绑定allocation account的off-heap realloc先释放旧地址、后移除元数据；地址复用可串代/panic
  • 原 PR：#28384；main 合入：2026-09-08T07:38:10Z；merge 585a38efd152。
  • 相关原 issue：#28383。
  • 本轮分类：优先排期；排期参考：高（非 severity 标签）。
  • 固定 4.2 位置：pkg/common/mpool/mpool.go:1526。
  • 4.2 代码证据：物理ReallocZero在removePtrMetadata之前。
  • 影响 / 升级范围：使用mpool的服务。
  • 回迁风险与必要验证：较小；分配失败回滚、并发地址复用、normal/race。
  • 证据边界：确定性allocator边界反例；非已复现SQL进程崩溃；完整补丁apply-check通过。

补充评审要点：适用的是未绑定 allocation account 的 off-heap realloc 分支；已走 allocate-copy-free 的 accounted 分支不能混为一谈，也不能用它替代 #28369。证据为 allocator 地址释放/复用边界反例，并非本次重现了 SQL 级进程崩溃。验证分配失败时元数据回滚、并发地址复用、profile 记录及 normal/race 路径。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#29352 — prepared查询完成后scope仍引用已关闭reader及旧PartitionState，空闲长连接可持续持有大块内存
  • 原 PR：#29352；main 合入：2026-09-24T13:48:39Z；merge c701ffa4ef76。
  • 相关原 issue：#29326。
  • 本轮分类：优先排期；排期参考：高（非 severity 标签）。
  • 固定 4.2 位置：pkg/sql/compile/scope.go:333。
  • 4.2 代码证据：p.Cleanup之后未清s.DataSource.R。
  • 影响 / 升级范围：CN。
  • 回迁风险与必要验证：小；prepared反复执行/空闲保留/错误退出。
  • 证据边界：完整补丁apply-check通过；不声称解决所有CN OOM。

补充评审要点：关闭 reader 不等于删除 scope 对 reader 的引用。应在已有 Cleanup 所有权下断开引用，不新增长期 registry。验证 prepared handle 反复执行、执行结束后保持连接空闲、错误/取消/Close，以及 reader 不重复释放；观察引用链和内存回收，不把任何 CN OOM 都归因到这里。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#29725 — 旧锁owner连接关闭返回EPIPE/ECONNRESET时未进入换绑恢复，Unlock清理可能残留
  • 原 PR：#29725；main 合入：2026-10-08T17:03:27Z；merge 9df2c4006142。
  • 相关原 issue：#29714。
  • 本轮分类：优先排期；排期参考：高（非 severity 标签）。
  • 固定 4.2 位置：pkg/lockservice/lock_table_remote.go:544。
  • 4.2 代码证据：retryRemoteLockError缺失EPIPE/ECONNRESET/net.ErrClosed。
  • 影响 / 升级范围：LockService相关组件。
  • 回迁风险与必要验证：较小；生产修复集中在分类器，测试需适配。
  • 证据边界：main有public Unlock反例。

补充评审要点：错误分类只负责进入既有换绑恢复，不能将 EPIPE/ECONNRESET 一律吞掉当作 Unlock 已成功；binding 没变时仍需满足原来的确认协议。验证旧 owner 连接失效、binding 已变/未变、重试取消和事务关闭后无遗留锁。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#29448 — 登录握手与连接关闭竞态、非法proxy salt可触发slice panic
  • 原 PR：#29448；main 合入：2026-09-28T14:56:12Z；merge 1ded9fc91480。
  • 相关原 issue：#29446。
  • 本轮分类：优先排期；排期参考：高（非 severity 标签）。
  • 固定 4.2 位置：pkg/frontend/mysql_protocol.go:1632。
  • 4.2 代码证据：makeHandshakeV10Payload反复GetSalt并直接切片，无长度/关闭快照检查。
  • 影响 / 升级范围：CN和Proxy。
  • 回迁风险与必要验证：较小至中；接口签名涉及双方；正常登录和断连并发测试。
  • 证据边界：4.2保留旧路径；不声称已确定某次现场panic触发者。

补充评审要点：应先取得一致的握手/关闭状态与 salt 快照并验证长度，再构造 payload；同时检查 proxy 帧长度边界。涉及 CN/Proxy 调用签名时需要成套适配。验证正常密码认证、关闭竞态、短 salt、非法帧；目前不能据此断言某一次现场 panic 的触发者。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#29199 — prepared LONG_DATA分块重复复制累积前缀并保留历史值；大参数上传严重放大内存
  • 原 PR：#29199；main 合入：2026-09-22T04:08:56Z；merge 170a559c858d。
  • 相关原 issue：#29187。
  • 本轮分类：优先排期；排期参考：场景高（非 severity 标签）。
  • 固定 4.2 位置：pkg/frontend/mysql_protocol.go:744。
  • 4.2 代码证据：每块append旧值再SetAnyToStringVector，无累计参数上限控制。
  • 影响 / 升级范围：CN。
  • 回迁风险与必要验证：中；驱动LONG_DATA协议、EXECUTE/RESET/CLOSE、迁移边界。
  • 证据边界：main原始协议验证4MiB数据曾引起约400MiB RSS增长；非生产保证。

补充评审要点：PR 的原始 MySQL 协议对照记录中，4 MiB 参数分 64 块上传曾导致约 400 MiB RSS 增长，修复后约 22 MiB；这是该测试记录，不是所有驱动/部署的保证。验证 COM_STMT_SEND_LONG_DATA 累计预算、失败后 EXECUTE 错误保持、RESET/CLOSE 释放、后续 statement 不受污染及迁移限制；不能只在单块上传处限长。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

B. 核心专项回迁

#29283 — merge输出的旧RowID被tombstone过滤后没有回退到appendable替代行，TN点查/去重漏判
  • 原 PR：#29283；main 合入：2026-09-24T09:40:06Z；merge 3da27b1d1f01。
  • 相关原 issue：#29284。
  • 本轮分类：核心专项回迁；排期参考：高（非 severity 标签）。
  • 固定 4.2 位置：pkg/vm/engine/tae/txn/txnimpl/base_table.go:152。
  • 4.2 代码证据：getRowsByPK仍共用单一RowID向量；没有候选集合。
  • 影响 / 升级范围：TN。
  • 回迁风险与必要验证：中高；查重/merge/重启/写入性能，关注每对象候选分配成本。
  • 证据边界：存储层确定性反例；不能写成普通CN SQL已复现重复PK。

补充评审要点：核心是先保存 appendable/non-appendable 候选，再按 tombstone 与可见性选出仍有效的行，不能由一个已被删除的旧 RowID 遮住替代行。现有证据是存储层 GetByFilter/Dedup 反例，普通 CN SQL 并发重复主键并未在本次重现。验证 merge 与新 append 交叠、tombstone、重启和 dedup；关注每对象候选分配及写入热路径性能。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#31380 — 最终WAL消息超过LogService上限后持续重试并使TN panic，影响无关业务
  • 原 PR：#31380；main 合入：2026-10-28T12:58:05Z；merge 21d67b276d67。
  • 相关原 issue：#31350。
  • 本轮分类：核心专项回迁；排期参考：高（非 severity 标签）。
  • 固定 4.2 位置：pkg/vm/engine/tae/txn/txnimpl/cmdmgr.go:56。
  • 4.2 代码证据：仍在group callback序列化，无最终大小准入；PrepareWAL错误直接panic。
  • 影响 / 升级范围：TN；核对LogService接收上限。
  • 回迁风险与必要验证：高；大小边界、pre-append回滚、LSN/DSN连续、group commit性能及恢复。
  • 证据边界：有main TKE现场；4.2相同危险路径；不是仅提高消息上限。

补充评审要点：main 的现场记录为 merge 携带 transferred deletes 后最终 WAL 约 106 MB，超过 LogService 100 MiB 限制，重试约 3 分钟后 TN panic。原先约 70 MiB 的估计不能约束最终序列化大小。修复涉及约 31 个文件，应在消费 LSN/DSN/提交不可逆状态前完成最终消息大小准入，不能简单提高接收上限。验证大小边界、拒绝后的回滚/资源释放、其他错误仍按原语义 fail-stop、group commit 吞吐、WAL replay；这不是只升级一个 CN 能闭环的修复。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#30321 — 混合行锁/范围锁下waiter与物理范围两端责任不平衡，锁残留及内存增长
  • 原 PR：#30321；main 合入：2026-10-16T06:10:35Z；merge ac55588b8d4b。
  • 相关原 issue：#30313。
  • 本轮分类：核心专项回迁；排期参考：高（非 severity 标签）。
  • 固定 4.2 位置：pkg/lockservice/lock_table_local.go:101。
  • 4.2 代码证据：oldOffset替换判断/c.offset=c.idx仍在；加入range仅记录一个key。
  • 影响 / 升级范围：LockService相关组件。
  • 回迁风险与必要验证：高；不得覆盖#28529旧分支独立修复；验证多CN换主、取消、超时、hotpath性能。
  • 证据边界：main生产代码反例，checker panic不等于生产配置必然panic。

补充评审要点：要按 waiter 身份及实际加入的锁范围两端核对所有权，不能只依赖 offset 判断是否替换。main 的 reuse checker panic 是测试证据，生产配置不一定以同样 panic 表现，实际可能是保留/增长。4.2 已有 #28529 的独立旧分支修复，不能被 main 整文件覆盖丢失。验证行锁加入范围锁、取消、下一次准入失败、多 CN 换主、remote owner、范围两端释放和热点锁吞吐。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#29397 — 显式事务中DROP DATABASE失败仅回滚语句，再COMMIT可误删恢复表的自增分配器
  • 原 PR：#29397；main 合入：2026-09-27T07:31:51Z；merge 346e02b49856。
  • 相关原 issue：#29395。
  • 本轮分类：核心专项回迁；排期参考：场景高（非 severity 标签）。
  • 固定 4.2 位置：pkg/incrservice/service.go:216。
  • 4.2 代码证据：删除仍登记事务级deletes并于txnClosed处理，无statement callback回滚。
  • 影响 / 升级范围：CN。
  • 回迁风险与必要验证：中高；与4.2自增缓存及语句回滚集成，验证DDL失败后继续COMMIT。
  • 证据边界：main真实MySQL线协议前后对照；4.2保留旧责任模型。

补充评审要点：语句 rollback 与整个事务终态不是同一责任边界：失败 DROP DATABASE 恢复了表，但事务级 deletes 仍可能在后续 COMMIT 删除其 allocator。应与 4.2 既有语句/事务回调融合。验证事务内先成功写入，再 KILL QUERY/失败 DROP DATABASE，再分别 COMMIT/ROLLBACK，之后原表自增 INSERT 仍正确；不能只测整个事务一起回滚。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#29558 — FORCE INDEX读取可NULL UNIQUE隐藏表时漏掉包含NULL的行
  • 原 PR：#29558；main 合入：2026-10-01T16:34:49Z；merge c2cad8af38f1。
  • 相关原 issue：#29555、#29557。
  • 本轮分类：核心专项回迁；排期参考：场景高（非 severity 标签）。
  • 固定 4.2 位置：pkg/sql/plan/apply_indices.go:983。
  • 4.2 代码证据：hinted covering/backfill入口缺少NULL完整性证明。
  • 影响 / 升级范围：CN planner。
  • 回迁风险与必要验证：中；优先移植nullable UNIQUE完整性部分，不捆绑main Decimal256优化。
  • 证据边界：main真实SQLwrong-result；4.2同样存在hinted访问入口。

补充评审要点：本轮建议仅提取 nullable UNIQUE 访问完整性修复：隐藏 UNIQUE 表不含某些 NULL 键，FORCE INDEX 的 covering/backfill 路径必须证明相关键非 NULL，否则回退到完整数据来源。本 PR 另含 Decimal256 等比较优化，不能默认整包迁入。验证单列/复合 UNIQUE、OR、NULL、hint、join/聚合以及与无索引 oracle 的结果一致性；正确性回退可能变慢，应明示。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#29066 — 并发写入/父表删除期间ADD FOREIGN KEY可能使用旧快照通过验证，留下孤儿数据
  • 原 PR：#29066；main 合入：2026-09-26T12:03:32Z；merge b1b68925d7f6。
  • 相关原 issue：#28934。
  • 本轮分类：核心专项回迁；排期参考：场景高（非 severity 标签）。
  • 固定 4.2 位置：pkg/sql/compile/ddl.go:635。
  • 4.2 代码证据：普通子表锁/父表catalog锁，缺乏专用freshness和父表data锁协议。
  • 影响 / 升级范围：CN。
  • 回迁风险与必要验证：中高；RC/SI、多CN、锁序与超时rollback；DDL持锁时间会增加。
  • 证据边界：main两CN实测；4.2原路径仍在。

补充评审要点：并发 ADD FOREIGN KEY 需要同时保证子表验证快照足够新、父表数据在验证/提交窗口内受到正确保护。不能仅加 catalog 锁。验证 RC/SI 下并发子表 INSERT、父表 DELETE、双 CN、锁顺序、超时/取消后的 metadata rollback；新增 data lock 会影响 DDL 与写入并发，需测量而非声称零性能影响。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#30823 — HNSW DELETE后INSERT复用已删除节点，破坏图连通性，持久漏召回；旧库另有重删插自旋
  • 原 PR：#30823；main 合入：2026-10-26T16:51:52Z；merge 47652f7a1aa1。
  • 相关原 issue：#30660。
  • 本轮分类：核心专项回迁；排期参考：HNSW场景高（非 severity 标签）。
  • 固定 4.2 位置：thirdparties/Makefile:32。
  • 4.2 代码证据：仍用usearch-2.25.3.tar.gz。
  • 影响 / 升级范围：HNSW执行CN及native artifacts。
  • 回迁风险与必要验证：高；不是只改版本号，必须带MO定制修复tarball；旧模型读写/重启/混合版本兼容与索引重建评估。
  • 证据边界：main有bare-usearch和真实SQL反例；升级不自动修复历史已损图。

补充评审要点：PR 提供 bare-usearch 与真实 SQL 反例：删除后复用节点破坏图连接，漏召回在保存/重启后仍存在；另有重删插场景自旋。必须使用包含 MO 定制修复的 native tarball，不能仅把版本字符串改为上游 vanilla 2.26.5。验证 native ABI、旧模型读写、reserve 语义、滚动升级、删除/插入稳定性与 recall/延迟。升级程序不自动修复历史已损坏的图，需要单独判断重建。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#28176 — ISCP水位刷新用仅含LSN的JobStatus覆盖状态，Stage退回Init并可能重复非幂等初始化
  • 原 PR：#28176；main 合入：2026-09-05T11:20:56Z；merge 845fff8ee9ca。
  • 相关原 issue：#28175。
  • 本轮分类：核心专项回迁；排期参考：异步索引场景高（非 severity 标签）。
  • 固定 4.2 位置：pkg/iscp/consumer_entry.go:167。
  • 4.2 代码证据：仍构造JobStatus{LSN:...}整块写回；没有原子初始化生命周期证据。
  • 影响 / 升级范围：所有可能接管ISCP任务的CN。
  • 回迁风险与必要验证：高；旧任务quarantine/索引重建与滚动升级接管策略，不能只滚一个CN就承诺闭环。
  • 证据边界：4.2直接存在原错误写入；main方案带明确运维代价。

补充评审要点：仅把 Stage 字段补回并不足以覆盖初始化原子性。main 方案还涉及保留 Stage 的 JSON 更新、InitSQL 与 Running 原子提交、旧 LSN CAS、LifecycleVersion，以及无法证明初始化历史的旧任务隔离/重建。评审需明确是否采用完整生命周期语义，避免在 4.2 再造重复状态机。所有可能接管 ISCP 的 CN 都需兼容，或明确限制 owner；只滚一个 CN 后旧 owner 仍可能覆盖状态。旧任务隔离会有可用性成本，必须给出升级/重建流程。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#29801 — CDC目标事务整体回滚后只重试失败语句可部分写入并推进水位；驱动错误分类也不匹配
  • 原 PR：#29801；main 合入：2026-10-09T19:46:21Z；merge a6e19ccf7761。
  • 相关原 issue：#29434。
  • 本轮分类：核心专项回迁；排期参考：CDC场景高（非 severity 标签）。
  • 固定 4.2 位置：pkg/cdc/sinker_v2_executor.go:315。
  • 4.2 代码证据：活跃e.tx仍进入逐语句execWithRetry；缺少整事务错误传播修复。
  • 影响 / 升级范围：CDC执行CN。
  • 回迁风险与必要验证：中高；成套移植分类/失败传播/整事务重放；不能只加retry error code。
  • 证据边界：main真实connector/rollback反例；4.2相关旧执行路径存在。

补充评审要点：必须区分目标执行器实际使用的 matrixorigin/mysql 驱动错误与上游驱动类型，并让已失败的目标事务整体失败/重放。若目标数据库回滚整个事务，只重试最后一条语句可能漏写前面的语句却推进 watermark。验证 1213、1205 及目标端 rollback 配置、错误持续传播、完整 batch replay、watermark 不前进、取消和清理；不能只回迁错误码分类器。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

C. I/O 与 cache：按场景回迁

#32053 — 有限范围读取请求开口后缀，Close还下载丢弃尾部，I/O放大
  • 原 PR：#32053；main 合入：2026-11-03T06:54:32Z；merge 1876b2f93e14。
  • 相关原 issue：#31692。
  • 本轮分类：性能场景回迁；排期参考：MinIO场景高（非 severity 标签）。
  • 固定 4.2 位置：pkg/fileservice/minio_sdk.go:602。
  • 4.2 代码证据：getObject无Range上界，Seek后Close中io.Copy(io.Discard)。
  • 影响 / 升级范围：MinIO SDK使用组件CN/TN。
  • 回迁风险与必要验证：中；4.2没有main identity reader接口，按旧架构移植；搭配fix(fileservice): avoid full-object reads without disk cache #32137。
  • 证据边界：HTTP字节计数反例；不是diskcache锁问题。

补充评审要点：有限范围请求应在每次重试都保持正确的 Range 上界；Close 不应为复用连接而下载并丢弃剩余大对象。4.2 没有 main 的 identity-reader 接口，应在原有 FileService/SDK 责任内做最小语义移植。验证真实 SDK/HTTP Range、实际下载字节数、partial read/Close、取消、retry 与 EOF；不是根据延时就认定 diskcache 锁 bug。与 #32137 配套看。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#32137 — 未配置diskcache仍按默认策略拉整个对象，无法缓存被多读的部分
  • 原 PR：#32137；main 合入：2026-11-04T05:40:30Z；merge b27f3869e6f2。
  • 相关原 issue：#31692。
  • 本轮分类：性能场景回迁；排期参考：关闭DiskCache场景高（非 severity 标签）。
  • 固定 4.2 位置：pkg/fileservice/s3_fs.go:1002。
  • 4.2 代码证据：仅forceMinimalRangeRead触发最小range；没有s.diskCache==nil判断。
  • 影响 / 升级范围：S3FS使用组件CN/TN。
  • 回迁风险与必要验证：较小；测试内存cache-only及零容量；MinIO还需fix(fileservice): bound MinIO range reads without draining on close #32053。
  • 证据边界：生产代码边界匹配，main真实SDK HTTP oracle。

补充评审要点：即使 MinIO SDK 修好范围，S3FS 上层在没有 diskcache 时仍请求整个对象，也会继续放大 I/O。验证没有 diskcache、零容量配置、memory-cache-only、正常 diskcache 开启，以及跨 range/重试行为；真实 HTTP 字节 oracle 与业务 TP/AP 性能均需核对。不能把小对象的 SDK 反例等同于完整生产吞吐验收。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#30519 — COS LOAD边界探测提前结束时Close继续读完整个后缀，放大下载与延迟
  • 原 PR：#30519；main 合入：2026-10-18T11:33:53Z；merge 799523418e9f。
  • 相关原 issue：#30511。
  • 本轮分类：性能场景回迁；排期参考：COS场景高（非 severity 标签）。
  • 固定 4.2 位置：pkg/fileservice/qcloud_sdk.go:924。
  • 4.2 代码证据：closeFunc仍io.Copy(io.Discard, resp.Body)。
  • 影响 / 升级范围：COS读取CN/TN。
  • 回迁风险与必要验证：较小至中；适配旧函数，核对partial read/retry及连接复用变化。
  • 证据边界：main真实SDK和LOAD probe反例。

补充评审要点：COS 的 LOAD 边界探测可能只需少量数据，但 Close 继续 io.Copy 到 EOF 会读取巨大尾部。移植时验证真实 SDK 与 LOAD probe、partial read、retry、取消。提前关闭可能改变 HTTP/1 连接复用，关注连接建立率和整体吞吐；不是去掉一行 io.Copy 就宣称无代价。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#29092 — FIFO同步回收遇到已删除main队列记录时过早停止
  • 原 PR：#29092；main 合入：2026-09-18T09:03:36Z；merge d97251938429。
  • 相关原 issue：#29088。
  • 本轮分类：第二批；排期参考：中（非 severity 标签）。
  • 固定 4.2 位置：pkg/fileservice/fifocache/fifo.go:687。
  • 4.2 代码证据：进度只检查used1；未识别used2变化；4.2不存在新reservedBytes机制。
  • 影响 / 升级范围：CN/TN内存cache。
  • 回迁风险与必要验证：只取FIFO进度修复；不要整包引入main reservation/accounting架构。
  • 证据边界：两个问题仅FIFO子问题适用4.2。

补充评审要点：本轮只建议 FIFO eviction 的进度判断修复：used1 没变但 used2 已下降时不应错误认为无进展。4.2 不存在 main 的 reservedBytes/reservation 机制，不要借此引入整套新 cache accounting/guard。验证混合队列、删除条目、容量收缩、pin/并发释放及 eviction 热路径。此项属于性能/回收类第二批。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

D. 第二批 / 待进一步核实

#30109 — logtail换连接时旧stream的context canceled泄漏到仍有效的只读屏障请求
  • 原 PR：#30109；main 合入：2026-10-13T15:44:25Z；merge c5208fc54d1a。
  • 相关原 issue：#30123。
  • 本轮分类：第二批；排期参考：中（非 severity 标签）。
  • 固定 4.2 位置：pkg/vm/engine/disttae/logtail_consumer.go:2131。
  • 4.2 代码证据：readBarrier单次调用后直接返回；#31571没有替代此修复。
  • 影响 / 升级范围：CN。
  • 回迁风险与必要验证：中；4.2 PushClient生命周期不同，不能引入重复owner状态。
  • 证据边界：并非数据损坏；只读barrier重试，不是重放DDL。

补充评审要点：只对旧 transport 被替换而调用方 context 仍有效的只读 readBarrier 做恢复；调用方自己取消/超时必须及时退出。不是重放 DDL/DML。4.2 PushClient 生命周期不同，复用已有 owner/连接代际信息；#31571 的测试稳定性修改不能当成该修复已覆盖。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#32022 — 订阅状态锁内写诊断日志，日志sink阻塞可拖住无关表读取
  • 原 PR：#32022；main 合入：2026-11-02T10:52:29Z；merge b4d1a674ce0d。
  • 相关原 issue：#32021。
  • 本轮分类：第二批；排期参考：中（非 severity 标签）。
  • 固定 4.2 位置：pkg/vm/engine/disttae/logtail_consumer.go:1773。
  • 4.2 代码证据：状态变更方法defer Unlock后日志仍在锁内。
  • 影响 / 升级范围：CN。
  • 回迁风险与必要验证：中；保留4.2 incarnation/newEntry所有权，不覆盖为main简单entry。
  • 证据边界：main确定性阻塞反例；无生产P95改善保证。

补充评审要点：在锁内取得日志所需快照、锁外记录，避免日志 sink 阻塞扩大成跨表阻塞；不能为移日志覆盖 4.2 已有 incarnation/newEntry 生命周期。验证阻塞日志 sink、并发订阅/退订/换代。没有现场 P95 改善保证，按实际证据排期。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#29860 — 恶意或损坏的length-encoded报文发生uint64转int溢出并触发slice panic
  • 原 PR：#29860；main 合入：2026-10-11T07:02:44Z；merge 4572ca1839b2。
  • 相关原 issue：#29859。
  • 本轮分类：第二批；排期参考：较低（非 severity 标签）。
  • 固定 4.2 位置：pkg/frontend/mysql_protocol.go:1223。
  • 4.2 代码证据：边界判断仍pos+count-1；readStringLenEnc先int转换。
  • 影响 / 升级范围：CN。
  • 回迁风险与必要验证：小；完整补丁apply-check通过，需wire协议回归。
  • 证据边界：已报告EXECUTE panic被恢复为SQL错误，不按CN必然宕机分类。

补充评审要点：长度必须在 uint64 域验证后才能安全转换为 int/做 slice 边界运算。覆盖恶意/截断包及正常 EXECUTE/参数协议。已知 EXECUTE panic 会被恢复为 SQL 错误，因此不按“任意坏包必然杀死 CN”描述。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#31574 — CN logtail replay batch保留重复rowid/time和无用tombstone列
  • 原 PR：#31574；main 合入：2026-10-28T12:51:11Z；merge 4808a7befd38。
  • 本轮分类：第二批；排期参考：按内存证据决定（非 severity 标签）。
  • 固定 4.2 位置：pkg/vm/engine/disttae/logtailreplay。
  • 4.2 代码证据：需进一步独立核对分支依赖，未列为已确认首批。
  • 影响 / 升级范围：CN。
  • 回迁风险与必要验证：涉及读路径与size accounting；必须做4.2内存/性能A-B。
  • 证据边界：main微基准已有轻微变慢，不承诺无性能影响。

补充评审要点：保留为后续调查，不列为已确认必须回迁：尚未完成独立的 4.2 依赖/字段可删性核对。main 的微基准记录也有约 3.7%–5.4% 的延时增加，不能只看节省内存。若进入回迁，应有真实 catalog/logtail 内存驻留、replay CPU、查询延迟和 size accounting 的 A/B 结果。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

E. 不直接回迁的记录

#30117 — HNSW缺覆盖证据即退全表扫描；main已通过#30989撤回HNSW主体
  • 原 PR：#30117；main 合入：2026-10-22T04:32:55Z；merge cca94b810ce8。
  • 本轮分类：暂不孤立回迁；排期参考：排除（非 severity 标签）。
  • 固定 4.2 位置：pkg/sql/plan/apply_indices_hnsw.go。
  • 4.2 代码证据：不能将被后续撤回的策略当当前main稳定修复。
  • 影响 / 升级范围：CN。
  • 回迁风险与必要验证：先明确异步ANN语义；不要孤立CP。
  • 证据边界：大表全表扫描回退可能严重降性能。

补充评审要点：main 随后通过 #30989 撤回 HNSW 主体策略，原因包括大表回退全扫描的明显性能影响。不能把两个月窗口内曾经合入过等同于当前 main 仍认可的稳定修复；异步 ANN 的一致性/覆盖语义需另行决策。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#29692 — Go1.27.0 database/sql死锁；4.2使用1.26.4
  • 原 PR：#29692；main 合入：2026-10-08T07:45:16Z；merge 1a0088790c88。
  • 本轮分类：暂不直接回迁；排期参考：不适用当前工具链（非 severity 标签）。
  • 固定 4.2 位置：go.mod:4。
  • 4.2 代码证据：当前4.2-dev go1.26.4；PR给出的1.26.4控制组不受该bug影响。
  • 影响 / 升级范围：构建工具链。
  • 回迁风险与必要验证：不为此问题额外升级整个工具链。
  • 证据边界：实际构建若覆盖go.mod需另查构建receipt。

补充评审要点：此处针对 Go 1.27.0 database/sql 的特定死锁，而固定 4.2 基线 go.mod 是 Go 1.26.4，PR 的控制组记录中不受该问题影响。如果实际构建覆盖了 go.mod 工具链，应另查 build receipt；当前不据此额外升级整个工具链。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#28525 — 备份soft-deleted checkpoint对象选择
  • 原 PR：#28525；main 合入：2026-09-09T16:00:35Z；merge 9475a9c22992。
  • 本轮分类：已有覆盖；排期参考：无需重复CP（非 severity 标签）。
  • 固定 4.2 位置：pkg/backup/tae.go:828。
  • 4.2 代码证据：4.2 selectBackupObjects已包含更完整的历史保留/GC扫描证明。
  • 影响 / 升级范围：CN/TN备份链。
  • 回迁风险与必要验证：不能用旧补丁覆盖更完整现有修复。
  • 证据边界：已代码确认。

补充评审要点：4.2 的 selectBackupObjects 已演进为更完整的历史保留与 GC 扫描证明逻辑。不要拿较早的简单 soft-delete 选择规则覆盖它，避免退化；“没有同一个 merge SHA”不等于“没有修复”。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

#28265 — ordered ODKU整体重构
  • 原 PR：#28265；main 合入：2026-09-06T13:44:14Z；merge a6ee7171327e。
  • 本轮分类：暂不批量回迁；排期参考：高风险大改造（非 severity 标签）。
  • 固定 4.2 位置：pkg/sql/plan/bind_insert.go。
  • 4.2 代码证据：4.2存在不同ODKU演进及已回迁[4.2] fix(plan): lock the resolved ODKU row #31957；未宣称本PR每个子问题仍在。
  • 影响 / 升级范围：CN/TN与计划协议。
  • 回迁风险与必要验证：约56文件/万行量级；按真实case拆最小修复，连同#31963依赖审查。
  • 证据边界：不是安全小补丁。

补充评审要点：ordered ODKU 约 56 文件、万行级变化，另有 #31963 等后续依赖；4.2 已有自己的演进和 #31957 等修复。若出现明确客户 case，应先构造反例，再拆最小语义补丁并审查计划协议/执行器兼容，不把整个 DML 重构作为本轮常规 CP。

评审状态：待负责人确认；尚无本轮 4.2 回迁 PR / 运行验证结论。

4. 已有覆盖，避免重复回迁或误判客户基线

以下是本轮核对中排除的典型重复项，不是所有已回迁修复的完整目录：

原修复 / 对应 PR 4.2-dev 核对结论
#28369 Vector.Area / allocation account 相关修复已在本次 4.2-dev 基线；不能由此推断旧 4.2.1 hotfix 也有
#31127 prepared/window reset 相关修复已有覆盖
#30796 CTE reader/batch 清理相关修复已有覆盖
#28280 订阅库 secondary index 查询相关修复已有覆盖
#29504 历史备份对象相关修复已有覆盖
#32080 最新 backup MinIO logical-size 对应回迁已包含在固定 4.2 head
#32081 compress scratch / merge batch 清理相关修复已有覆盖
#28525 4.2 的 selectBackupObjects 已有更完整逻辑，不能用较早简单规则替换

额外边界：

  • #29748 的存储层去重时间戳/行窗口反例，不能直接外推成“普通 CN SQL 一定可重复主键”；正常 CN 的悲观 PK 锁及快照刷新可能阻断该时序。未作为本轮已证实的普通业务 blocker，若要推进应先补端到端可达性证据。
  • #30117 必须连同撤回 #30989 一起理解；#28265 必须连同 #31963 等后续演进核对，不能只看原 PR 曾经合入。
  • 表中“已有覆盖”只针对固定 4.2-dev，不是对任何已发布 4.2.x 镜像或 hotfix 的承诺。

5. 补丁文本适用性检查：仅用于估算适配工作量

使用独立临时 git index，以固定 4.2 SHA 初始化，执行原 main commit 的差异：

git diff <main-merge-sha>^ <main-merge-sha> --binary
    | git apply --cached --check

没有改动工作树或分支。该方法不是 git cherry-pick 的三方合并，也不能替代语义检查。

6. 设计与工程质量评审要求

回迁时先确认“原职责归谁”，再确定补丁：

  • 生命周期/关闭/释放使用已有 owner、terminal 和错误传播路径，不重复维护状态机、registry 或缓存真相。
  • 同一个不变量只保留一个有效实现；新增分支要说明为什么需要，不能永久并存两套校验/执行路径。
  • 不能用 main 整文件覆盖丢失 4.2 独立修复；特别关注 fix(lockservice): balance row waiter and range ownership lifetimes #30321、fix(disttae): release subscription state locks before diagnostics #32022、fix(fileservice): correct cache accounting and reclamation #29092 等已注明的分支差异。
  • 被替代的条件、无用字段、不可达分支和重复计算应同步删除；不要为了搬测试引入生产层多余抽象。
  • Q1：成功、错误、取消、部分初始化、重启/换代后，资源恰好终结一次。
  • Q2：等待有明确完成者或可生效的取消/期限；不要仅靠外层 timeout 掩盖内部死锁。
  • Q3：常驻、在途、pin、重试和失败样本都纳入增长约束；数量有界不等于内存预算合理。
  • 性能需看正常热路径，不只看修复反例；包括锁竞争、分配、I/O 字节数、连接复用、吞吐及 p95/p99。
  • 对可选场景要写清前提，不能把理论最坏情况当成所有业务必现的 blocker。

7. 后续评审记录与验收

每个候选由评审人给出 接受完整回迁 / 最小适配 / 已有等价修复 / 不适用 / 延后补证据 之一，并填写：

字段 必须记录的内容
原 PR / 根因 对应上面的编号与不变量，避免按标题决定
目标基线 回迁时真实 4.2-dev SHA；若用于客户 hotfix，另列客户实际 SHA
决策 / 负责人 选用哪些语义、排除哪些改动，以及理由
依赖与后续修正 必要前置、main 后续修复/回退、4.2 独立逻辑
反例与证据 未修复目标上失败、修复目标上通过；若无法重现，明确缺失证据
unhappy / 正常回归 取消、超时、断连、并发、关闭、重启及业务正确性
性能 同基线、同资源、同数据的对照，不用一次 noisy 结果作保证
升级范围 / 兼容性 CN/TN/Proxy/native、持久格式/任务状态、滚动混版本、是否需重建
回迁 PR / SHA / 测试链接 实际提交和可核验结果，不以原 main CI 替代
回滚方案 代码回滚是否足够；是否已有不可逆状态或需重建/恢复

总体验收：

  • 逐项完成适用性复核，更新此清单中的接受/排除决定，避免笼统打包。
  • 优先组形成边界清楚的回迁 PR；紧密相关生命周期修复联合验证，不夹带无关重构。
  • 专项组完成设计、混版本和数据/索引恢复评审后再决定发布批次。
  • 每个接受项具备目标 4.2 上的反例、修复后验证和必要的正常业务回归。
  • 验证失败、未执行、跳过、通过分别记录；不可把纯文本应用检查写成测试通过。
  • 发布前重新比对分支 SHA、等价修复和后续回退，明确最终镜像与升级组件。
  • 客户 hotfix 单独按实际版本评估，不自动从本 issue 推导“可仅升级 CN / 可直接上线”。

本 issue 仅建立评审入口；当前未执行任何回迁或发布。

Activity

  1. LeftHandCold
    added
    kind/tech-requestNew feature or request
    on Nov 4, 2026
  2. LeftHandCold
    self-assigned this
    on Nov 5, 2026

  3. LeftHandCold commented on Nov 5, 2026

    @LeftHandCold
    LeftHandCold
    on Nov 5, 2026
    CollaboratorAuthor

    补充复审：回迁优先级、遗漏项与验收边界（2026-11-05）

    结论：本 Issue 的方向基本正确，可以作为回迁评审基线，但不能直接作为整批 cherry-pick、合并或发布批准。建议保留“小修复先行、核心生命周期专项验证、场景项按配置选择”的安排，并补上下面的 ISCP 重试责任缺口及后续修正。

    本轮是源码、PR 差异和后续历史复核，没有重新执行 cherry-pick、编译、UT/BVT、集群故障注入或性能测试。原 Main PR 的测试记录不能当成本轮 4.2 验收。以下建议也不是在认定近期所有 OOM、连接中断或索引问题都已找到对应修复。

    1. 固定审查基线及状态

    需要始终区分四件事：语义上值得回迁、文本能够应用、目标 4.2 测试通过、最终组合镜像和升级流程通过。前一项不自动证明后一项。

    2. 建议优先推进的九个修复单元

    这里的“九项”是工程排期建议，不是九个已经完成 4.2 验收的补丁；#29558 仅包含 nullable UNIQUE 正确性部分。

    原 PR 建议及实际修复范围 必须保留的验收边界
    #30761 首次 Catalog replay 遇到断流后，修复 bootstrap/reconnect 的责任交接。 首次回放前、中、后断流，恢复及关闭；必须验证 SQL 真正可用，不能只看 Pod Ready，也不能提前发布 catalog-ready。
    #29586 未完成的 unary Future 不应被连接 idle GC 当作空闲回收。 长请求、完成、取消及清理排队；另含 ISCP 逻辑行读取修复，见下文。不等同于 5 秒 backend 建连超时修复。
    #29559 解除 FinishStream 持有 streamStateMu 等待发送、writer 退出又等待该锁的环。 与 #30536 联合验证 FIN/错误/取消/Close、消息及 Future 所有权，不能只把 Write 移出锁就认为闭环。
    #30536 区分打断 I/O 与最终释放连接缓冲，避免 writer 仍使用缓冲时提前释放。 writer finalizer 和启动失败路径各自承担明确释放责任；重复 Close、阻塞 Write、异常退出都不能泄漏或重复释放。
    #28384 修复未绑定 allocation account 的 off-heap realloc 地址复用与旧元数据清理顺序。 分配失败恢复、地址复用、profile 元数据与 normal/race；不是所有 OOM 的统一修复。
    #29352 prepared Scope 清理后断开 Reader/旧 PartitionState 的引用。 复用原 Reader Cleanup，不再额外 Close；覆盖 repeated execute、连接空闲、取消及失败。不能据此宣布所有 prepared OOM 已解决。
    #29725 EPIPE/ECONNRESET/net.ErrClosed 进入既有远端锁换绑恢复。 binding 已变/未变、取消、最终 Unlock；不能吞掉错误并冒充锁已释放。
    #29448 登录握手在关闭竞态下取得一致状态，校验 salt 长度后构造报文。 CN/Proxy 调用成套适配；正常认证、并发关闭、非法 salt/帧都验证。
    #29558 的 NULL 完整性部分 UNIQUE 隐藏索引不保存某些 NULL 键，hinted covering/backfill 路径必须证明数据完整。 单列/复合 UNIQUE、OR、IS NULL/IS NOT NULL、join/聚合，对照无索引答案；保留有完整性证明时的合法索引访问。不捆绑整数/Decimal256 优化。

    2.1 #29586 不是只有 MORPC 一个改动

    原补丁同时包含 ISCP task-runner 查询的逻辑行读取修正：常量向量的物理长度不能代表 SQL 逻辑行数，需要正确处理零行、一行、多行和 NULL/空值。

    回迁记录应把两个修复单元分开写明，并分别带测试。既不要把整个 PR 说成“只改了一行 idle 判断”，也不要拆补丁时无意漏掉另一个仍适用的修复。

    此外，已有连接上的长 unary RPC 被 idle GC 回收，与新 backend 在 5 秒内未建立成功是不同机制。仅合入 #29586 不足以关闭所有 backend connection closed Issue，也不能据此认定近期 IVF 连接错误全部解决。

    2.2 #29558 要修完整性证明，不是全局禁用 nullable UNIQUE

    当谓词已经能证明所有索引键分量非 NULL 时，完整且合法的索引路径应继续保留。不能为了避免漏行把所有 nullable UNIQUE 查询一律改为全表扫描。OR 等复合条件必须证明每个可能返回结果的分支都满足完整性要求。

    因此应同时验收结果正确性与计划：不安全路径回退，安全路径仍可使用索引；任何必要回退的性能代价都要明示。

    3. 一个应补入清单的具体遗漏：#28693

    建议把 #28693（fix(iscp): delegate caller transaction retries，对应 #28675）补入 ISCP 专项。这不是引入新架构，而是纠正“谁有权重试”的责任边界。

    当前 4.2 的直接证据：

    1. ExecWithResult 使用 WithDisableIncrStatement().WithTxn(txn)，子 SQL 借用调用者事务，不拥有独立语句回滚边界。
    2. 同一文件的 RegisterJob、UnregisterJob、UnregisterJobsByDBName、重命名及更新 job spec 的入口仍包裹本地 retry。
    3. retry 遇到错误会再次执行回调；它本身不负责回滚借用事务中已经留下的 workspace 写入。

    所以在需要重试的错误后，helper 继续使用同一事务局部重放，可能复用失败尝试留下的写入，产生重复 transfer intent 等问题。正确责任应是：

    借用调用者事务的 ISCP helper 执行一次
→ 返回原始可重试错误
→ 外层 SQL owner 完成语句回滚与整体重放

    Main 的 修复提交 正是按这个边界修改，同时保留自有事务后台操作的通用重试。

    最小验收应复用原反例：metadata 读取后 UPDATE 返回 TxnNeedRetry，helper 必须立即返回该错误，而不是再次 UPDATE；再验证正常 register/unregister 幂等性及取消。

    #28693 不应被描述成 #28176 必然的编译依赖。 它是相邻路径中另一个明确的事务语义缺口，应一起审查，是否拆 PR 可由实际依赖决定。

    4. ISCP 不能只孤立回迁 #28176

    建议把以下语义放到同一张专项检查表中，复用现有任务 owner 和事务机制，不另外建设状态机：

    改动 需要解决的责任
    #28176 水位刷新不把 Stage 覆盖回 Init；初始化 SQL 与 Running 状态原子提交，明确旧任务兼容处置。
    #31237 的生产修正 新任务注册时正确携带生命周期版本，避免新建 Init 任务被误判为不可证明历史的旧任务而隔离。无须夹带不相关的测试提速修改。
    #28693 借用事务的 helper 不自行局部重试，错误交回外层拥有回滚能力的调用者。
    #31076 的相关生产部分 补充核对异步索引水位发布与 DROP DATABASE / ACCOUNT 的锁竞争及恢复责任，见下文。

    关于 #31076：Main 的周期水位发布使用 WaitPolicy_FastFail，发生冲突时按既有批次事务责任回滚/释放，留给下一次周期重试；不是把冲突当成功，也不是反复重放借用事务中的单条 SQL。该 PR 还有账户删除及测试等其他修改，不建议整包机械 CP。

    此处只是要求补查相关生产修正，并没有证明当前每一个账户清理超时都由它造成，也没有把它升级为无条件发布阻断。

    升级时必须考虑所有可能接管任务的 CN：仅升级一个 CN，旧 owner 仍可能把状态覆盖回去。旧任务隔离/重建会影响可用性，应给出明确运维方案；不能只添加一个 Stage 字段就声称重复初始化已彻底解决。

    5. 核心专项不能机械 CP，但也不应因难度高而长期搁置

    专项 复审判断及必要边界
    #29283 TN 点查/去重中，被 tombstone 删除的旧 RowID 不应遮住有效替代行。保留存储层反例、merge/append/tombstone/重启及写入热路径对照；不能把存储层反例夸大为所有普通 SQL 都已复现重复主键。
    #31380 最终序列化 WAL 超限需要在不可逆提交/序号消费前妥善处理。验证拒绝后的回滚、LSN/DSN 连续性、group commit 和恢复；不是只调大消息上限，也不是只升级 CN。
    #30321 行锁/范围锁、waiter 引用及物理范围两端的清理责任需要成套适配。必须保留 4.2 已有 #28529 等独立修复，不可用 Main 整文件覆盖；验证取消、换主、锁残留及竞争性能。
    #30823 对 HNSW DELETE 后 INSERT 场景应积极推进。必须使用带 MO 定制修复的 native 包，不是只改成上游版本字符串；验证旧模型读取、保存/重启、删除后插入、recall 及延迟。防止继续损坏不等于自动修复已损坏图，需单独评估重建。
    #28176 及配套修正 按上一节完成初始化、发布、重试、owner 接管与旧任务处置，不能只补水位字段。
    #29801 对应 CDC 优先评审现有 4.2 PR #32232，避免另做重复回迁；关键是失败目标事务整体重放，而不是只重试最后一条 SQL。

    这些项是否进入同一维护版本，应以目标 4.2 的验证结果决定。“需要专项验证”不代表“不重要”，特别是客户确实依赖的 HNSW、全文/向量异步索引和 CDC。

    6. 已有 4.2 PR 必须单独确认，不能视为已落地

    CDC：#32232

    本次核对为 OPEN，head e272ce87e7a8dd5282d948066732b20af27651fc，目标 4.2-dev。

    其方向与本 Issue 的 CDC 缺口匹配：识别实际驱动及包裹后的错误，活跃目标事务不做单语句重试，由外层回滚/重放未确认范围，失败时不推进 watermark；还需要正确处理 batch 所有权交接后的计数。

    PR 作者记录了单测、race 和受控目标事务 rollback 的验证，但本轮没有重跑这些测试。其证据边界也应保留：

    • 受控 rollback 不等于已经覆盖实际 TN kill/owner failover。
    • 不自动修复重复 CN ownership。
    • 不自动清理已有 N: 状态记录。
    • 已经在旧逻辑下发生错误提交或错误推进水位的数据，需要另行检查/修复，不能承诺升级后历史数据自动一致。

    因此优先评审该 PR 的目标分支闭环，不再盲目重复搬 #29801。

    ODKU：#31979

    本次核对为 OPEN，head 6c2d460de5b2a161cbec01229a6df6f322b87c55，目标 4.2-dev。

    不直接 CP #28265 的结论仍然正确，但不能由此忽略 ODKU 多约束、更新顺序及索引一致性。应独立评审 #31979 这份 4.2 适配方案。

    特别注意其 protocol 12 / coordinated CN rollout 要求：本地 gate 拒绝低协议 ordered plan，不等于旧二进制自动理解新计划，也不能视为已经证明任意新旧 CN 混跑安全。历史已损坏的基表/索引同样不会自动修复。

    7. 条件项、后置项及明确排除项

    保留原先按实际业务/配置选择的思路：

    可排后续批次，但不是永久不修：

    明确不原样 CP：

    8. 建议的实施顺序和最小验收

    1. 先做第 2 节的集中修复，并优先评审已有 CDC fix(cdc): replay deadlocked target transactions on 4.2-dev #32232。 MORPC 三项按共享生命周期联合验证；其他项按独立语义拆分，避免一个大 PR 混入所有东西。
    2. 准备 HNSW、ISCP、TN/WAL、锁专项。 ISCP 补进 fix(iscp): delegate caller transaction retries #28693、核对 fix(iscp): preserve fresh init jobs and shorten embedded test waits #31237 和 fix: resolve async index lock contention during catalog teardown #31076；是否同批发布由目标版本证据决定，不因“改动大”无限后置，也不为赶版本省掉验证。
    3. 客户实际命中的条件项再追加。 不混入无关工具链升级、Main 新缓存架构或尚无适用性证据的大优化。

    每个接受项用现有测试与回归设施留下最小可审计记录即可，不建设额外平台：

    • 固定目标 4.2 SHA、原始补丁、实际回迁 SHA 和最终镜像。
    • 尽量做到旧目标反例失败、回迁后通过；无法复现的项明确缺证据，不能以文本 apply-check 代替。
    • 正常业务对照，以及与改动相关的失败、取消、重试、部分初始化、Close、重启/换代检查。
    • 热路径改动测量锁竞争、分配、I/O、吞吐及延迟；不承诺未经测量的“零性能影响”。
    • 明确升级组件、混版本限制、旧任务/损坏索引处置和回滚边界。
    • 单项验收后，再对最终组合镜像跑现有回归和相关故障场景；通过、失败、跳过、未执行分开记录。

    工程上优先找到已有 owner、事务边界和 Cleanup 路径，确保资源只终结一次、等待可退出、重试有界；同步删除被替代的旧条件，不维护两套同义状态机或校验路径。

    最终建议：接受此清单作为回迁工作基线；补齐上述遗漏、配套和证据边界后逐项推进。现在不能宣称整批已验证可发布，也不能将本清单用于证明客户当前事故已经修复。

  4. LeftHandCold commented on Nov 5, 2026

    @LeftHandCold
    LeftHandCold
    on Nov 5, 2026
    CollaboratorAuthor

    再次逐路径复审：整体计划可推进，但 #29725 的 4.2 适用性需要更正

    对照 上一条复审、原 Issue、Main 合入补丁及目标分支源码后，结论是：

    保留“最小语义修复先行、核心专项适配、场景项按需追加”的总体安排，不整批 CP。但首批 #29725 的原理由不能沿用：当前 4.2 并没有 Main 上导致 EPIPE 提前退出 Unlock 的判断。此前把它作为已确认的 4.2 解锁残留修复推荐，判断过宽，这里明确更正。

    审查范围与证据边界

    • 目标：4.2-dev@ebf03dc42bf25ba00018da019783e1037299d1ae。
    • Main：d2dab994dd87445b5f5d44a06293bd5e09a1eee9。
    • 重点深入追踪首批候选的调用、错误、关闭和释放路径；核对 ISCP 后续修正、HNSW native 来源、TN/WAL 和文件读取的分支差异；其余项目复核排期和适用边界。
    • 这是回迁计划及源码适用性复审，不是对 30 个 PR 全部实现重新出具发布批准。本轮没有执行 CP、修改生产代码、编译、UT/BVT、故障注入或性能测试。原 PR 的测试叙述不计作本轮已通过的目标分支证据。
    • 工作树原有修改未动；没有修改 Issue 正文、标签或分支。

    1. 实质性更正：#29725 不能继续按“4.2 的 Unlock 跳过换绑恢复”列为必修

    Main 原问题有明确的前提：在 #29725 的父提交中，unlockWithContext 包含：

    if !retryRemoteUnlockError(err) {
    // 特定错误的处理……
    return err
}

    EPIPE 未被分类为可重试错误，会在到达 allocator 检查之前返回。这段判断见 Main 修复前源码。

    但是当前 4.2 的实际路径不同：

    1. unlockWithContext 在 doUnlock 失败后直接调用 handleErrorWithContext，没有上述 retryRemoteUnlockError 提前返回判断。
    2. handleErrorWithContext 中的 retryRemoteLockError 只决定是否把错误包装为 ErrBackendCannotConnect；它不控制是否查询 allocator。未分类的 EPIPE 同样继续执行 binding 检查。
    3. binding 改变时走已有换绑处理；binding 未变时，Unlock 保留退避重试；调用者取消则退出。这不是“收到 EPIPE 就视为解锁成功”。
    4. 公共 Unlock 仍按实际清理结果处理事务：失败保留，成功才释放。

    因此：原 Main 的“分类遗漏 → 提前返回 → 未换绑 → closing txn 残留”因果链不能直接套到这个 4.2 基线。

    这不表示 #29725 完全没有价值。错误归一化还会影响普通 Lock 返回后是否进入 lockop 的有界重试。如果要回迁，应按这个实际收益单独给出反例与验收；建议改列“错误分类/重试一致性补齐”，不再用已确认解锁残留作为首批必修理由，也不要为复现 Main 问题引入它的整套前置锁重构。

    2. 原首批其余八项：继续优先，修复范围保持收敛

    原 PR 本轮目标源码核对 回迁要求
    #30761 首次 replay 完成前收到 pause(false)，receiver 等 resume；成功分支随后只切换 first/ready，没有补上恢复责任交接。 按 4.2 现有 connector 适配；首次回放前/中/后断流、退出和真实 SQL 可用性都验证。不要整包引入 Main 的其他 PushClient 生命周期改造。
    #29586 idle GC 仍按锁状态及活动时间判定，没有待完成 unary Future 的原子复核与 admission 封闭。 保留已有 Future map 和有界 cleanup，不加一套占用计数。覆盖完成/取消/超时、清理队列满，以及 GC 与新请求竞争。
    #29559 FinishStream 仍持有 streamStateMu 同步等待 Write，而 writer 退出路径需要同一把锁执行 Close。 需要终结认领和消息/Future 所有权一起修；不能只移动 Write。与 #30536 联合验证。
    #30536 clientSession.Close 仍调用连接 Close；writer finalizer 尚未独立承担最终引用释放。已核对 4.2 所用 goetty：Disconnect 打断连接，Close 还会减引用并在归零时释放缓冲。 打断 I/O 与最终释放分开；writer 正常/异常退出和启动被拒绝均有唯一释放责任。成功发送、重复 Close 和取消要保持原语义。
    #28384 未绑定 allocation account 的 off-heap realloc 仍先进入物理分配器，再删除旧地址元数据；存在地址被其他分配复用的窗口。 元数据/profile 先摘除，物理 realloc 失败恢复；不动已受 account 管理的其他分配路径。不是通用 OOM 修复。
    #29352 Scope 的 defer 执行 Pipeline Cleanup 后仍保留 DataSource.R。 由原 pipeline 关闭 reader，再断开非 const reader 引用；不能重复 Close。验证 prepared 重复执行、执行间空闲及失败/取消。
    #29448 握手仍多次调用 GetSalt 并直接切片；关闭会清空 salt。Proxy 额外信息的边界修正也属于原补丁。 CN/Proxy 签名和调用者一起适配；正常认证、关闭竞态、短 salt、额外信息长度边界一起验证。
    #29558 的 NULL 完整性部分 hinted covering/backfill 入口尚无 UNIQUE NULL 行完整性保护。 只取完整性判断及对应测试；AND/OR、复合键、NULL 谓词要正确，能证明所有键非 NULL 的合法索引计划继续保留。不要顺带搬整数/Decimal256 重写。

    关键定位：
    首次 replay、
    idle GC、
    FIN/Write、
    writer finalizer、
    realloc、
    Scope Cleanup、
    握手、
    hinted backfill。

    #29586 另含 ISCP task runner 逻辑行数读取修复，仍应独立记录并带测试，避免只看 MORPC 标题而漏掉。三项 MORPC 修复可以分别提交，但组合验收应覆盖同一发送—终结—释放链。

    3. ISCP：补充项成立，但区分独立修复与真正配套

    新旧 CN 的任务接管限制、旧任务隔离/重建仍需明确。#31237 修好新任务注册，不等于允许旧 executor 随意接管这些新任务。

    4. 其余分组与工程边界

    类别 项目与复核意见
    六个核心专项 #29283、#31380、#30321、#30823、#28176 及配套、#29801 对应 CDC：保留专项安排。TN 点查/去重与最终 WAL 拒绝涉及存储和回滚；锁修复须保留 4.2 已有 #28529；HNSW 需要 MO 定制的 usearch tarball，不是替换上游版本号。
    已有 4.2 实现 #32232（CDC）和 #31979（ODKU）当前仍 OPEN，优先评审已有方案，不再重复搬 #29801/#28265。#31979 明确要求 coordinated protocol-12 CN rollout，不能推导成任意混版本安全。
    按场景选择 #29199、#29397、#29066、#32053、#32137、#30519；另将 #29725 按上述实际错误分类收益重新评估。大参数协议、显式事务 DDL、并发加外键和对象存储读取要分别确认使用前提。
    可后置 #29092 只取 FIFO 回收进度语义；#30109、#32022 按升级/重连和日志阻塞场景提高优先级；#29860 是协议边界加固；#31574 保持待核实，不以近期 OOM 为适用性证据。
    不原样搬 #30117 的 HNSW 策略已被 #30989 撤回；#29692 对应 Go 1.27.0，而目标默认是 1.26.4；#28525 不覆盖更完整的 4.2 备份选择；#28265 不整包搬，走 #31979 的独立评审。

    几项容易在实施中误判的边界：

    5. 调整后的执行结论

    1. 原首批八项继续优先：fix(disttae): reconnect after logtail failure during first catalog replay #30761、fix(morpc): preserve live unary requests during idle GC #29586、fix(morpc): unblock FIN teardown when writer exits #29559、fix(morpc): retain writer buffers until write loop exits #30536、fix(mpool): retire realloc address state before physical reuse #28384、fix(compile): release completed prepared scan readers #29352、fix(frontend): prevent pre-auth handshake panics #29448、fix(planner): preserve exact integer filtering and nullable unique index completeness #29558 的 NULL 完整性部分。
    2. fix(iscp): delegate caller transaction retries #28693 独立优先评审；fix(lockservice): recover closed connections before unlock cleanup #29725 改为错误分类/重试一致性评估，不沿用错误的 4.2 Unlock 残留理由。不是为了凑固定“九项”。
    3. 优先推进现有 CDC fix(cdc): replay deadlocked target transactions on 4.2-dev #32232；HNSW、ISCP、TN/WAL、锁和 ODKU 按目标分支证据分别确定发布批次，不要求全部捆绑，也不因复杂而无限后置。
    4. 复用已有 owner、事务、Cleanup、回归设施；不要增加第二套状态机或为了 CP 引入整套 Main 架构。单项目标分支证据和最终组合镜像回归分开验收。
    5. 客户 4.2.1 hotfix 与本 4.2-dev 清单分开核对；本评论不批准任何客户环境升级或发布。

    最终 review：总体回迁设计合理；修正 #29725 的适用性判断后可作为实施清单推进。当前不具备“这些补丁已在 4.2 验证无风险、可以直接发布”的证据。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

kind/tech-requestNew feature or request

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions