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

On Thursday, July 15, 2021, Dave Cramer <davecramer@gmail.com> wrote:

As a first step I propose the following

diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml

index a83c63cd98..f747a4473a 100644

--- a/doc/src/sgml/ref/pgupgrade.sgml

+++ b/doc/src/sgml/ref/pgupgrade.sgml

@@ -305,9 +305,10 @@ make prefix=/usr/local/pgsql.new install

      Install any custom shared object files (or DLLs) used by the old cluster

      into the new cluster, e.g., <filename>pgcrypto.so</filename>,

      whether they are from <filename>contrib</filename>

-     or some other source. Do not install the schema definitions, e.g.,

-     <command>CREATE EXTENSION pgcrypto</command>, because these will be upgraded

-     from the old cluster.

+     or some other source. Do not execute CREATE EXTENSION on the new cluster.

+     The extensions will be upgraded from the old cluster. However it may be

+     necessary to recreate the extension on the new server after the upgrade

+     to ensure compatibility with the new library.

      Also, any custom full text search files (dictionary, synonym,

      thesaurus, stop words) must also be copied to the new cluster.

     </para>

 

I think this needs some work to distinguish between core extensions where we know the new server already has a library installed and external extensions where it’s expected that the library that is added to the new cluster is compatible with the version being migrated (not upgraded).  In short, it should never be necessary to recreate the extension.  My uncertainty revolves around core extensions since it seems odd to tell the user to overwrite them with versions from an older version of PostgreSQL.