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

  1. Redesign archive modules

  2. Remove uses of AssertVariableIsOfType() obsoleted by f2b73c8

  3. Rename contrib module basic_archive to basic_wal_module

  4. Refactor code for restoring files via shell commands

  5. Refactor code in charge of running shell-based recovery commands