Re: [WIP] Pipelined Recovery

Hi Xuneng,

> I share the concern here. It might be simpler to make the startup
> process the owner of recovery policy and make the producer a bounded,
> policy-free WAL reader. It might not be viable to decouple them
> cleanly since decoding is what discovers edege cases such as
> incomplete WAL, missing continuation records, and read boundaries.
> Still wondering whether those conditions can be reported to startup as
> events rather than letting the producer making these policy decisions.

Thanks for the thoughtful response. I agree with you.

I like the idea of keeping the startup as the single owner of recovery
policy, while keeping the producer bound to reading and decoding WAL
and reporting conditions. As you pointed out, decoding will naturally
discover edge cases such as incomplete WAL, missing continuation
records, and read-boundary issues. However, the policy decision for
those cases should remain in startup to avoid split authority.

An event-based contract seems like a good way to define this boundary:
the producer reports a typed condition with LSN context, and startup
decides the appropriate action. This should also make ownership
clearer across startup-local state, producer-local state,
WalPipelineParams, and mutable shared state, including which copy is
authoritative.

Even if this approach provides a smaller performance improvement than
the current v6 design, it may still be a worthwhile first phase if it
improves correctness and simplifies the architecture. Further
performance optimizations can be explored once the ownership and
communication contracts are stable.

Best Regards,
Nitin Jadhav
Azure Database for PostgreSQL
Microsoft