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

Justin Clift <justin@postgresql.org> 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 other solution (my wording).

Relevant part of that thread there for reference:

/messages/by-id/CANP8+jLtk1NtaJyXc=hAqX=0k+ku4zfavgVBKfs+_sOr9hepNQ@mail.gmail.com

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
et al

This still is better placed on -hackers though, so lets have the
conversation here to figure out if a "backwards compatibility breaking"
release really is needed or not.

Hopefully we can get it all done without giving users a reason to consider
switching. ;)

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.

On Mon, Apr 11, 2016 at 3:23 PM, Robbie Harwood <rharwood@redhat.com> 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 would be a good idea. Occasionally
good things come from artificially limiting how users can use the
system, but mostly that just annoys people.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 12 April 2016 at 00:39, Justin Clift <justin@postgresql.org> 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 that
might have no other solution (my wording).

Relevant part of that thread there for reference:

/messages/by-id/CANP8+jLtk1NtaJyXc=hAqX=0k+ku4zfavgVBKfs+_sOr9hepNQ@mail.gmail.com

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
et al

+

* v4 protocol (feature negotiation, lazy blob fetching, etc)
* retire pg_hba.conf and use SQL access management

?

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

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
et al

+ CMake build I think.

Now I can build:
* postgres
* bin/* programs
* pl/* languages
* contrib/* (with cmake PGXS analogue)

Can run regression and isolation tests for postgres/pl* and all contrib
modules.

There is still a lot of work but I hope everything will turn out. Also it
would be good to get help.

Thanks.

PS https://github.com/stalkerg/postgres_cmake

--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 12 Apr 2016, at 14:12, Yury Zhuravlev <u.zhuravlev@postgrespro.ru> 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
* Retire template0, template1
* Optimise FSM
* Add heap metapage
* Alter tuple headers
et al

+ CMake build I think.

Now I can build:
* postgres
* bin/* programs
* pl/* languages
* contrib/* (with cmake PGXS analogue)

Can run regression and isolation tests for postgres/pl* and all contrib modules.
There is still a lot of work but I hope everything will turn out. Also it would be good to get help.

Thanks.

PS https://github.com/stalkerg/postgres_cmake

If/when PostgreSQL can be built and tested with CMake... why would the
resulting code + database files + network protocol (etc) not be compatible
with previous versions? :)

+ Justin

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, Apr 11, 2016 at 11:39 AM, Justin Clift <justin@postgresql.org> 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 that
might have no other solution (my wording).

Relevant part of that thread there for reference:

/messages/by-id/CANP8+jLtk1NtaJyXc=hAqX=0k+ku4zfavgVBKfs+_sOr9hepNQ@mail.gmail.com

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
et al

This still is better placed on -hackers though, so lets have the
conversation here to figure out if a "backwards compatibility breaking"
release really is needed or not.

A couple of points here:
*) I don't think having a version number that starts with 10 instead
of 9 magically fixes backwards compatibility problems and I think
that's a dangerous precedent to set unless we're willing to fork
development and support version 9 indefinitely including major release
versions.

*) Compatibility issues at the SQL level have to be taken much more
seriously than other things (like internal layouts or .conf issues).

*) We need to do an honest cost benefit analysis before breaking
things. Code refactors placed on your users puts an enormous cost
that is often underestimated. I have some fairly specific examples of
the costs related to the text cast removal for example. It's not a
pretty picture.

merlin

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 12 Apr 2016, at 17:23, Merlin Moncure <mmoncure@gmail.com> wrote:

On Mon, Apr 11, 2016 at 11:39 AM, Justin Clift <justin@postgresql.org> 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 that
might have no other solution (my wording).

Relevant part of that thread there for reference:

/messages/by-id/CANP8+jLtk1NtaJyXc=hAqX=0k+ku4zfavgVBKfs+_sOr9hepNQ@mail.gmail.com

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
et al

This still is better placed on -hackers though, so lets have the
conversation here to figure out if a "backwards compatibility breaking"
release really is needed or not.

A couple of points here:
*) I don't think having a version number that starts with 10 instead
of 9 magically fixes backwards compatibility problems and I think
that's a dangerous precedent to set unless we're willing to fork
development and support version 9 indefinitely including major release
versions.

*) Compatibility issues at the SQL level have to be taken much more
seriously than other things (like internal layouts or .conf issues).

*) We need to do an honest cost benefit analysis before breaking
things. Code refactors placed on your users puts an enormous cost
that is often underestimated. I have some fairly specific examples of
the costs related to the text cast removal for example. It's not a
pretty picture.

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 discuss the
initial points. :(

+ Justin

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Apr 12, 2016 at 12:32 PM, Justin Clift <justin@postgresql.org> 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 discuss the
initial points. :(

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 absolutely impossible to do without major
compatibility breaks, we shouldn't do them at all.

2. Small backward compatibility breaks are OK, but don't require doing
anything special to the version number.

3. There's no value in aggregating many small backward compatibility
breaks into a single release. That increases pain for users, rather
than decreasing it, and slows down development, too, because you have
to wait for the special magic release where it's OK to hose users. We
typically have a few small backward compatibility breaks in each
release, and that's working fine, so I see little reason to change it.

4. To the extent that I can guess what the things on Simon's list
means from what he wrote, and that's a little difficult because his
descriptions were very short, I think that everything on that list is
either (a) a bad idea or (b) something that we can do without any
compatibility break at all.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 require doing
anything special to the version number.

+1

3. There's no value in aggregating many small backward compatibility
breaks into a single release. That increases pain for users, rather
than decreasing it, and slows down development, too, because you have
to wait for the special magic release where it's OK to hose users. We
typically have a few small backward compatibility breaks in each
release, and that's working fine, so I see little reason to change it.

+1

4. To the extent that I can guess what the things on Simon's list
means from what he wrote, and that's a little difficult because his
descriptions were very short, I think that everything on that list is
either (a) a bad idea or (b) something that we can do without any
compatibility break at all.

+1

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 replication/clustering or sharding.

4. Perfect partitioning (i.e. transparent to the user, supports keys &
joins, supports expressions on partition key, etc.)

5. Transparent upgrade-in-place (i.e. allowing 10.2 to use 10.1's tables
without pg_upgrade or other modification).

6. Fully pluggable parser/executor with a good API

That's pretty much it. I can't imagine anything else which would
justify imposing a huge upgrade barrier on users. And, I'll point out,
that in the above list:

* nobody is currently working on anything in core except #4.

* 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 on anything which will and
justifies it.

--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 replication/clustering or sharding.

4. Perfect partitioning (i.e. transparent to the user, supports keys &
joins, supports expressions on partition key, etc.)

5. Transparent upgrade-in-place (i.e. allowing 10.2 to use 10.1's tables
without pg_upgrade or other modification).

6. Fully pluggable parser/executor with a good API

That's pretty much it. I can't imagine anything else which would
justify imposing a huge upgrade barrier on users. And, I'll point out,
that in the above list:

* nobody is currently working on anything in core except #4.

* we don't *know* that any of the above items will require a backwards
compatibility break.

none but 2) seem likely to require a substantial compatibility break.

Greetings,

Andres Freund

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Apr 12, 2016 at 2:27 PM, Andres Freund <andres@anarazel.de> 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, to me, seems like the only sensible approach from a
development perspective. If you decide to rip out the entire heapam
and replace it with something new in one fell swoop, you might as well
bother not writing the patch. It's got the same chance of being
accepted either way.

I really think the time has come that we need an API for the heap the
same way we already have for indexes. Regardless of exactly how we
choose to implement that, I think a large part of it will end up
looking similar to what we already have for FDWs. We can either use
the FDW API itself and add whatever additional methods we need for
this purpose, or copy it to a new file, rename everything, and have
two slightly different versions. AFAICS, the things we need that the
FDW API doesn't currently provide are:

1. The ability to have a local relfilenode associated with the data.
Or, ideally, several, so you have a separate set of files for each
index.

2. The ability to WAL-log changes to that relfilenode (or those
relfilenodes) in a sensible way. Not sure whether the new generic
XLOG stuff is good enough for a first go-round here or if more is
needed.

3. The ability to intercept DDL commands directed at the table and
handle them in some arbitrary way. This is really optional; people
could always provide a function-based API until we devise something
better.

4. The ability to build standard PostgreSQL indexes on top of the
data, if the underlying format still has a useful notion of CTIDs.
That is, if the underlying format is basically like our heap format,
but optimized in some way - e.g. append-only table that can't update
or delete with a smaller tuple header and page compression - then it
can reuse our indexing. If it does something else, like an
index-organized table where rows can move around to different physical
positions, then it has to provide its own indexing facilities.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Apr 12, 2016 at 9:25 PM, Josh berkus <josh@agliodbs.com> 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 them at all.

+1

2. Small backward compatibility breaks are OK, but don't require doing
anything special to the version number.

+1

3. There's no value in aggregating many small backward compatibility
breaks into a single release. That increases pain for users, rather
than decreasing it, and slows down development, too, because you have
to wait for the special magic release where it's OK to hose users. We
typically have a few small backward compatibility breaks in each
release, and that's working fine, so I see little reason to change it.

+1

4. To the extent that I can guess what the things on Simon's list
means from what he wrote, and that's a little difficult because his
descriptions were very short, I think that everything on that list is
either (a) a bad idea or (b) something that we can do without any
compatibility break at all.

+1

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 replication/clustering or sharding.

4. Perfect partitioning (i.e. transparent to the user, supports keys &
joins, supports expressions on partition key, etc.)

5. Transparent upgrade-in-place (i.e. allowing 10.2 to use 10.1's tables
without pg_upgrade or other modification).

6. Fully pluggable parser/executor with a good API

That's pretty much it. I can't imagine anything else which would
justify imposing a huge upgrade barrier on users. And, I'll point out,
that in the above list:

* nobody is currently working on anything in core except #4.

We are working on #3 (HA multimaster).

* 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 on anything which will and
justifies it.

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
developers, who do all major contributions. All these companies has their
roadmaps, but not the community. I think 9.6 release is inflection point,
where we should combine our roadmaps and release the one for the community.
Than we could plan releases and our customers will see what to expect. I
can't say for other companies, but we have big demand for many features
from russian customers and we have to compete with other databases. Having
community roadmap will helps us to work with customers and plan our
resources.

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 roadmap doesn't magically make code happen.

There are several postgres-centric companies, which have
most of developers, who do all major contributions. All these companies
has their roadmaps, but not the community. I think 9.6 release is
inflection point, where we should combine our roadmaps and release the
one for the community. Than we could plan releases and our customers
will see what to expect. I can't say for other companies, but we have
big demand for many features from russian customers and we have to
compete with other databases. Having community roadmap will helps us to
work with customers and plan our resources.

It would be good to have a place for the companies who do PostgreSQL
feature work would publish their current efforts and timelines, so we at
least have a go-to place for "here's what someone's working on". But
only if that information is going to be *updated*, something we're very
bad at. And IMHO, a "roadmap" which is less that 50% accurate is a
waste of time.

There's an easy way for you to kick this off though: have PostgresPro
publish a wiki page or Trello board or github repo or whatever with your
roadmap and invite other full-time PostgreSQL contributors to add their
pieces.

--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Apr 12, 2016 at 1:07 PM, Oleg Bartunov <obartunov@gmail.com> 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 on anything which will and
justifies it.

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 developers, who do all major contributions. All these companies has
their roadmaps, but not the community. I think 9.6 release is inflection
point, where we should combine our roadmaps and release the one for the
community. Than we could plan releases and our customers will see what to
expect. I can't say for other companies, but we have big demand for many
features from russian customers and we have to compete with other
databases. Having community roadmap will helps us to work with customers
and plan our resources.

​I've already posited just having our release numbers operate on 5-year
increments 10.0 - 10.4; 11.0 - 11.4, etc on advocacy but was met with
silence. In any case this comment is just furtherance of the tail wagging
the dog. I see no fundamental reason to have to plan something momentous
enough, and actively schedule work to meet the plan, in order to justify a
10.0 release.

There is a bunch of hand-waving here, and its an environment I'm not
immersed in, but it seems that creating a roadmap today is tantamount to
waterfall design - useful in moderation but has largely shown to be
undesirable at scale. Aside from the 1-year release cycle the project is
reasonably agile and well receptive to outside observation, questions, and
contributions. If you have spare resources you need to keep busy just ask
how you can help. To be honest the community would likely rather have
those people help review and test everything that is presently in-progress
- future goals on a roadmap are not nearly as important. And if you have a
demand you think needs to be fulfill put the information out there and get
input.

If you are claiming the balance between community and profit is skewed
undesirably you will need to put forth a more concrete argument in order to
convince me. For me, having plans reside in the profit-motive parts of the
community and having core simply operate openly seems to strike a solid
balance.

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 job on the
communication and planning front. The biggest resource need is quality
control. I dislike the fact that we are currently in a situation where the
first 3 point releases each year are considered "live betas" based
especially on both 9.3 and 9.5 post-release significant bug counts.

David J.

On Tue, Apr 12, 2016 at 4:07 PM, Oleg Bartunov <obartunov@gmail.com> 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
developers, who do all major contributions. All these companies has their
roadmaps, but not the community. I think 9.6 release is inflection point,
where we should combine our roadmaps and release the one for the community.
Than we could plan releases and our customers will see what to expect. I
can't say for other companies, but we have big demand for many features from
russian customers and we have to compete with other databases. Having
community roadmap will helps us to work with customers and plan our
resources.

I don't think it's realistic to plan what is going to go into a
certain release. We don't know whether we want the patch until we see
the patch and review it and decide whether it's good. We can't make
the decision, first, that the patch will be in the release, and then,
second, write the patch. What we *can* do, as Josh says, is discuss
our plans.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Apr 12, 2016 at 4:32 PM, David G. Johnston
<david.g.johnston@gmail.com> 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 job on the
communication and planning front. The biggest resource need is quality
control. I dislike the fact that we are currently in a situation where the
first 3 point releases each year are considered "live betas" based
especially on both 9.3 and 9.5 post-release significant bug counts.

/me blinks.

I find it shocking that you would compare 9.5 to 9.3 that way. Yeah,
we've had a few bugs in 9.5: in particular, it was disappointing to
have to disable abbreviated keys. But I'm not sure that I really
believe that affected massive numbers of users in a really negative
way - many locales were just fine, and not every locale that had a
problem with some string data necessarily had a problem with the
strings people were actually storing. But we haven't eaten anybody's
data, at least not beyond what can be fixed by a REINDEX, unless I
missed something here.

The fact is that this is a fairly hard problem to solve. Some bugs
are not going to get found before people try the software, and we
can't make them try it while it's in beta. We can only do our best to
do good code review, but inevitably we will miss some things.

As for your proposal that we blindly consider $(N+1).0 to follow $N.4,
I'm not particularly enthralled with that. I think it's a good idea
to look for a release that's got some particularly nifty feature(s)
and use that as the time to move the first digit. And, sure, plan to
have that happen every 4-6 years or so, but adjust based on what
actually gets into which releases.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Apr 12, 2016 at 2:04 PM, Robert Haas <robertmhaas@gmail.com> wrote:

On Tue, Apr 12, 2016 at 4:32 PM, David G. Johnston
<david.g.johnston@gmail.com> 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 job on the
communication and planning front. The biggest resource need is quality
control. I dislike the fact that we are currently in a situation where

the

first 3 point releases each year are considered "live betas" based
especially on both 9.3 and 9.5 post-release significant bug counts.

/me blinks.

I find it shocking that you would compare 9.5 to 9.3 that way. Yeah,
we've had a few bugs in 9.5: in particular, it was disappointing to
have to disable abbreviated keys. But I'm not sure that I really
believe that affected massive numbers of users in a really negative
way - many locales were just fine, and not every locale that had a
problem with some string data necessarily had a problem with the
strings people were actually storing. But we haven't eaten anybody's
data, at least not beyond what can be fixed by a REINDEX, unless I
missed something here.

​I probably over-implied my feelings regarding 9.5 since, yes, abbreviated
keys was largely out of realm of reasonable expectation.
​

​I think I am colored by my involvement in attempting to help research this
one:​

9.5.1 ​"Fix an oversight that caused hash joins to miss joining to some
tuples of the inner relation in rare cases (Tomas Vondra, Tom Lane)"

This one struck me as well for some reason...

9.5.1 "Fix overeager pushdown of HAVING clauses when grouping sets are
used."

The two ROW() comparison fixes for 9.5.2

I'm not exactly someone looking to poke a stick in PostgreSQL's side so
regardless of degree of "validity" of my feelings that fact that I have
them is likely informative. Or I'm just in a particularly overly-sensitive
mood right now - I wouldn't fully discount the possibility.

The fact is that this is a fairly hard problem to solve. Some bugs
are not going to get found before people try the software, and we
can't make them try it while it's in beta. We can only do our best to
do good code review, but inevitably we will miss some things.

​Agreed, and to the point of using corporate resources for improvement of
existing work as opposed to roadmap stuff.​

As for your proposal that we blindly consider $(N+1).0 to follow $N.4,
I'm not particularly enthralled with that. I think it's a good idea
to look for a release that's got some particularly nifty feature(s)
and use that as the time to move the first digit. And, sure, plan to
have that happen every 4-6 years or so, but adjust based on what
actually gets into which releases.

​The main point on that post was we emphasize not only the new stuff in the
just released version but that we re-celebrate everything that has been
accomplished in the previous​ 4 releases as well. If the first-digit is
getting such significant attention we might as well play to that fact and
try and remind people who've missed out on prior releases that we are
continually innovating. That, and the fact that the last N.0 release that
was so highly touted just went out of support.

Otherwise I don't see why we don't just start increment the first-digit
yearly. Sure, every so often we think we've done enough to warrant an
increase there but the philosophy as a community doesn't actually match our
particular choice - we don't, in advance, place any special importance on
the first-digit releases, as evidenced by this discussion.

David J.

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 absolutely impossible to do without major
compatibility breaks, we shouldn't do them at all.

2. Small backward compatibility breaks are OK, but don't require doing
anything special to the version number.

3. There's no value in aggregating many small backward compatibility
breaks into a single release. That increases pain for users, rather
than decreasing it, and slows down development, too, because you have
to wait for the special magic release where it's OK to hose users. We
typically have a few small backward compatibility breaks in each
release, and that's working fine, so I see little reason to change it.

Well, this is true for SQL-level and admin-level changes, but it does
make sense to group pg_upgrade breaks into a single release. I think
the plan is for us to have logical replication usable before we make
such a change.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+                     Ancient Roman grave inscription +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 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 anytime soon.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+                     Ancient Roman grave inscription +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers