Re: recovery modules

Hi,

On 2022-12-27 11:24:49 -0800, Nathan Bossart wrote:
> I've attached a patch set that adds the restore_library,
> archive_cleanup_library, and recovery_end_library parameters to allow
> archive recovery via loadable modules. This is a follow-up to the
> archive_library parameter added in v15 [0] [1].

Why do we need N parameters for this? To me it seems more sensible to have one
parameter that then allows a library to implement all these (potentially
optionally).

> * Unlike archive modules, recovery libraries cannot be changed at runtime.
> There isn't a safe way to unload a library, and archive libraries work
> around this restriction by restarting the archiver process. Since recovery
> libraries are loaded via the startup and checkpointer processes (which
> cannot be trivially restarted like the archiver), the same workaround is
> not feasible.

I don't think that's a convincing reason to not support configuration
changes. Sure, libraries cannot be unloaded, but an unnecessarily loaded
library is cheap. All that's needed is to redirect the relevant function
calls.

> * pg_rewind uses restore_command, but there isn't a straightforward path to
> support restore_library. I haven't addressed this in the attached patches,
> but perhaps this is a reason to allow specifying both restore_command and
> restore_library at the same time. pg_rewind would use restore_command, and
> the server would use restore_library.

That seems problematic, leading to situations where one might not be able to
use restore_command anymore, because it's not feasible to do
segment-by-segment restoration.

Greetings,

Andres Freund