Re: pg_upgrade does not upgrade pg_stat_statements properly

From: Dave Cramer <davecramer(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_upgrade does not upgrade pg_stat_statements properly
Date: 2021-07-15 11:40:54
Message-ID: CADK3HHJJm_EocOX5Jtvus2pYw_mSFH99t02fOP00K2D-hNfVRA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dave Cramer

On Wed, 14 Jul 2021 at 15:43, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Dave Cramer <davecramer(at)gmail(dot)com> writes:
> > On Wed, 14 Jul 2021 at 15:09, David G. Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)com>
> > wrote:
> >> "Install ... files used by the old cluster" (which must be binary
> >> compatible with the new cluster as noted elsewhere on that page)
> supports
> >> the claim that it is the old cluster's version that is going to result.
> >> But I agree that saying "because these will be upgraded from the old
> >> cluster" is poorly worded and should be fixed to be more precise here.
> >>
> >> Something like, "... because the installed extensions will be copied
> from
> >> the old cluster during the upgrade."
>
> > This is still rather opaque. Without intimate knowledge of what changes
> > have occurred in each extension I have installed; how would I know what I
> > have to fix after the upgrade.
>
> That's exactly why we don't force upgrades of extensions. It is on the
> user's head to upgrade their extensions from time to time, but we don't
> make them do it as part of pg_upgrade. (There are also some
> implementation-level reasons to avoid this, IIRC, but the overall
> choice is intentional.)
>
> I agree this documentation could be worded better.

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>

> Another idea
> is that possibly pg_upgrade could produce a list of extensions
> that are not the latest version, so people know what's left to
> be addressed.
>

It would be possible to look at the control files in the new cluster to see
the default version and simply output a file with the differences.
We can query pg_extension for the currently installed versions.

Dave

>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2021-07-15 11:42:39 Re: Enhanced error message to include hint messages for redundant options error
Previous Message Josef Šimánek 2021-07-15 11:40:31 Re: Git revision in tarballs