Re: pg_upgrade does not upgrade pg_stat_statements properly

Поиск
Список
Период
Сортировка
От Dave Cramer
Тема Re: pg_upgrade does not upgrade pg_stat_statements properly
Дата
Msg-id CADK3HH+LSuyks36i9TeMFT44NxHTbHHjNq_Mv8+BFNrazxpVvg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_upgrade does not upgrade pg_stat_statements properly  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: pg_upgrade does not upgrade pg_stat_statements properly
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Replace l337sp34k in comments.
Следующее
От: wenjing zeng
Дата:
Сообщение: Re: [Proposal] Global temporary tables