Re: pg_upgrade does not upgrade pg_stat_statements properly

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Dave Cramer <davecramer(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:15:57
Message-ID: CAKFQuwZhCVAhsjBX7vnBxAkK1XvzHci=J_-ibZyLpNtrt2fMcg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thursday, July 15, 2021, 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:
>
>>
>> Install any custom shared object files (or DLLs) used by the old
>> cluster
>> into the new cluster, e.g., <filename>pgcrypto.so</filename>,
>> whether they are from <filename>contrib</filename>
>> - or some other source.
>> However it may be
>> + necessary to recreate the extension on the new server after the
>> upgrade
>> + to ensure compatibility with the new library.
>>
>>
>
> My uncertainty revolves around core extensions since it seems odd to tell
> the user to overwrite them with versions from an older version of
> PostgreSQL.
>

Ok. Just re-read the docs a third time…no uncertainty regarding contrib
now…following the first part of the instructions means that before one
could re-run create extension they would need to restore the original
contrib library files to avoid the new extension code using the old
library. So that whole part about recreation is inconsistent with the
existing unchanged text.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2021-07-15 15:17:27 Re: pg_upgrade does not upgrade pg_stat_statements properly
Previous Message Dave Cramer 2021-07-15 15:09:28 Re: pg_upgrade does not upgrade pg_stat_statements properly