Re: [HACKERS] pg_upgrade vs extension upgrades - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: [HACKERS] pg_upgrade vs extension upgrades
Date
Msg-id CABUevEwn6mZE7oj1-qmjD_Bdf_VAsB34hWhGrn7+UF9ZyusKRw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] pg_upgrade vs extension upgrades  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Michael Meskes
Date:
Subject: Re: [HACKERS] Host variables corresponding bytea type in ecpg
Next
From: Ashutosh Bapat
Date:
Subject: Re: [HACKERS] [sqlsmith] ERROR: badly formatted node string "RESTRICTINFO...