Re: pg_upgrade does not upgrade pg_stat_statements properly - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: pg_upgrade does not upgrade pg_stat_statements properly |
Date | |
Msg-id | 20210729190645.GS9600@momjian.us Whole thread Raw |
In response to | Re: pg_upgrade does not upgrade pg_stat_statements properly (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Responses |
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 (Bruce Momjian <bruce@momjian.us>) |
List | pgsql-hackers |
On Thu, Jul 29, 2021 at 01:43:09PM -0400, Álvaro Herrera wrote: > On 2021-Jul-29, Bruce Momjian wrote: > > > + If the old cluster used extensions, whether from > > + <filename>contrib</filename> or some other source, it used > > + shared object files (or DLLs) to implement these extensions, e.g., > > + <filename>pgcrypto.so</filename>. Now, shared object files matching > > + the new server binary must be installed in the new cluster, usually > > + via operating system commands. Do not load the schema definitions, > > + e.g., <command>CREATE EXTENSION pgcrypto</command>, because these > > + will be copied from the old cluster. (Extensions should be upgraded > > + later using <literal>ALTER EXTENSION ... UPGRADE</literal>.) > > I propose this: > > <para> > If the old cluster used shared-object files (or DLLs) for extensions > or other loadable modules, install recompiled versions of those files > onto the new cluster. > Do not install the extension themselves (i.e., do not run > <command>CREATE EXTENSION</command>), because extension definitions > will be carried forward from the old cluster. > </para> > > <para> > Extensions can be upgraded after pg_upgrade completes using > <command>ALTER EXTENSION ... UPGRADE</command>, on a per-database > basis. > </para> > > I suggest " ... for extensions or other loadable modules" because > loadable modules aren't necessarily for extensions. Also, it's > perfectly possible to have extension that don't have a loadable module. Yes, good point. > I suggest "extension definitions ... carried forward" instead of > "extensions ... copied" (your proposed text) to avoid the idea that > files are copied; use it instead of "schema definitions ... upgraded" > (the current docs) to avoid the idea that they are actually upgraded; > also, "schema definition" seems a misleading term to use here. I used the term "duplicated". > I suggest "can be upgraded" rather than "should be upgraded" because > we're not making a recommendation, merely stating the fact that it is > possible to do so. Agreed. Most extensions don't have updates between major versions. > I suggest using the imperative mood, to be consistent with the > surrounding text. (Applies to the first para; the second para is > informative.) OK. > I haven't seen it mentioned in the thread, but I think the final phrase > of this <step> should be a separate step, > > <step> > <title>Copy custom full-text search files</title> > <para> > Copy any custom full text search file (dictionary, synonym, thesaurus, > stop word list) to the new server. > </para> > </step> > > While this is closely related to extensions, it's completely different. Agreed. See attached patch. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
Attachment
pgsql-hackers by date: