Re: archive modules

I've just realized I forgot to CC the active participants on the last
thread to this one, so I've attempted to do that now. I didn't
intentionally leave anyone out, but I'm sorry if I missed someone.

On 11/1/21, 10:24 PM, "Michael Paquier" <michael(at)paquier(dot)xyz> wrote:
> It seems to me that this patch is not moving into the right direction
> implementation-wise (I have read the arguments about
> backward-compatibility that led to the introduction of archive_library
> and its shell mode), for what looks like a duplicate of
> shared_preload_libraries but for an extra code path dedicated to the
> archiver, where we could just have a hook instead? We have been
> talking for some time now to make the archiver process more
> bgworker-ish, so as we finish with something closer to what the
> logical replication launcher is.

Hm. It sounds like you want something more like what was discussed
earlier in the other thread [0]. This approach would basically just
add a hook and call it a day. My patch for this approach [1] moved
the shell archive logic to a test module, but the general consensus
seems to be that we'd need to have it be present in core (and the
default).

Nathan

[0] https://postgr.es/m/8B7BF404-29D4-4662-A2DF-1AC4C98463EB%40amazon.com
[1] https://postgr.es/m/attachment/127385/v2-0001-Replace-archive_command-with-a-hook.patch