I think we're better off clearly documenting that we don't care about
it. And basically let the external command be responsible for that part.
So for example, your typical backup manager would listen to this
signal or whatever to react quickly. But it would *also* have some sort of fallback. For example, whenever it's triggered it also checks if there are any previous segments it missed (this would also cover the startup sequence).
I'm fine with the backup manager doing all the work of keeping track of what has been compressed, moved to archive, etc. No need to reinvent the wheel here.
For my part I still prefer an actual command to be executed so it will start/restart the archiver if it is not already running or died. This reduces the number of processes that I need to ensure are running.
If the consensus is that a signal is better then I'll make that work. I will say this raises the bar on what is required to write a good archive command and we already know it is quite a difficult task.
I like the idea of a command as well, for flexibility. If you want a signal, you can write a trivial command that sends the signal... Maximum flexibility, as long as we don't create a lot of caveats for users.
