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

From Jan Wieck
Subject Re: pg_upgrade does not upgrade pg_stat_statements properly
Date
Msg-id c4fc0792-1736-63e2-2447-ee2ed6e96b5b@wi3ck.info
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 7/29/21 11:10 AM, Bruce Momjian wrote:
> On Thu, Jul 29, 2021 at 11:01:43AM -0400, Dave Cramer wrote:
>> 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.
> 

This assumes that the scripts executed during CREATE EXTENSION have no 
conditional code in them that depends on the server version. Running the 
same SQL script on different server versions can have different effects.

I don't have a ready example of such an extension, but if we ever would 
convert the backend parts of Slony into an extension, it would be one.


Regards, Jan

-- 
Jan Wieck



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade does not upgrade pg_stat_statements properly
Next
From: Dave Cramer
Date:
Subject: Re: pg_upgrade does not upgrade pg_stat_statements properly