Reports on obsolete Postgres versions

On Mon, Mar 11, 2024 at 04:37:49PM -0400, Bruce Momjian wrote:

https://www.postgresql.org/support/versioning/

This web page should correct the idea that "upgrades are more risky than
staying with existing versions". Is there more we can do? Should we
have a more consistent response for such reporters?

I've read that the use of the term "minor release" can be confusing. While
the versioning page clearly describes what is eligible for a minor release,
not everyone reads it, so I suspect that many folks think there are new
features, etc. in minor releases. I think a "minor release" of Postgres is
more similar to what other projects would call a "patch version."

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

On Mon, Mar 11, 2024 at 04:12:04PM -0500, Nathan Bossart wrote:

On Mon, Mar 11, 2024 at 04:37:49PM -0400, Bruce Momjian wrote:

https://www.postgresql.org/support/versioning/

This web page should correct the idea that "upgrades are more risky than
staying with existing versions". Is there more we can do? Should we
have a more consistent response for such reporters?

I've read that the use of the term "minor release" can be confusing. While
the versioning page clearly describes what is eligible for a minor release,
not everyone reads it, so I suspect that many folks think there are new
features, etc. in minor releases. I think a "minor release" of Postgres is
more similar to what other projects would call a "patch version."

Well, we do say:

While upgrading will always contain some level of risk, PostgreSQL
minor releases fix only frequently-encountered bugs, security issues,
and data corruption problems to reduce the risk associated with
upgrading. For minor releases, the community considers not upgrading to
be riskier than upgrading.

but that is far down the page. Do we need to improve this?

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

On Mon, Mar 11, 2024 at 4:38 PM Bruce Momjian <bruce@momjian.us> wrote:

https://www.postgresql.org/support/versioning/

This web page should correct the idea that "upgrades are more risky than
staying with existing versions". Is there more we can do? Should we have
a more consistent response for such reporters?

It could be helpful to remove this sentence:

"Upgrading to a minor release does not normally require a dump and restore"

While technically true, "not normally" is quite the understatement, as the
true answer is "never" or at least "not in the last few decades". I have a
hard time even imagining a scenario that would require a minor revision to
do a dump and restore - surely, that in itself would warrant a major
release?

It would be a crazy idea to report something in the logs if a major
version is run after a certain date, since we know the date when major
versions will become unsupported.

Could indeed be useful to spit something out at startup. Heck, even minor
versions are fairly regular now. Sure would be nice to be able to point a
client at the database and say "See? Even Postgres itself thinks you should
upgrade from 11.3!!" (totally made up example, not at all related to an
actual production system /sarcasm)

Cheers,
Greg

On Mon, Mar 11, 2024 at 05:17:13PM -0400, Bruce Momjian wrote:

On Mon, Mar 11, 2024 at 04:12:04PM -0500, Nathan Bossart wrote:

I've read that the use of the term "minor release" can be confusing. While
the versioning page clearly describes what is eligible for a minor release,
not everyone reads it, so I suspect that many folks think there are new
features, etc. in minor releases. I think a "minor release" of Postgres is
more similar to what other projects would call a "patch version."

Well, we do say:

While upgrading will always contain some level of risk, PostgreSQL
minor releases fix only frequently-encountered bugs, security issues,
and data corruption problems to reduce the risk associated with
upgrading. For minor releases, the community considers not upgrading to
be riskier than upgrading.

but that is far down the page. Do we need to improve this?

I think making that note more visible would certainly be an improvement.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

On 12 Mar 2024, at 02:37, Nathan Bossart <nathandbossart@gmail.com> wrote:

On Mon, Mar 11, 2024 at 05:17:13PM -0400, Bruce Momjian wrote:

On Mon, Mar 11, 2024 at 04:12:04PM -0500, Nathan Bossart wrote:

I've read that the use of the term "minor release" can be confusing. While
the versioning page clearly describes what is eligible for a minor release,
not everyone reads it, so I suspect that many folks think there are new
features, etc. in minor releases. I think a "minor release" of Postgres is
more similar to what other projects would call a "patch version."

Well, we do say:

While upgrading will always contain some level of risk, PostgreSQL
minor releases fix only frequently-encountered bugs, security issues,
and data corruption problems to reduce the risk associated with
upgrading. For minor releases, the community considers not upgrading to
be riskier than upgrading.

but that is far down the page. Do we need to improve this?

I think making that note more visible would certainly be an improvement.

We have this almost at the top of the page, which IMHO isn't a very good
description about what a minor version is:

Each major version receives bug fixes and, if need be, security fixes
that are released at least once every three months in what we call a
"minor release."

Maybe we can rewrite that sentence to properly document what a minor is (bug
fixes *and* security fixes) with a small blurb about the upgrade risk?

(Adding Jonathan in CC: who is good at website copy).

--
Daniel Gustafsson

Hi,

On Mon, Mar 11, 2024 at 05:17:13PM -0400, Bruce Momjian wrote:

On Mon, Mar 11, 2024 at 04:12:04PM -0500, Nathan Bossart wrote:

On Mon, Mar 11, 2024 at 04:37:49PM -0400, Bruce Momjian wrote:

https://www.postgresql.org/support/versioning/

This web page should correct the idea that "upgrades are more risky than
staying with existing versions". Is there more we can do? Should we
have a more consistent response for such reporters?

I've read that the use of the term "minor release" can be confusing. While
the versioning page clearly describes what is eligible for a minor release,
not everyone reads it, so I suspect that many folks think there are new
features, etc. in minor releases. I think a "minor release" of Postgres is
more similar to what other projects would call a "patch version."

Well, we do say:

While upgrading will always contain some level of risk, PostgreSQL
minor releases fix only frequently-encountered bugs, security issues,
and data corruption problems to reduce the risk associated with
upgrading. For minor releases, the community considers not upgrading to
be riskier than upgrading.

but that is far down the page. Do we need to improve this?

I liked the statement from Laurenz a while ago on his blog
(paraphrased): "Upgrading to the latest patch release does not require
application testing or recertification". I am not sure we want to put
that into the official page (or maybe tone down/qualify it a bit), but I
think a lot of users stay on older minor versions because they dread
their internal testing policies.

The other thing that could maybe be made a bit better is the fantastic
patch release schedule, which however is buried in the "developer
roadmap". I can see how this was useful years ago, but I think this page
should be moved to the end-user part of the website, and maybe (also)
integrated into the support/versioning page?

Michael

but that is far down the page. Do we need to improve this?

I liked the statement from Laurenz a while ago on his blog
(paraphrased): "Upgrading to the latest patch release does not require
application testing or recertification". I am not sure we want to put
that into the official page (or maybe tone down/qualify it a bit), but I
think a lot of users stay on older minor versions because they dread
their internal testing policies.

I think we need a more conservative language since a minor release might fix a
planner bug that someone's app relied on and their plans will be worse after
upgrading. While rare, it can for sure happen so the official wording should
probably avoid such bold claims.

The other thing that could maybe be made a bit better is the fantastic
patch release schedule, which however is buried in the "developer
roadmap". I can see how this was useful years ago, but I think this page
should be moved to the end-user part of the website, and maybe (also)
integrated into the support/versioning page?

Fair point.

--
Daniel Gustafsson

On 3/12/24 3:56 AM, Daniel Gustafsson wrote:

but that is far down the page. Do we need to improve this?

I liked the statement from Laurenz a while ago on his blog
(paraphrased): "Upgrading to the latest patch release does not require
application testing or recertification". I am not sure we want to put
that into the official page (or maybe tone down/qualify it a bit), but I
think a lot of users stay on older minor versions because they dread
their internal testing policies.

I think we need a more conservative language since a minor release might fix a
planner bug that someone's app relied on and their plans will be worse after
upgrading. While rare, it can for sure happen so the official wording should
probably avoid such bold claims.

The other thing that could maybe be made a bit better is the fantastic
patch release schedule, which however is buried in the "developer
roadmap". I can see how this was useful years ago, but I think this page
should be moved to the end-user part of the website, and maybe (also)
integrated into the support/versioning page?

Fair point.

Both of the above points show inconsistency in how PG uses the terms
"minor" and "patch" today.

It's not just roadmaps and release pages where we mix up these terms
either, it's even in user-facing SQL and libpq routines: both
PQserverVersion and current_setting('server_version_num') return the
patch release version in the numeric patch field, rather than the
numeric minor field (which is always 0).

In my view, the best thing would be to move toward consistently using
the word "patch" and moving away from the word "minor" for the
PostgreSQL quarterly maintenance updates.

-Jeremy

--
http://about.me/jeremy_schneider

On Wed, Mar 13, 2024 at 09:21:27AM -0700, Jeremy Schneider wrote:

It's not just roadmaps and release pages where we mix up these terms
either, it's even in user-facing SQL and libpq routines: both
PQserverVersion and current_setting('server_version_num') return the
patch release version in the numeric patch field, rather than the
numeric minor field (which is always 0).

In my view, the best thing would be to move toward consistently using
the word "patch" and moving away from the word "minor" for the
PostgreSQL quarterly maintenance updates.

I think "minor" is a better term since it contrasts with "major". We
don't actually supply patches to upgrade minor versions.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

On Wed, Mar 13, 2024 at 1:12 PM Bruce Momjian <bruce@momjian.us> wrote:

On Wed, Mar 13, 2024 at 09:21:27AM -0700, Jeremy Schneider wrote:

It's not just roadmaps and release pages where we mix up these terms
either, it's even in user-facing SQL and libpq routines: both
PQserverVersion and current_setting('server_version_num') return the
patch release version in the numeric patch field, rather than the
numeric minor field (which is always 0).

In my view, the best thing would be to move toward consistently using
the word "patch" and moving away from the word "minor" for the
PostgreSQL quarterly maintenance updates.

I think "minor" is a better term since it contrasts with "major". We
don't actually supply patches to upgrade minor versions.

I tend to agree with Bruce, and major/minor seems to be the more
common usage within the industry; iirc, debian, ubuntu, gnome, suse,
and mariadb all use that nomenclature; and ISTR some distro's who
release packaged versions of postgres with custom patches applied (ie
12.4-2 for postgres 12.4 patchlevel 2).

BTW, as a reminder, we do have this statement, in bold, in the
"upgrading" section of the versioning page:
"We always recommend that all users run the latest available minor
release for whatever major version is in use." There is actually
several other phrases and wording on that page that could probably be
propagated as replacement language in some of these other areas.

Robert Treat
https://xzilla.net

Robert Treat <rob@xzilla.net> writes:

On Wed, Mar 13, 2024 at 1:12 PM Bruce Momjian <bruce@momjian.us> wrote:

On Wed, Mar 13, 2024 at 09:21:27AM -0700, Jeremy Schneider wrote:

In my view, the best thing would be to move toward consistently using
the word "patch" and moving away from the word "minor" for the
PostgreSQL quarterly maintenance updates.

I think "minor" is a better term since it contrasts with "major". We
don't actually supply patches to upgrade minor versions.

I tend to agree with Bruce, and major/minor seems to be the more
common usage within the industry; iirc, debian, ubuntu, gnome, suse,
and mariadb all use that nomenclature; and ISTR some distro's who
release packaged versions of postgres with custom patches applied (ie
12.4-2 for postgres 12.4 patchlevel 2).

Agreed, we would probably add confusion not reduce it if we were to
change our longstanding nomenclature for this.

I'm +1 on rewriting these documentation pages though. Seems like
they could do with a whole fresh start rather than just tweaks
around the edges --- what we've got now is an accumulation of such
tweaks.

regards, tom lane

On 3/13/24 11:21 AM, Tom Lane wrote:

Robert Treat <rob@xzilla.net> writes:

On Wed, Mar 13, 2024 at 1:12 PM Bruce Momjian <bruce@momjian.us> wrote:

On Wed, Mar 13, 2024 at 09:21:27AM -0700, Jeremy Schneider wrote:

In my view, the best thing would be to move toward consistently using
the word "patch" and moving away from the word "minor" for the
PostgreSQL quarterly maintenance updates.

I think "minor" is a better term since it contrasts with "major". We
don't actually supply patches to upgrade minor versions.

I tend to agree with Bruce, and major/minor seems to be the more
common usage within the industry; iirc, debian, ubuntu, gnome, suse,
and mariadb all use that nomenclature; and ISTR some distro's who
release packaged versions of postgres with custom patches applied (ie
12.4-2 for postgres 12.4 patchlevel 2).

Agreed, we would probably add confusion not reduce it if we were to
change our longstanding nomenclature for this.

"Longstanding nomenclature"??

Before v10, the quarterly maintenance updates were unambiguously and
always called patch releases

I don't understand the line of thinking here

Bruce started this whole thread because of "an increasing number of
bug/problem reports on obsolete Postgres versions"

Across the industry the word "minor" often implies a release that will
be maintained, and I'm trying to point out that the change in v10 to
change terminology from "patch" to "minor" actually might be part of
what's responsible for the increasing number of bug reports on old patch
releases, because people don't understand that patch releases are the
way those bugfixes were already delivered.

Just taking MySQL as an example, it's clear that a "minor" like 5.7 is a
full blown release that gets separate patches from 5.6 - so I don't
understand how we're making an argument it's the opposite?

-Jeremy

--
http://about.me/jeremy_schneider

Jeremy Schneider <schneider@ardentperf.com> writes:

On 3/13/24 11:21 AM, Tom Lane wrote:

Agreed, we would probably add confusion not reduce it if we were to
change our longstanding nomenclature for this.

Before v10, the quarterly maintenance updates were unambiguously and
always called patch releases

I think that's highly revisionist history. I've always called them
minor releases, and I don't recall other people using different
terminology. I believe the leadoff text on

https://www.postgresql.org/support/versioning/

is much older than when we switched from two-part major version
numbers to one-part major version numbers.

regards, tom lane

On Mar 13, 2024, at 11:39 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Jeremy Schneider <schneider@ardentperf.com> writes:

On 3/13/24 11:21 AM, Tom Lane wrote:
Agreed, we would probably add confusion not reduce it if we were to
change our longstanding nomenclature for this.

Before v10, the quarterly maintenance updates were unambiguously and
always called patch releases

I think that's highly revisionist history. I've always called them
minor releases, and I don't recall other people using different
terminology. I believe the leadoff text on

https://www.postgresql.org/support/versioning/

is much older than when we switched from two-part major version
numbers to one-part major version numbers.

Huh, that wasn’t what I expected. I only started (in depth) working with PG around 9.6 and I definitely thought of “6” as the minor version. This is an interesting mailing list thread.

-Jeremy

Sent from my TI-83

On Wed, Mar 13, 2024 at 02:21:20PM -0400, Tom Lane wrote:

I'm +1 on rewriting these documentation pages though. Seems like
they could do with a whole fresh start rather than just tweaks
around the edges --- what we've got now is an accumulation of such
tweaks.

If no one else volunteers, I could probably give this a try once v17 is
frozen.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

On Tue, 2024-03-12 at 11:56 +0100, Daniel Gustafsson wrote:

I liked the statement from Laurenz a while ago on his blog
(paraphrased): "Upgrading to the latest patch release does not require
application testing or recertification". I am not sure we want to put
that into the official page (or maybe tone down/qualify it a bit), but I
think a lot of users stay on older minor versions because they dread
their internal testing policies.

I think we need a more conservative language since a minor release might fix a
planner bug that someone's app relied on and their plans will be worse after
upgrading.  While rare, it can for sure happen so the official wording should
probably avoid such bold claims.

I think we are pretty conservative with backpatching changes to the
optimizer that could destabilize existing plans.

I feel quite strongly that we should not use overly conservative language
there. If people feel that they have to test their applications for new
minor releases, the only effect will be that they won't install minor releases.
Installing a minor release should be as routine as the operating system
patches that many companies apply automatically during weekend maintenance
windows. They can also introduce bugs, and everybody knows and accepts that.

Yours,
Laurenz Albe

On Wed, Mar 13, 2024 at 3:05 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:

I think we are pretty conservative with backpatching changes to the
optimizer that could destabilize existing plans.

We have gotten better about that, which is good.

I feel quite strongly that we should not use overly conservative language
there. If people feel that they have to test their applications for new
minor releases, the only effect will be that they won't install minor releases.
Installing a minor release should be as routine as the operating system
patches that many companies apply automatically during weekend maintenance
windows. They can also introduce bugs, and everybody knows and accepts that.

I don't agree with this. If we tell people that they don't need to
test their applications after an upgrade, I do not think that the
result will be that they skip the testing and everything works
perfectly. I think that the result will be that we lose all
credibility. Nobody who has been working on computers for longer than
a week is going to believe that a software upgrade can't break
anything, and someone whose entire business depends on things not
breaking is going to want to validate that they haven't. And they're
not wrong to think that way, either.

I think that whatever we say here should focus on what we try to do or
guarantee, not on what actions we think users ought to take, never
mind must take. We can say that we try to avoid making any changes
upon which an application might be relying -- but there surely is some
weasel-wording there, because we have made such changes before in the
name of security, and sometimes to fix bugs, and we will likely to do
so again in the future. But it's not for us to decide how much testing
is warranted. It's the user's system, not ours.

In the end, while I certainly don't mind improving the web page, I
think that a lot of what we're seeing here probably has to do with the
growing popularity and success of PostgreSQL. If you have more people
using your software, you're also going to have more people using
out-of-date versions of your software.

--
Robert Haas
EDB: http://www.enterprisedb.com

On 13.03.24 18:12, Bruce Momjian wrote:

On Wed, Mar 13, 2024 at 09:21:27AM -0700, Jeremy Schneider wrote:

It's not just roadmaps and release pages where we mix up these terms
either, it's even in user-facing SQL and libpq routines: both
PQserverVersion and current_setting('server_version_num') return the
patch release version in the numeric patch field, rather than the
numeric minor field (which is always 0).

In my view, the best thing would be to move toward consistently using
the word "patch" and moving away from the word "minor" for the
PostgreSQL quarterly maintenance updates.

I think "minor" is a better term since it contrasts with "major". We
don't actually supply patches to upgrade minor versions.

There are potentially different adjectives that could apply to "version"
and "release".

The version numbers can be called major and minor, because that just
describes their ordering and significance.

But I do agree that "minor release" isn't quite as clear, because one
could also interpret that as "a release, but a bit smaller this time".
(Also might not translate well, since "minor" and "small" could
translate to the same thing.)

One could instead, for example, describe those as "maintenance releases":

"Are you on the latest maintenance release? Why not? Are you not
maintaining your database?"

That carries much more urgency than the same with "minor".

A maintenance release corresponds to an increase in the minor version
number. It's still tied together, but has different terminology.

The last news item reads:

"The PostgreSQL Global Development Group has released an update to all
supported versions of PostgreSQL"

which has no urgency, but consider

"The PostgreSQL Global Development Group has published maintenance
releases to all supported versions of PostgreSQL"

On Thu, Mar 14, 2024 at 10:15:18AM -0400, Robert Haas wrote:

I think that whatever we say here should focus on what we try to do or
guarantee, not on what actions we think users ought to take, never
mind must take. We can say that we try to avoid making any changes
upon which an application might be relying -- but there surely is some
weasel-wording there, because we have made such changes before in the
name of security, and sometimes to fix bugs, and we will likely to do
so again in the future. But it's not for us to decide how much testing
is warranted. It's the user's system, not ours.

Yes, good point, let's tell whem what our goals are and they can decide
what testing they need.

In the end, while I certainly don't mind improving the web page, I
think that a lot of what we're seeing here probably has to do with the
growing popularity and success of PostgreSQL. If you have more people
using your software, you're also going to have more people using
out-of-date versions of your software.

Yeah, probably, and we recently end-of-life'ed PG 11.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.