Re: where should I stick that backup? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: where should I stick that backup?
Date
Msg-id CA+TgmoYm6+25yBsCzV4qQ4QSG1r0NEg9qjLa-XaBQyUm3NX=vw@mail.gmail.com
Whole thread Raw
In response to Re: where should I stick that backup?  (Andres Freund <andres@anarazel.de>)
Responses Re: where should I stick that backup?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: where should I stick that backup?
Next
From: Tomas Vondra
Date:
Subject: Re: sqlsmith crash incremental sort