Re: pg_upgrade does not upgrade pg_stat_statements properly - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_upgrade does not upgrade pg_stat_statements properly
Date
Msg-id 3562835.1626291827@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_upgrade does not upgrade pg_stat_statements properly  (Dave Cramer <davecramer@gmail.com>)
Responses Re: pg_upgrade does not upgrade pg_stat_statements properly  (Dave Cramer <davecramer@gmail.com>)
List pgsql-hackers
Dave Cramer <davecramer@gmail.com> writes:
> On Wed, 14 Jul 2021 at 15:09, David G. Johnston <david.g.johnston@gmail.com>
> wrote:
>> "Install ... files used by the old cluster" (which must be binary
>> compatible with the new cluster as noted elsewhere on that page) supports
>> the claim that it is the old cluster's version that is going to result.
>> But I agree that saying "because these will be upgraded from the old
>> cluster" is poorly worded and should be fixed to be more precise here.
>> 
>> Something like, "... because the installed extensions will be copied from
>> the old cluster during the upgrade."

> This is still rather opaque. Without intimate knowledge of what changes
> have occurred in each extension I have installed; how would I know what I
> have to fix after the upgrade.

That's exactly why we don't force upgrades of extensions.  It is on the
user's head to upgrade their extensions from time to time, but we don't
make them do it as part of pg_upgrade.  (There are also some
implementation-level reasons to avoid this, IIRC, but the overall
choice is intentional.)

I agree this documentation could be worded better.  Another idea
is that possibly pg_upgrade could produce a list of extensions
that are not the latest version, so people know what's left to
be addressed.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Ibrar Ahmed
Date:
Subject: Re: Remove page-read callback from XLogReaderState.
Next
From: John Naylor
Date:
Subject: Re: Replacing pg_depend PIN entries with a fixed range check