Re: pg_upgrade vs extension upgrades

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade vs extension upgrades
Date: 2017-04-13 02:56:30
Message-ID: 20170413025630.GB3641@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 12, 2017 at 06:59:32PM -0400, Robert Haas wrote:
> On Wed, Apr 12, 2017 at 6:30 PM, Peter Eisentraut
> > If I restore a dump into another instance, I need to upgrade all my
> > extensions to that installations's versions, no? That's not particular
> > to pg_upgrade.
>
> No, it's an optional step. If we did the upgrade by default, it would
> greatly increase the chance of something failing. For example,
> suppose the upgrade does a DROP and then CREATE of a function whose
> signature has changed. If there's anything that depends on that
> function, this will fail. But if we don't do it, there's no actual
> problem: the shared library is supposed to be prepared to cope with
> people still using the old SQL definition. It is probably desirable
> to update where possible to gain access to new features, etc., but it
> shouldn't be required.
>
> I do think there might be some value in a tool that looked for old
> extensions and tried to update them, but I'm not sure it should be
> pg_dump.

Is pg_upgrade the right place for an extension upgrade script? When
pg_upgrade started creating an incremental-analyze script, people
thought it should be more generic so it was moved to vacuumdb
--analyze-in-stages. Seems we should do the same thing for the
extension upgrade script.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2017-04-13 02:59:00 Re: delta relations in AFTER triggers
Previous Message Michael Paquier 2017-04-13 02:54:59 Re: Letting the client choose the protocol to use during a SASL exchange