Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thursday, July 15, 2021, Dave Cramer <davecramer(at)gmail(dot)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.

David J.