Re: [WIP] Pipelined Recovery

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