Re: pg_upgrade does not upgrade pg_stat_statements properly

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Jan Wieck <jan(at)wi3ck(dot)info>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_upgrade does not upgrade pg_stat_statements properly
Date: 2021-07-15 18:30:35
Message-ID: CAKFQuwaK6nM5AP6YURKvfx+owKjPELQgh4kfmBxHFES-rixzTQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 15, 2021 at 11:14 AM Jan Wieck <jan(at)wi3ck(dot)info> wrote:

> On 7/15/21 1:10 PM, David G. Johnston wrote:
> > ... But while
> > PostgreSQL doesn't really have a choice here - it cannot be expected to
> > subdivide itself - extensions (at least external ones - PostGIS is one I
> > have in mind presently) - can and often do attempt to support multiple
> > versions of PostgreSQL for whatever major versions of their product they
> > are offering. For these it is possible to adhere to the "change one
> > thing at a time principle" and to treat the extensions as not being part
> > of "ALL the changes from one major version to the target version..."
>
> You may make that exception for an external extension like PostGIS. But
> I don't think it is valid for one distributed in sync with the core
> system in the contrib package, like pg_stat_statements. Which happens to
> be the one named in the subject line of this entire discussion.
>
>
Yep, and IIUC running "CREATE EXTENSION pg_stat_statements VERSION '1.5';"
works correctly in v13 as does executing "ALTER EXTENSION
pg_stat_statements UPDATE;" while version 1.5 is installed. So even
without doing the copying of the old contrib libraries to the new server
such a "one at a time" procedure would work just fine for this particular
contrib extension.

And since the OP was unaware of the presence of the existing ALTER
EXTENSION UPDATE command I'm not sure at what point a "lack of features"
complaint here is due to lack of knowledge or actual problems (yes, I did
forget too but at least this strengthens my position that one-at-a-time
methods are workable, even today).

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2021-07-15 18:41:05 Re: Using a stock openssl BIO
Previous Message Bruce Momjian 2021-07-15 18:26:24 Re: pg_upgrade does not upgrade pg_stat_statements properly