来源: docs/design.md §3.2 WAL Oracle 架构审查
步骤 ⑥ 要求"只做内存内编码,不得触碰 WAL 文件或任何可能被 recovery 看到的 WAL 缓冲区"。步骤 ⑦ 的 WAL write 失败判断标准取决于"zero bytes reached WAL state"。
这涉及实现层面的缓冲模型选择,直接影响 ErrCommitUnknown 的判断:
ErrCommitUnknown
模型 A: 私有 encode buffer + write()
batch → private []byte → write(fd, batchBytes)
write()
模型 B: 共享 buffered writer
batch → shared bufio.Writer → flush() → write(fd)
bufio.Write()
bufio.Writer
推荐模型 A(私有 buffer + 直接 write),因为:
No dependencies set.
The note is not visible to the blocked user.
来源: docs/design.md §3.2 WAL Oracle 架构审查
问题描述
步骤 ⑥ 要求"只做内存内编码,不得触碰 WAL 文件或任何可能被 recovery 看到的 WAL 缓冲区"。步骤 ⑦ 的 WAL write 失败判断标准取决于"zero bytes reached WAL state"。
这涉及实现层面的缓冲模型选择,直接影响
ErrCommitUnknown的判断:两种模型
模型 A: 私有 encode buffer + write()
write()调用前:零 WAL 副作用,失败 = 普通错误write()调用后:可能有 WAL 副作用,失败 =ErrCommitUnknownwrite()模型 B: 共享 buffered writer
bufio.Write()进入共享缓冲区时,该缓冲区可能被其他 batch 共享需要明确
bufio.Writer,是否需要 per-batch 的 WAL 副作用边界标记?write()"?建议
推荐模型 A(私有 buffer + 直接 write),因为:
ErrCommitUnknown判断边界清晰