Re: Updated backup APIs for non-exclusive backups

On Wed, Feb 10, 2016 at 2:46 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
> On 2016-02-10 13:46:05 +0100, Magnus Hagander wrote:
> > Per discussionat the developer meeting in Brussels, here's a patch that
> > makes some updates to the backup APIs, to support non-exclusive backups
> > without using pg_basebackup.
>
> Thanks for following through with this!
>
> > * If the client disconnects with a non-exclusive backup running, the
> backup
> > is automatically aborted. This is the same thing that pg_basebackup does.
> > To use these non-exclusive backups the backup software will have to
> > maintain a persistent connection to the database -- something that should
> > not be a problem for any of the modern ones out there (but would've been
> > slightly trickier back in the days when we suggested shellscripts)
>
> I think we might want to make this one optional, but I'm not going to
> fight super hard for it.
>

Not sure what you're referring to here. Do you mean being able to make a
non-exclusive backup while not maintaining a connection? That's going to
make things a *lot* more complicated, as we'd have to invent something like
"backup slots" similar to what we're doing with replication slots. I doubt
it's worth all that work and complexity.

>
> > * A new version of pg_stop_backup is created, taking an argument
> specifying
> > if it's exclusive or not. The current version of pg_stop_backup()
> continues
> > to work for exclusive backups, with no changes to behavior. The new
> > pg_stop_backup will return a record of three columns instead of just the
> > value -- the LSN (pglsn), the backup label file (text) and the tablespace
> > map file (text).
>
> I wonder if we shouldn't change the API a bit more aggressively. Right
> now we return the label and the map - but what if there's more files at
> some later point? One way would be to make it a SETOF function returning
> 'filename', 'content' or such. Makes it less clear what to do with the
> lsn admittedly.
>

*Adding* more columns to the API shouldn't be a problem in the future. If
there's another file, we can return a fourth column. A backup program is
going to have to know about those things anyway and shouldn't just blindly
write those files to the backup, IMO.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/