From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Jan Wieck <jan(at)wi3ck(dot)info> |
Cc: | Dave Cramer <davecramer(at)postgres(dot)rocks>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_upgrade does not upgrade pg_stat_statements properly |
Date: | 2021-07-15 23:31:07 |
Message-ID: | CAKFQuwYde-GKV0CrRUZMVefKFPbF-Tb8JjaRUjDf+MxXT89xyg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thursday, July 15, 2021, Jan Wieck <jan(at)wi3ck(dot)info> wrote:
> On 7/15/21 4:24 PM, David G. Johnston wrote:
>
> OK, especially as this seems useful outside of pg_upgrade, and if done
>> separately is something pg_upgrade could just run as part of its new
>> cluster evaluation scripts. Knowing whether an extension is outdated
>> doesn't require the old cluster.
>>
>
> Knowing that (the extension is outdated) exactly how? Can you give us an
> example query, maybe a few SQL snippets explaining what exactly you are
> talking about? Because at this point you completely lost me.
>
I was mostly going off other people saying it was possible. In any case,
looking at pg_available_extension_versions, once you figure out how to
order by the version text column, would let you check if any installed
extensions are not their latest version.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | r.takahashi_2@fujitsu.com | 2021-07-15 23:34:36 | RE: Speed up COMMIT PREPARED |
Previous Message | Jan Wieck | 2021-07-15 23:18:10 | Re: pg_upgrade does not upgrade pg_stat_statements properly |