| From: | Dave Cramer <davecramer(at)gmail(dot)com> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(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-15 15:43:20 |
| Message-ID: | CADK3HHKXWBtyxVXBsBf8RKibaLusWGE3Y+b4iQ_xfrTQKupQZA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 15 Jul 2021 at 11:29, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
wrote:
> On Thursday, July 15, 2021, Dave Cramer <davecramer(at)gmail(dot)com> wrote:
>
>>
>> I'm thinking at this point we need something a bit more sophisticated like
>>
>> ALTER EXTENSION ... UPGRADE. And the extension knows how to upgrade
>> itself.
>>
>
> I’m not familiar with what hoops extensions jump through to facilitate
> upgrades but even if it was as simple as “create extension upgrade” I
> wouldn’t have pg_upgrade execute that command (or at least not by
> default). I would maybe have pg_upgrade help move the libraries over from
> the old server (and we must be dealing with different databases having
> different extension versions in some manner…).
>
Well IMHO the status quo is terrible. Perhaps you have a suggestion on how
to make it better ?
Dave
>
> David J.
>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2021-07-15 15:43:59 | Re: enable_resultcache confusion |
| Previous Message | Tom Lane | 2021-07-15 15:43:12 | Re: Replacing pg_depend PIN entries with a fixed range check |