Re: [HACKERS] pg_upgrade vs extension upgrades

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: [HACKERS] pg_upgrade vs extension upgrades
Дата
Msg-id CABUevEwn6mZE7oj1-qmjD_Bdf_VAsB34hWhGrn7+UF9ZyusKRw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] pg_upgrade vs extension upgrades  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, Apr 10, 2017 at 6:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
> After you've run pg_upgrade, you have to loop through all your databases
> and do an "ALTER EXTENSION abc UPDATE" once for each extension.

> Is there a reason we shouldn't have pg_upgrade emit a script that does
> this, similar to how it emits a script to run ANALYZE?

+1 --- I think this has been discussed before, but nobody got round
to it.

Do we need to worry about the order of the updates when there are
cross-extension dependencies?  I'm thinking that if extension A
requires extension B, it'd be safest to update B first.

Good point, I wasn't considering dependencies. I was envisioning something as simple as querying pg_available_extensions and check the versions and then just run -- that has always worked for me, but when I think of it I don't think I've ever had dependent extensions in those systems.

But that should probably be parsable out of pg_available_extension_versions, I think. Because surely it should be OK to rely only on the new dependency information, in case it has actually changed?

And since it's an external script, it's not the end of the world if it fails in super-cornery cases, as long as it covers the majority. 


--

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

Предыдущее
От: Michael Meskes
Дата:
Сообщение: Re: [HACKERS] Host variables corresponding bytea type in ecpg
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: Re: [HACKERS] [sqlsmith] ERROR: badly formatted node string "RESTRICTINFO...