Re: pg_upgrade does not upgrade pg_stat_statements properly

From: Jan Wieck <jan(at)wi3ck(dot)info>
To: Dave Cramer <davecramer(at)postgres(dot)rocks>, Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_upgrade does not upgrade pg_stat_statements properly
Date: 2021-07-30 16:43:04
Message-ID: 3b757bb5-b481-3615-6d44-aaf0ab2813c8@wi3ck.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 7/30/21 7:33 AM, Dave Cramer wrote:
>
>
>
>
> Yes, but as I said twice only if the currently installed version is
> different
> from the default version.  Otherwise ALTER EXTENSION UPGRADE is a no-op.
>
>
> Ah, ok, got it, thanks. Well I'm not sure how to deal with this.
> The only thing I can think of is that we add a post_upgrade function to
> the API.
>
> All extensions would have to implement this.

An alternative to this would be a recommended version number scheme for
extensions. If extensions were numbered

MAJOR_SERVER.MAJOR_EXTENSION.MINOR_EXTENSION

then pg_upgrade could check the new cluster for the existence of an SQL
script that upgrades the extension from the old cluster's version to the
new current. And since an extension cannot have the same version number
on two major server versions, there is no ambiguity here.

The downside is that all the extensions that don't need anything done
for those upgrades (which I believe is the majority of them) would have
to provide empty SQL files. Not necessarily a bad thing, as it actually
documents "yes, the extension developer checked this and there is
nothing to do here."

Regards, Jan

--
Jan Wieck

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2021-07-30 16:44:17 Re: pg_upgrade does not upgrade pg_stat_statements properly
Previous Message Bruce Momjian 2021-07-30 16:40:06 Re: pg_upgrade does not upgrade pg_stat_statements properly