Re: pg_upgrade vs extension upgrades

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade vs extension upgrades
Date: 2017-04-11 12:12:39
Message-ID: CABUevEwn6mZE7oj1-qmjD_Bdf_VAsB34hWhGrn7+UF9ZyusKRw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 10, 2017 at 6:57 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Magnus Hagander <magnus(at)hagander(dot)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.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2017-04-11 12:27:21 Re: [sqlsmith] ERROR: badly formatted node string "RESTRICTINFO...
Previous Message Michael Meskes 2017-04-11 12:05:25 Re: Host variables corresponding bytea type in ecpg