Re: recovery modules
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, pgsql-hackers@postgresql.org
Date: 2023-01-28T00:09:39Z
Lists: pgsql-hackers
Hi, On 2023-01-27 15:28:21 -0800, Nathan Bossart wrote: > The more I think about this, the more I wonder whether we really need to > include archive_cleanup_command and recovery_end_command in recovery > modules. I think it would be hard to write a good module that isn't just implementing the existing commands without it. Needing to clean up archives and reacting to the end of recovery seems a pretty core task. > Another weird thing with the checkpointer is that the restore_library will > stay loaded long after recovery is finished, and it'll be loaded regardless > of whether recovery is required in the first place. I don't see a problem with that. And I suspect we might even end up there for other reasons. I was briefly wondering whether it'd be worth trying to offload things like archive_cleanup_command from checkpointer to a different process, for robustness. But given that it's pretty much required for performance that the module runs in the startup process, that ship probably has sailed. Greetings, Andres Freund
Commits
-
Redesign archive modules
- 35739b87dcfe 16.0 landed
-
Remove uses of AssertVariableIsOfType() obsoleted by f2b73c8
- 30b789eafed2 16.0 landed
-
Rename contrib module basic_archive to basic_wal_module
- 0ad3c60caf5f 16.0 landed
-
Refactor code for restoring files via shell commands
- 14bdb3f13de1 16.0 landed
-
Refactor code in charge of running shell-based recovery commands
- 9a740f81eb02 16.0 landed