Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Tue, Jun 21, 2016 at 12:12:34PM -0400, Robert Haas wrote: > >> > What is confusing you? > >> > >> I don't think I'm confused. Sure, you can do that, but the effects of > >> any writes performed on the new cluster will not be there when you > >> revert back to the old cluster. So you will have

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Tue, Jun 21, 2016 at 08:56:09PM +0800, Craig Ringer wrote: > Also, if you run *with* --link, IIRC there's no guarantee that the old version > will be happy to see any new infomask bits etc introduced by the new Pg. I Well, we only write system tables in pg_upgrade in the new cluster, and those

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Tue, Jun 21, 2016 at 11:34 AM, Bruce Momjian wrote: > On Tue, Jun 21, 2016 at 08:19:55AM -0400, Robert Haas wrote: >> On Mon, Jun 20, 2016 at 10:08 PM, Bruce Momjian wrote: >> >> No, not really. Once you let write transactions into the new cluster, >> >>

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Tue, Jun 21, 2016 at 08:19:55AM -0400, Robert Haas wrote: > On Mon, Jun 20, 2016 at 10:08 PM, Bruce Momjian wrote: > >> No, not really. Once you let write transactions into the new cluster, > >> there's no way to get back to the old server version no matter which > >> option

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 21 June 2016 at 20:19, Robert Haas wrote: > On Mon, Jun 20, 2016 at 10:08 PM, Bruce Momjian wrote: > > On Fri, May 20, 2016 at 07:40:53PM -0400, Robert Haas wrote: > >> On Mon, May 16, 2016 at 3:36 AM, Bruce Momjian > wrote: > >> >

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Mon, Jun 20, 2016 at 10:08 PM, Bruce Momjian wrote: > On Fri, May 20, 2016 at 07:40:53PM -0400, Robert Haas wrote: >> On Mon, May 16, 2016 at 3:36 AM, Bruce Momjian wrote: >> > On Sun, May 15, 2016 at 03:23:52PM -0500, Jim Nasby wrote: >> >> 2) There's no

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Tue, May 24, 2016 at 09:23:27AM -0500, Jim Nasby wrote: > On 5/16/16 2:36 AM, Bruce Momjian wrote: > >Right. I am thinking of writing some docs about how to avoid downtime > >for upgrades of various types. > > If there's some magic sauce to shrink pg_upgrade downtime to near 0 I think > folks

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Fri, May 20, 2016 at 07:40:53PM -0400, Robert Haas wrote: > On Mon, May 16, 2016 at 3:36 AM, Bruce Momjian wrote: > > On Sun, May 15, 2016 at 03:23:52PM -0500, Jim Nasby wrote: > >> 2) There's no ability at all to revert, other than restore a backup. That > >> means if you

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 5/16/16 2:36 AM, Bruce Momjian wrote: Right. I am thinking of writing some docs about how to avoid downtime for upgrades of various types. If there's some magic sauce to shrink pg_upgrade downtime to near 0 I think folks would be very interested in that. Outside of that scenario, I

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Mon, May 16, 2016 at 3:36 AM, Bruce Momjian wrote: > On Sun, May 15, 2016 at 03:23:52PM -0500, Jim Nasby wrote: >> 2) There's no ability at all to revert, other than restore a backup. That >> means if you pull the trigger and discover some major performance problem, >> you

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Sun, May 15, 2016 at 03:23:52PM -0500, Jim Nasby wrote: > 2) There's no ability at all to revert, other than restore a backup. That > means if you pull the trigger and discover some major performance problem, > you have no choice but to deal with it (you can't switch back to the old > version

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 4/29/16 10:37 AM, Joshua D. Drake wrote: 5. Transparent upgrade-in-place (i.e. allowing 10.2 to use 10.1's tables without pg_upgrade or other modification). Technically, this is exactly what pg_upgrade does. I think what you really mean is for the backend binary to be able to read the

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Fri, May 13, 2016 at 12:12 PM, Joshua D. Drake wrote: > On 05/13/2016 07:42 AM, Robert Haas wrote: > >> On Sat, Apr 30, 2016 at 8:46 PM, Joshua Drake >> wrote: >> >>> Oh, absolutely. I was just pointing out how a lot of companies are >>>

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Fri, May 13, 2016 at 6:05 PM, Joshua D. Drake wrote: > On 05/13/2016 01:42 PM, Josh berkus wrote: > >> On 05/13/2016 01:04 PM, Joshua D. Drake wrote: >> >>> On 05/13/2016 12:03 PM, Josh berkus wrote: >>> On 05/13/2016 11:48 AM, Robert Haas wrote: > On

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 05/13/2016 01:42 PM, Josh berkus wrote: On 05/13/2016 01:04 PM, Joshua D. Drake wrote: On 05/13/2016 12:03 PM, Josh berkus wrote: On 05/13/2016 11:48 AM, Robert Haas wrote: On Fri, May 13, 2016 at 12:12 PM, Joshua D. Drake wrote: Anyway, all of this is a moot

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 13 May 2016, at 21:42, Josh berkus wrote: > On 05/13/2016 01:04 PM, Joshua D. Drake wrote: >> On 05/13/2016 12:03 PM, Josh berkus wrote: >>> On 05/13/2016 11:48 AM, Robert Haas wrote: On Fri, May 13, 2016 at 12:12 PM, Joshua D. Drake wrote:

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 05/13/2016 01:04 PM, Joshua D. Drake wrote: > On 05/13/2016 12:03 PM, Josh berkus wrote: >> On 05/13/2016 11:48 AM, Robert Haas wrote: >>> On Fri, May 13, 2016 at 12:12 PM, Joshua D. Drake >>> wrote: > >> Anyway, all of this is a moot point, because nobody has the

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Fri, May 13, 2016 at 2:05 PM, Robert Haas wrote: > Now, where this gets tricky is when it comes down to whether the > end-product of that effort is something the community wants. We all > need to be careful not to make our corporate priorities into community >

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 05/13/2016 12:03 PM, Josh berkus wrote: On 05/13/2016 11:48 AM, Robert Haas wrote: On Fri, May 13, 2016 at 12:12 PM, Joshua D. Drake wrote: Anyway, all of this is a moot point, because nobody has the power to tell the various companies what to do. We're just

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 05/13/2016 12:05 PM, Robert Haas wrote: On Fri, May 13, 2016 at 12:35 PM, Joshua D. Drake wrote: Hey, if I am wrong that's awesome. The impression I have is the general workflow is this: The difference being one of coopetition versions competition for the

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Fri, May 13, 2016 at 12:35 PM, Joshua D. Drake wrote: > Hey, if I am wrong that's awesome. The impression I have is the general > workflow is this: > > * Company(1) discusses feature with community > * Company(1) works on patch/feature for a period of

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 05/13/2016 11:48 AM, Robert Haas wrote: > On Fri, May 13, 2016 at 12:12 PM, Joshua D. Drake > wrote: >> Singular point contribution is not the point of my argument. My point is >> that if three people from EDB and three people from Citus got together and >> worked on a

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Fri, May 13, 2016 at 12:12 PM, Joshua D. Drake wrote: > Singular point contribution is not the point of my argument. My point is > that if three people from EDB and three people from Citus got together and > worked on a project in full collaboration it would be more

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 05/13/2016 09:40 AM, Bruce Momjian wrote: On Fri, May 13, 2016 at 09:35:40AM -0700, Joshua Drake wrote: On 05/13/2016 09:28 AM, Bruce Momjian wrote: On Fri, May 13, 2016 at 09:12:23AM -0700, Joshua Drake wrote: There was no disrespect intended. I was trying to push forth an idea that

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Fri, May 13, 2016 at 09:35:40AM -0700, Joshua Drake wrote: > On 05/13/2016 09:28 AM, Bruce Momjian wrote: > >On Fri, May 13, 2016 at 09:12:23AM -0700, Joshua Drake wrote: > >>There was no disrespect intended. I was trying to push forth an idea that > >>multi-company team collaboration is better

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 05/13/2016 09:28 AM, Bruce Momjian wrote: On Fri, May 13, 2016 at 09:12:23AM -0700, Joshua Drake wrote: There was no disrespect intended. I was trying to push forth an idea that multi-company team collaboration is better for the community than single company team collaboration. I will stand

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Fri, May 13, 2016 at 09:12:23AM -0700, Joshua Drake wrote: > There was no disrespect intended. I was trying to push forth an idea that > multi-company team collaboration is better for the community than single > company team collaboration. I will stand by that assertion. Uh, we are already

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 05/13/2016 07:42 AM, Robert Haas wrote: On Sat, Apr 30, 2016 at 8:46 PM, Joshua Drake wrote: Oh, absolutely. I was just pointing out how a lot of companies are hoarding talent internally for no productive purpose. Wow, really? I disagree both with the idea that

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Sat, Apr 30, 2016 at 8:46 PM, Joshua Drake wrote: > Oh, absolutely. I was just pointing out how a lot of companies are hoarding > talent internally for no productive purpose. Wow, really? I disagree both with the idea that this is happening and with your

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Apr 30, 2016 2:07 PM, Oleg Bartunov wrote: > > > > On Fri, Apr 29, 2016 at 7:40 PM, Joshua D. Drake wrote: >> > I'd not limited by the companies, individual developes are highly welcome. I'm afraid there are some. >   Oh, absolutely. I was just

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Fri, Apr 29, 2016 at 7:40 PM, Joshua D. Drake wrote: > On 04/29/2016 08:44 AM, Bruce Momjian wrote: > >> On Tue, Apr 12, 2016 at 11:07:04PM +0300, Oleg Bartunov wrote: >> >>> Our roadmap http://www.postgresql.org/developer/roadmap/ is the >>> problem. We >>> don't have

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 - > 10.0

I cut many of emails from CC - AFAIR most of you are subscribed to pg-hackers. Dnia 2016-04-30 19:29 Joshua D. Drake napisał(a): >On 04/29/2016 11:50 AM, Joshua D. Drake wrote: >> On 04/29/2016 11:36 AM, Simon Riggs wrote: >> >>> Egos. >>> >>> Consider PgLogical, who is working on this

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 04/29/2016 11:50 AM, Joshua D. Drake wrote: On 04/29/2016 11:36 AM, Simon Riggs wrote: Egos. Consider PgLogical, who is working on this outside of 2Q? Thank you for volunteering to assist. What would you like to work on? You are very welcome. I have been testing as you know. I

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 04/29/2016 11:36 AM, Simon Riggs wrote: Egos. Consider PgLogical, who is working on this outside of 2Q? Thank you for volunteering to assist. What would you like to work on? You are very welcome. I have been testing as you know. I would be happy to continue that and also was

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 29 April 2016 at 18:40, Joshua D. Drake wrote: > On 04/29/2016 08:44 AM, Bruce Momjian wrote: > >> On Tue, Apr 12, 2016 at 11:07:04PM +0300, Oleg Bartunov wrote: >> >>> Our roadmap http://www.postgresql.org/developer/roadmap/ is the >>> problem. We >>> don't have clear

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 04/29/2016 09:40 AM, Joshua D. Drake wrote: On 04/29/2016 08:44 AM, Bruce Momjian wrote: Consider PgLogical, who is working on this outside of 2Q? Where is the git repo for it? Where is the bug tracker? Where is the mailing list? Oh, its -hackers, except that it isn't, is it? FTR: I am

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 04/29/2016 08:44 AM, Bruce Momjian wrote: On Tue, Apr 12, 2016 at 11:07:04PM +0300, Oleg Bartunov wrote: Our roadmap http://www.postgresql.org/developer/roadmap/ is the problem. We don't have clear roadmap and that's why we cannot plan future feature full release. There are several

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Fri, Apr 29, 2016 at 11:02 AM, Simon Riggs wrote: > On 12 April 2016 at 20:25, Josh berkus wrote: > >> >> Here's the features I can imagine being worth major backwards >> compatibility breaks: >> >> 1. Fully pluggable storage with a clean API. >> >>

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 12 April 2016 at 20:25, Josh berkus wrote: > Here's the features I can imagine being worth major backwards > compatibility breaks: > > 1. Fully pluggable storage with a clean API. > > 2. Total elimination of VACUUM or XID freezing > > 3. Fully transparent-to-the user MM

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Tue, Apr 12, 2016 at 11:07:04PM +0300, Oleg Bartunov wrote: > Our roadmap http://www.postgresql.org/developer/roadmap/ is the problem. We > don't have clear roadmap and that's why we cannot plan future feature full > release. There are several postgres-centric companies, which have most of >

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Fri, Apr 29, 2016 at 08:37:57AM -0700, Joshua Drake wrote: > >Technically, this is exactly what pg_upgrade does. I think what you > >really mean is for the backend binary to be able to read the system > >tables and WAL files of the old clusters --- something I can't see us > >implementing

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 04/29/2016 08:32 AM, Bruce Momjian wrote: On Tue, Apr 12, 2016 at 11:25:21AM -0700, Josh Berkus wrote: Here's the features I can imagine being worth major backwards compatibility breaks: ... 5. Transparent upgrade-in-place (i.e. allowing 10.2 to use 10.1's tables without pg_upgrade or

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Tue, Apr 12, 2016 at 11:25:21AM -0700, Josh Berkus wrote: > Here's the features I can imagine being worth major backwards > compatibility breaks: ... > 5. Transparent upgrade-in-place (i.e. allowing 10.2 to use 10.1's tables > without pg_upgrade or other modification). Technically, this is

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Tue, Apr 12, 2016 at 01:43:41PM -0400, Robert Haas wrote: > I'm going to throw down the gauntlet (again) and say more or less what > I previously said on the pgsql-advocacy thread. I think that: > > 1. Large backward compatibility breaks are bad. Therefore, if any of > these things are

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Tue, Apr 12, 2016 at 2:04 PM, Robert Haas wrote: > On Tue, Apr 12, 2016 at 4:32 PM, David G. Johnston > wrote: > > I give a solid +10 to Robert's opinions on the matter and aside from > > figuring out if and how to fit first-number

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Tue, Apr 12, 2016 at 4:32 PM, David G. Johnston wrote: > I give a solid +10 to Robert's opinions on the matter and aside from > figuring out if and how to fit first-number versioning dynamics into our > release policies I think the community is doing a sufficient

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Tue, Apr 12, 2016 at 4:07 PM, Oleg Bartunov wrote: > Our roadmap http://www.postgresql.org/developer/roadmap/ is the problem. We > don't have clear roadmap and that's why we cannot plan future feature full > release. There are several postgres-centric companies, which have

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Tue, Apr 12, 2016 at 1:07 PM, Oleg Bartunov wrote: > > >> * we don't *know* that any of the above items will require a backwards >> compatibility break. >> >> People keep talking about "we might want to break compatibility/file >> format one day". But nobody is working

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 04/12/2016 01:07 PM, Oleg Bartunov wrote: > > Our roadmap http://www.postgresql.org/developer/roadmap/ is the problem. > We don't have clear roadmap and that's why we cannot plan future feature > full release. As someone who's worked at multiple proprietary software companies, having a

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Tue, Apr 12, 2016 at 9:25 PM, Josh berkus wrote: > On 04/12/2016 10:43 AM, Robert Haas wrote: > > 1. Large backward compatibility breaks are bad. Therefore, if any of > > these things are absolutely impossible to do without major > > compatibility breaks, we shouldn't do

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Tue, Apr 12, 2016 at 2:27 PM, Andres Freund wrote: > none but 2) seem likely to require a substantial compatibility break. And even that doesn't require one, if you keep the only system around and make the new system optional via some sort of pluggable storage API. Which,

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 2016-04-12 11:25:21 -0700, Josh berkus wrote: > Here's the features I can imagine being worth major backwards > compatibility breaks: > > 1. Fully pluggable storage with a clean API. > > 2. Total elimination of VACUUM or XID freezing > > 3. Fully transparent-to-the user MM

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 04/12/2016 10:43 AM, Robert Haas wrote: > 1. Large backward compatibility breaks are bad. Therefore, if any of > these things are absolutely impossible to do without major > compatibility breaks, we shouldn't do them at all. +1 > 2. Small backward compatibility breaks are OK, but don't

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Tue, Apr 12, 2016 at 12:32 PM, Justin Clift wrote: > Yeah. Moving the discussion here was more to determine which items > really would need a backwards compatible break. eg no other approach can > be found. > > Seems I started it off badly, as no-one's yet jumped in to

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 12 Apr 2016, at 17:23, Merlin Moncure wrote: > On Mon, Apr 11, 2016 at 11:39 AM, Justin Clift wrote: >> Moving over a conversation from the pgsql-advocacy mailing list. In it >> Simon (CC'd) raised the issue of potentially creating a >>

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Mon, Apr 11, 2016 at 11:39 AM, Justin Clift wrote: > Moving over a conversation from the pgsql-advocacy mailing list. In it > Simon (CC'd) raised the issue of potentially creating a > backwards-compatibility > breaking release at some point in the future, to deal with

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 12 Apr 2016, at 14:12, Yury Zhuravlev wrote: > Justin Clift wrote: >> Simon included a short starter list of potentials which might be in >> that category: >> >> * SQL compliant identifiers >> * Remove RULEs >> * Change recovery.conf >> * Change block headers

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

Justin Clift wrote: Simon included a short starter list of potentials which might be in that category: * SQL compliant identifiers * Remove RULEs * Change recovery.conf * Change block headers * Retire template0, template1 * Optimise FSM * Add heap metapage * Alter tuple headers

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 12 April 2016 at 00:39, Justin Clift wrote: > Moving over a conversation from the pgsql-advocacy mailing list. In it > Simon (CC'd) raised the issue of potentially creating a > backwards-compatibility > breaking release at some point in the future, to deal with things

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Mon, Apr 11, 2016 at 3:23 PM, Robbie Harwood wrote: > I'm sure this won't be a popular suggestion, but in the interest of > advocating for more cryptography: if we land GSSAPI auth+encryption, I'd > like the auth-only codepath to go away. I can't think of a reason that

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

Justin Clift writes: > Moving over a conversation from the pgsql-advocacy mailing list. In it > Simon (CC'd) raised the issue of potentially creating a > backwards-compatibility > breaking release at some point in the future, to deal with things that > might have no

[HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

Moving over a conversation from the pgsql-advocacy mailing list. In it Simon (CC'd) raised the issue of potentially creating a backwards-compatibility breaking release at some point in the future, to deal with things that might have no other solution (my wording). Relevant part of that thread