Re: Problems with pg_upgrade and extensions referencing catalog tables/views
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Problems with pg_upgrade and extensions referencing catalog tables/views |
| Дата | |
| Msg-id | 9728.1557358405@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Problems with pg_upgrade and extensions referencing catalogtables/views ("Nasby, Jim" <nasbyj@amazon.com>) |
| Список | pgsql-hackers |
"Nasby, Jim" <nasbyj@amazon.com> writes:
> The problem is that pg_dump --binary-upgrade intentionally does not
> simply issue a `CREATE EXTENSION` command the way a normal dump does, so
> that it can control the OIDs that are assigned to objects[1].
That's not the only reason. The original concerns were about not
breaking the extension, in case the destination server had a different
version of the extension available. CREATE EXTENSION doesn't normally
guarantee that you get an exactly compatible extension version, which
is a good thing for regular pg_dump and restore but a bad thing
for binary upgrade.
I'm not really sure how to improve the situation you describe, but
"issue CREATE EXTENSION and pray" doesn't sound like a solution.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера