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/>
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 |