Oracle 审核 docs/design.md Section 3.2 WAL
docs/design.md
Section 3.2 "恢复完成状态"（~line 575）与 "持久化策略"（~line 96）
Recovery 重放所有 CRC 合法、sequence 连续的 WAL batch，并在恢复完成后将其全部标记为 published。但其中可能包含崩溃前从未 fsync 确认（调用方未收到成功）的 batch。
published
场景：
write()
Always 策略下，调用方收到的语义是 "Put 返回成功 = 已持久化"。但如果进程 crash（非掉电），未确认的写入可能变成已发布。这是一个 API 语义问题而非数据安全问题。
Always
在 Section 3.2 "持久化策略" 或 "恢复完成状态" 中显式声明：
进程崩溃（非掉电）后恢复时，OS page cache 中已写入但尚未 fsync 的完整 WAL Batch 可能被恢复并视为已发布。这不是数据丢失，而是数据可见性前移。 调用方必须理解：进程崩溃重启后，比掉电场景可能多恢复一些写入。 如果需要严格区分"调用方已确认"与"未确认但存在于 WAL"，需要后续引入 durable commit marker 或 confirmed-sequence 元数据。
进程崩溃（非掉电）后恢复时，OS page cache 中已写入但尚未 fsync 的完整 WAL Batch 可能被恢复并视为已发布。这不是数据丢失，而是数据可见性前移。 调用方必须理解：进程崩溃重启后，比掉电场景可能多恢复一些写入。
如果需要严格区分"调用方已确认"与"未确认但存在于 WAL"，需要后续引入 durable commit marker 或 confirmed-sequence 元数据。
No dependencies set.
The note is not visible to the blocked user.
来源
Oracle 审核
docs/design.mdSection 3.2 WAL位置
Section 3.2 "恢复完成状态"（~line 575）与 "持久化策略"（~line 96）
问题描述
Recovery 重放所有 CRC 合法、sequence 连续的 WAL batch，并在恢复完成后将其全部标记为
published。但其中可能包含崩溃前从未 fsync 确认（调用方未收到成功）的 batch。场景：
write()写入 OS page cache影响
Always策略下，调用方收到的语义是 "Put 返回成功 = 已持久化"。但如果进程 crash（非掉电），未确认的写入可能变成已发布。这是一个 API 语义问题而非数据安全问题。建议修复
在 Section 3.2 "持久化策略" 或 "恢复完成状态" 中显式声明：