On Sun, Apr 12, 2020 at 3:17 PM Andres Freund <and...@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