Robert Haas <robertmhaas@gmail.com> writes:
> I think that we could certainly, as Michael suggests, have people
> provide their own background worker rather than having the archiver
> invoke the user-supplied code directly. As long as the functions that
> you need in order to get the necessary information can be called from
> some other process, that's fine. The only difficulty I see is that if
> the archiving is happening from a separate background worker rather
> than from the archiver, then what is the archiver doing? We could
> somehow arrange to not run the archiver process at all, or I guess to
> just sit there and have it do nothing. Or, we can decide not to have a
> separate background worker and just have the archiver call the
> user-supplied core directly. I kind of like that approach at the
> moment; it seems more elegant to me.
I'm fairly concerned about the idea of making it common for people
to write their own main loop for the archiver. That means that, if
we have a bug fix that requires the archiver to do X, we will not
just be patching our own code but trying to get an indeterminate
set of third parties to add the fix to their code.
If we think we need primitives to let the archiver hooks get all
the pending files, or whatever, by all means add those. But don't
cede fundamental control of the archiver. The hooks need to be
decoration on a framework we provide, not the framework themselves.
regards, tom lane