Re: Reports on obsolete Postgres versions

From: Greg Sabino Mullane <htamfids(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reports on obsolete Postgres versions
Date: 2024-03-12 00:40:56
Message-ID: CAKAnmmJoNjku+qDwFyS_9tr1RpOLx9S0tedgT6rk0Tu16Avo-g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 11, 2024 at 4:38 PM Bruce Momjian <bruce(at)momjian(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-03-12 01:22:18 Re: Using the %m printf format more
Previous Message Erik Wienhold 2024-03-12 00:33:55 Re: Patch: Add parse_type Function