Re: Updated backup APIs for non-exclusive backups
От | Andres Freund |
---|---|
Тема | Re: Updated backup APIs for non-exclusive backups |
Дата | |
Msg-id | 20160210134607.cho7tdrrbevuncwh@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Updated backup APIs for non-exclusive backups (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Updated backup APIs for non-exclusive backups
Re: Updated backup APIs for non-exclusive backups |
Список | pgsql-hackers |
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. > * 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. Regards, Andres
В списке pgsql-hackers по дате отправления: