Re: pg_upgrade does not upgrade pg_stat_statements properly - Mailing list pgsql-hackers

From Dave Cramer
Subject Re: pg_upgrade does not upgrade pg_stat_statements properly
Date
Msg-id CADK3HH+LSuyks36i9TeMFT44NxHTbHHjNq_Mv8+BFNrazxpVvg@mail.gmail.com
Whole thread Raw
In response to Re: pg_upgrade does not upgrade pg_stat_statements properly  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_upgrade does not upgrade pg_stat_statements properly  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers


On Thu, 29 Jul 2021 at 11:10, Bruce Momjian <bruce@momjian.us> wrote:
On Thu, Jul 29, 2021 at 11:01:43AM -0400, Dave Cramer wrote:
>
>
>
>
>     OK, I went with this new text.  There is confusion over install vs copy,
>     and whether this is happening at the operating system level or the SQL
>     level.  I tried to clarify that, but I am not sure I was successful.  I
>     also used the word "extension" since this is more common than "custom".
>
>
> Much better, however I'm unclear on whether CREATE EXTENSION is actually
> executed on the upgraded server.
>
> From what I could gather it is not, otherwise the new function definitions
> should have been in place. 
> I think what happens is that the function definitions are copied as part of the
> schema and pg_extension is also copied.

Yes, the _effect_ of CREATE EXTENSION in the old cluster is copied to
the new cluster as object definitions.  CREATE EXTENSION runs the SQL
files associated with the extension.

OK, I think we should be more clear as to what is happening.  Saying they will be recreated is misleading.
The extension definitions are being copied from the old server to the new server.

I also think we should have stronger wording in the "The extensions may be upgraded ..." statement. 
I'd suggest "Any new versions of extensions should be upgraded using...."

Dave

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Replace l337sp34k in comments.
Next
From: wenjing zeng
Date:
Subject: Re: [Proposal] Global temporary tables