Hi, +1 on the overall direction. Decoupling WAL decode from redo looks like a promising way to improve CPU-bound recovery, and the performance numbers are encouraging. Thanks for posting v6; I reviewed the series at a high level.
My main concern is the startup-to-producer state handoff. Startup exports a broad recovery snapshot, but the producer appears to restore only part of it. That can leave the two sides operating with different views of the recovery state. This becomes more important because the state is spread across startup-local state, producer-local state, WalPipelineParams, and shared mutable state. In this model, correctness depends on a clear ownership contract for each field: who writes it, who reads it, when it may change, and which copy is authoritative if values diverge. Without that contract, it is difficult to reason about behavior under races. Relatedly, it would help to document queue/replay invariants in one place: strict LSN ordering, no silent drop/skip, defined ordering between data and shutdown/error messages, and clear behavior on queue-full and early-exit paths. The consumer side in-place deserialization path also needs an explicit memory-lifetime guarantee, so pointer validity during redo is unambiguous. Best Regards, Nitin Jadhav Azure Database for PostgreSQL Microsoft
