Re: pg_upgrade does not upgrade pg_stat_statements properly

Поиск
Список
Период
Сортировка
От Dave Cramer
Тема Re: pg_upgrade does not upgrade pg_stat_statements properly
Дата
Msg-id CADK3HHJQ=GoGcH0u2Yf2Sbes+161xMwFd4FDNGzUViH4ncbeEw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_upgrade does not upgrade pg_stat_statements properly  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: pg_upgrade does not upgrade pg_stat_statements properly
Re: pg_upgrade does not upgrade pg_stat_statements properly
Список pgsql-hackers


On Wed, 14 Jul 2021 at 15:09, David G. Johnston <david.g.johnston@gmail.com> wrote:
On Wed, Jul 14, 2021 at 11:59 AM Dave Cramer <davecramer@gmail.com> wrote:


On Wed, 14 Jul 2021 at 14:47, David G. Johnston <david.g.johnston@gmail.com> wrote:
On Wednesday, July 14, 2021, Dave Cramer <davecramer@gmail.com> wrote:


Notice the upgraded version is 1.5 and the new version is 1.8

I would think somewhere in the upgrade of the schema there should have been a create extension pg_stat_statements ?

That would be a faulty assumption.  Modules do not get upgraded during a server version upgrade.  This is a good thing, IMO.

This is from the documentation of pg_upgrade

Install any custom shared object files (or DLLs) used by the old cluster into the new cluster, e.g., pgcrypto.so, whether they are from contrib or some other source. Do not install the schema definitions, e.g., CREATE EXTENSION pgcrypto, because these will be upgraded from the old cluster. Also, any custom full text search files (dictionary, synonym, thesaurus, stop words) must also be copied to the new cluster.

If indeed modules do not get upgraded then the above is confusing at best, and misleading at worst.


"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. 

Seems to me extensions should either store some information in pg_extension to indicate compatibility, or they should have some sort of upgrade script which pg_upgrade would call to fix any problems (yes, I realize this is hand waving at the moment)

In this example the older version of pg_stat_statements works fine, it only fails when I do a dump restore of the new database and then the error is rather obtuse. IIRC pg_dump wanted to revoke all from public from the function pg_stat_statements_reset() and that could not be found, yet the function is there. I don't believe we should be surprising our users like this.

Dave

David J.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ibrar Ahmed
Дата:
Сообщение: Re: BUG #16583: merge join on tables with different DB collation behind postgres_fdw fails
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] Hooks at XactCommand level