From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Bruce Momjian <bruce@momjian.us>
Cc: Dave Cramer <davecramer@gmail.com>
Cc: David G. Johnston <david.g.johnston@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_upgrade does not upgrade pg_stat_statements properly
Date: Thu, 29 Jul 2021 13:43:09 -0400
Message-ID: <202107291743.pqlj3s2uilfu@alvherre.pgsql> (raw)
In-Reply-To: <20210729163448.GP9600@momjian.us>
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.
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 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.
I suggest using the imperative mood, to be consistent with the
surrounding text. (Applies to the first para; the second para is
informative.)
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.
--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
"Sallah, I said NO camels! That's FIVE camels; can't you count?"
(Indiana Jones)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: alvherre@alvh.no-ip.org, bruce@momjian.us, davecramer@gmail.com, david.g.johnston@gmail.com, tgl@sss.pgh.pa.us, pgsql-hackers@lists.postgresql.org
Subject: Re: pg_upgrade does not upgrade pg_stat_statements properly
In-Reply-To: <202107291743.pqlj3s2uilfu@alvherre.pgsql>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox