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:

Previous
From: Yura Sokolov
Date:
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade does not upgrade pg_stat_statements properly