Re: pg_upgrade does not upgrade pg_stat_statements properly

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: pg_upgrade does not upgrade pg_stat_statements properly
Дата
Msg-id CAKFQuwbgOTMcDB4aRoU9+h8sCP=E+ikyRRv7b4DA=RLXepMwwQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_upgrade does not upgrade pg_stat_statements properly  (Jan Wieck <jan@wi3ck.info>)
Ответы Re: pg_upgrade does not upgrade pg_stat_statements properly
Список pgsql-hackers
On Thu, Jul 29, 2021 at 9:28 AM Jan Wieck <jan@wi3ck.info> wrote:
On 7/29/21 12:00 PM, David G. Johnston wrote:
> Ok, looking at the flow again, where exactly would the user even be able
> to execute "CREATE EXTENSION" meaningfully?  The relevant databases do
> not exist (not totally sure what happens to the postgres database
> created during the initdb step...) so at the point where the user is
> "installing the extension" all they can reasonably do is a server-level
> install (they could maybe create extension in the postgres database, but
> does that even matter?).
>
> So, I'd propose simplifying this all to something like:
>
> Install extensions on the new server

Extensions are not installed on the server level. Their binary
components (shared objects) are, but the actual catalog modifications
that make them accessible are performed per database by CREATE
EXTENSION, which executes the SQL files associated with the extension.
And they can be performed differently per database, like for example
placing one and the same extension into different schemas in different
databases.

pg_upgrade is not (and should not be) concerned with placing the
extension's installation components into the new version's lib and share
directories. But it is pg_upgrade's job to perform the correct catalog
modification per database during the upgrade.

That is exactly the point I am making.  The section is informing the user of things to do that the server will not do.  Which is "install extension code into the O/S" and that mentioning CREATE EXTENSION at this point in the process is talking about something that is simply out-of-scope.

 
> Any extensions that are used by the old cluster need to be installed
> into the new cluster.  Each database in the old cluster will have its
> current version of all extensions migrated to the new cluster as-is. 
> You can use the ALTER EXTENSION command, on a per-database basis, to
> update its extensions post-upgrade.

That assumes that the extension SQL files are capable of detecting a
server version change and perform the necessary (if any) steps to alter
the extension's objects accordingly.

Off the top of my head I don't remember what happens when one executes
ALTER EXTENSION ... UPGRADE ... when it is already on the latest version
*of the extension*. Might be an error or a no-op.

And to make matters worse, it is not possible to work around this with a
DROP EXTENSION ... CREATE EXTENSION. There are extensions that create
objects, like user defined data types and functions, that will be
referenced by end user objects like tables and views.


These are all excellent points - but at present pg_upgrade simply doesn't care and hopes that the extension author's documentation deals with these possibilities in a sane manner.

David J.

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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_upgrade does not upgrade pg_stat_statements properly
Следующее
От: Yura Sokolov
Дата:
Сообщение: Re: [PoC] Improve dead tuple storage for lazy vacuum