On Sun, Apr 12, 2020 at 3:17 PM Andres Freund <andres@anarazel.de> wrote:
> A huge advantage of a scheme like this would be that it wouldn't have to
> be specific to pg_basebackup. It could just as well work directly on the
> server, avoiding an unnecesary loop through the network. Which
> e.g. could integrate with filesystem snapshots etc. Without needing to
> build the 'archive target' once with server libraries, and once with
> client libraries.
That's quite appealing. One downside - IMHO significant - is that you
have to have a separate process to do *anything*. If you want to add a
filter that just logs everything it's asked to do, for example, you've
gotta have a whole process for that, which likely adds a lot of
overhead even if you can somehow avoid passing all the data through an
extra set of pipes. The interface I proposed would allow you to inject
very lightweight filters at very low cost. This design really doesn't.
Note that you could build this on top of what I proposed, but not the
other way around.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company