Re: where should I stick that backup?

Greetings,

* Noah Misch (noah(at)leadboat(dot)com) wrote:
> On Fri, Apr 03, 2020 at 10:19:21AM -0400, Robert Haas wrote:
> > What I'm thinking about is: suppose we add an option to pg_basebackup
> > with a name like --pipe-output. This would be mutually exclusive with
> > -D, but would work at least with -Ft and maybe also with -Fp. The
> > argument to --pipe-output would be a shell command to be executed once
> > per output file. Any instance of %f in the shell command would be
> > replaced with the name of the file that would have been written (and
> > %% would turn into a single %). The shell command itself would be
> > executed via system(). So if you want to compress, but using some
> > other compression program instead of gzip, you could do something
> > like:
> >
> > pg_basebackup -Ft --pipe-output 'bzip > %f.bz2'
>
> Seems good to me. I agree -Fp is a "maybe" since the overhead will be high
> for small files.

For my 2c, at least, introducing more shell commands into critical parts
of the system is absolutely the wrong direction to go in.
archive_command continues to be a mess that we refuse to clean up or
even properly document and the project would be much better off by
trying to eliminate it rather than add in new ways for users to end up
with bad or invalid backups.

Further, having a generic shell script approach like this would result
in things like "well, we don't need to actually add support for X, Y or
Z, because we have this wonderful generic shell script thing and you can
write your own, and therefore we won't accept patches which do add those
capabilities because then we'd have to actually maintain that support."

In short, -1 from me.

Thanks,

Stephen