Re: pg_upgrade does not upgrade pg_stat_statements properly
От | David G. Johnston |
---|---|
Тема | Re: pg_upgrade does not upgrade pg_stat_statements properly |
Дата | |
Msg-id | CAKFQuwZ7Cg3aD+oiBL7FE+F-tS_Bn5Lg4TqLpe-BxRoeazPS9w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_upgrade does not upgrade pg_stat_statements properly (Dave Cramer <davecramer@gmail.com>) |
Ответы |
Re: pg_upgrade does not upgrade pg_stat_statements properly
Re: pg_upgrade does not upgrade pg_stat_statements properly |
Список | pgsql-hackers |
On Thursday, July 15, 2021, Dave Cramer <davecramer@gmail.com> wrote:
As a first step I propose the followingdiff --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 installInstall any custom shared object files (or DLLs) used by the old clusterinto 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.
В списке pgsql-hackers по дате отправления: