Re: Remove Deprecated Exclusive Backup Mode - Mailing list pgsql-hackers
From | Andres Freund |
---|---|
Subject | Re: Remove Deprecated Exclusive Backup Mode |
Date | |
Msg-id | 20190225211417.cddpxhsrj5vuessw@alap3.anarazel.de Whole thread Raw |
In response to | Re: Remove Deprecated Exclusive Backup Mode (Stephen Frost <sfrost@snowman.net>) |
Responses |
Re: Remove Deprecated Exclusive Backup Mode
Re: Remove Deprecated Exclusive Backup Mode |
List | pgsql-hackers |
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. > but I'm not really sure exactly what that would look like and I > honestly don't have terribly much interest in spending resources on > implementing it since it would lack a great many features that we'd > then end up wanting to add on... and then we end up backing into > building yet another backup tool. Meh. You are proposing to remove a feature (even if a dangerous one). Requiring some minimal compat work to make htat more palpaple isn't crazy. Nor does using backrest or whatnot do *ANYTHING* about the users of large company wide backup tools. > > > I really, honestly, believe what we need to *stop* doing is trying to > > > drag along support for old/deprecated interfaces after we've introduced > > > new ones, thus avoiding these arguments and the time spent on them, and > > > the time spent dealing with implementing and documenting new APIs around > > > old ones. The only thing it seems to unquestionably do is make us argue > > > about when we are going to *finally* rip out the old/deprecated API (or > > > interface, or whatever you want to call it). > > > > While I agree that we should remove non-exclusive backups, I VEHEMENTLY > > oppose the unconditionality of the above statement. Yes, it's annoying > > to keep interfaces around, but unnecessarily inflicting pain to everyone > > also is annoying. > > Alright, then how about we provide a bit of help for everyone who's got > a system built around recovery.conf today, instead of just completely > ripping that out? Oh, comeon. Obviously we're sometimes going to have to make breaking changes. But you're essentially arguing that we shouldn't provide compat where we can come up with a reasonable way to provide backward compatibility. And I think that's crazy and will hurt postgres. > > That's not to say we shouldn't be better at announcing and then > > following through on the deprecation of old interfaces. > > We announce things have changed every year, and people have five years > from that point, during which we'll continue to support them and fix > bugs and deal with security issues, to make whatever changes they need > to for the new interface. > > The argument seems to be that people want new features but they don't > want to have to do any work to get those new features. I mean, duh? We can't make that happen all the time, but I don't understand why it's surprising to have that as *one* goal that's in conflict with other goals? Your analysis also neglects that a lot of software will have to work across multiple supported versions of postgres (at the very least in prep for the migration, but also often longer) - by having a few versions were both interfaces work, that can be made *MUCH* less painful. > When is something too big of a change to make in a given major version > and we have to, instead, provide backwards compatibility for it? What > is that policy? How many releases do we have to support it for? How do > we communicate that to our users, so that they know what they can depend > on being there across major releases and what they can't? I literally said that we should have more policy around this. I'm going to stop here, discussing with you in this thread seems unproductive. Greetings, Andres Freund
pgsql-hackers by date: