On Wed, Feb 10, 2016 at 2:46 PM, Andres Freund <andres@anarazel.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.
