On Sat, Nov 05, 2022 at 02:08:58PM -0700, Nathan Bossart wrote:
> Such a module could define a custom GUC that accepts a shell command. I
> don't think we should overload the meaning of archive_command based on the
> whims of whatever archive module is loaded. Besides the potential end-user
> confusion, your archive_command might be unexpectedly used incorrectly if
> you forget to set archive_library.
While mostly copying the logic from shell_archive.c to build the
command to execute (aka shell_archive_file), which is not great as
well. But well, perhaps my whole line of argument is just moot..
> Perhaps we could eventually move the archive_command functionality to a
> contrib module (i.e., "shell_archive") so that users must always set
> archive_library. But until then, I suspect it's better to treat modules
> and commands as two separate interfaces to ease migration from older major
> versions (even though archive_command is now essentially a built-in archive
> module).
I agree that this is a fine long-term goal, removing all traces of the
archive_command from the backend core code. This is actually an
argument in favor of having no traces of XLogArchiveCommand in
pgarch.c, no? ;p
I am not sure how long we should wait before being able to do that,
perhaps a couple of years of least? I'd like to think the sooner the
better (like v17?) but we are usually conservative, and the removal of
the exclusive backup mode took 5~6 years if I recall correctly..
--
Michael
