On Tue, Jul 20, 2021 at 4:03 PM Mark Dilger <mark.dil...@enterprisedb.com> wrote: > I was only imagining having a callback for injecting manifests or recovery > configurations. It is not necessary that this be done in the current patch > set, or perhaps ever.
A callback where? I actually think the ideal scenario would be if the server always did all the work and the client wasn't involved in editing the tarfile, but it's not super-easy to get there from here. We could add an option to tell the server whether to inject the manifest into the archive, which probably wouldn't be too bad. For it to inject the recovery configuration, we'd have to send that configuration to the server somehow. I thought about using COPY BOTH mode instead of COPY OUT mode to allow for stuff like that, but it seems pretty complicated, and I wasn't really sure that we'd get consensus that it was better even if I went to the trouble of coding it up. If we don't do that and stick with the current system where it's handled on the client side, then I agree that we want to separate the tar-specific concerns from the injection-type concerns, which the patch does by making those operations different kinds of bbstreamer that know only a relatively limited amount about what each other are doing. You get [server] => [tar parser] => [recovery injector] => [tar archiver], where the [recovery injector] step nukes the archive file headers for the files it adds or modifies, and the [tar archiver] step fixes them up again. So the only thing that the [recovery injector] piece needs to know is that if it makes any changes to a file, it should send that file to the next step with a 0-length archive header, and all the [tar archiver] piece needs to know is that already-valid headers can be left alone and 0-length ones need to be regenerated. There may be a better scheme; I don't think this is perfectly elegant. I do think it's better than what we've got now. -- Robert Haas EDB: http://www.enterprisedb.com
