On Sun, Feb 05, 2023 at 09:49:57AM +0900, Michael Paquier wrote:
> - Should we include archive_cleanup_command into the recovery modules
> at all? We've discussed offloading that from the checkpointer, and it
> makes the failure handling trickier when it comes to unexpected GUC
> configurations, for one. The same may actually apply to
> restore_end_command. Though it is done in the startup process now,
> there may be an argument to offload that somewhere else based on the
> timing of the end-of-recovery checkpoint. My opinion on this stuff is
> that only including restore_command in the modules would make most
> users I know of happy enough as it removes the overhead of the command
> invocation from the startup process, if able to replay things fast
> enough so as the restore command is the bottleneck.
> restore_end_command would be simple enough, but if there is a wish to
> redesign the startup process to offload it somewhere else, then the
> recovery module makes backward-compatibility concerns harder to think
> about in the long-term.
I agree. I think we ought to first focus on getting the recovery modules
interface and restore_command functionality in place before we take on more
difficult things like archive_cleanup_command. But I still think the
archive_cleanup_command/recovery_end_command functionality should
eventually be added to recovery modules.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com