Re: pg_upgrade does not upgrade pg_stat_statements properly

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_upgrade does not upgrade pg_stat_statements properly
Дата
Msg-id 3562835.1626291827@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_upgrade does not upgrade pg_stat_statements properly  (Dave Cramer <davecramer@gmail.com>)
Ответы Re: pg_upgrade does not upgrade pg_stat_statements properly
Список pgsql-hackers
Dave Cramer <davecramer@gmail.com> writes:
> On Wed, 14 Jul 2021 at 15:09, David G. Johnston <david.g.johnston@gmail.com>
> wrote:
>> "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.

That's exactly why we don't force upgrades of extensions.  It is on the
user's head to upgrade their extensions from time to time, but we don't
make them do it as part of pg_upgrade.  (There are also some
implementation-level reasons to avoid this, IIRC, but the overall
choice is intentional.)

I agree this documentation could be worded better.  Another idea
is that possibly pg_upgrade could produce a list of extensions
that are not the latest version, so people know what's left to
be addressed.

            regards, tom lane



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

Предыдущее
От: Ibrar Ahmed
Дата:
Сообщение: Re: Remove page-read callback from XLogReaderState.
Следующее
От: John Naylor
Дата:
Сообщение: Re: Replacing pg_depend PIN entries with a fixed range check