On Thu, 15 Jul 2021 at 11:01, David G. Johnston <david.g.johns...@gmail.com> wrote:
> On Thursday, July 15, 2021, Dave Cramer <davecra...@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. > Well clearly my suggestion was not clear if you interpreted that as over writing them with versions from an older version of PostgreSQL. Dave Cramer > >
