On Mon, Feb 25, 2019 at 10:14 PM Andres Freund <andres@anarazel.de> wrote:
On 2019-02-25 08:42:02 -0500, Stephen Frost wrote: > Greetings, > > * Andres Freund (andres@anarazel.de) wrote: > > On 2019-02-24 17:19:22 -0500, Stephen Frost wrote: > > > You say above that the new interface is unquestionably an improvement > > > > FWIW, I think we didn't design it even remotely as well as we ought to > > have. It was both a mistake to not offer a version of non-exclusive > > backups that works with a client connection (for integration with the > > TSMs of this world), and it was a mistake not to offer a commandline > > tool that does the non-exclusive pg/start backup. > > I'm not really following- did you mean to say "without a client > connection" above?
Yes.
> We could still add some kind of commandline tool to help with the > non-exclusive pg start/stop backup
That doesn't help, as long as the connection requirement is there. As explained elsewhere in this thread, a lot of larger external backup infrastructure just gives you a start/stop hook, and that makes using a persistent connection hard and fragile.
In my experience they don't just give you that. They also give you a module that calls the postgres APIs to do backups.
Some of them are using the old API, some are using the new one. The only thing that would be required there would be to upgrade the module to one that supports the 9.6 APIs. (And you have to upgrade those modules whenever you upgrade oracle or mssql or whatever else you have, so that's not something those organisations are unused to)
I agree with the need for as simpler way to drive it in the simple case or in the say filesystem snapshot case, but I'm not sure the pre/post case is all that common in this context? Some certainly use it today even if they don't have to, but that can probably be easily changed to such a "simplified cmd tool" that you have suggested elsewhere as well.