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
