On 2021/11/02 3:54, Bossart, Nathan wrote:
This thread is a continuation of the thread with the subject "parallelizing the archiver" [0]. That thread had morphed into an effort to allow creating archive modules, so I've created a new one to ensure that this topic has the proper visibility.
What is the main motivation of this patch? I was thinking that it's for parallelizing WAL archiving. But as far as I read the patch very briefly, WAL file name is still passed to the archive callback function one by one. Are you planning to extend this mechanism to other WAL archiving-related commands like restore_command? I can imagine that those who use archive library (rather than shell) would like to use the same mechanism for WAL restore.
I've attached the latest patch from the previous thread. This patch does a few things. First, it adds the archive_library GUC that specifies a library to use in place of archive_command. If archive_library is set to "shell" (the default), archive_command is still used. The archive_library is preloaded, so its _PG_init() can do anything that libraries loaded via shared_preload_libraries can do. Like logical decoding output plugins, archive modules must define an initialization function and some callbacks. The patch also introduces the basic_archive module to ensure test coverage on the new infrastructure.
I think that it's worth adding this module into core rather than handling it as test module. It provides very basic WAL archiving feature, but (I guess) it's enough for some users. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
