Re: pg_upgrade does not upgrade pg_stat_statements properly

On Thu, Jul 15, 2021 at 11:52 AM Dave Cramer <davecramer(at)postgres(dot)rocks>
wrote:

>
> On Thu, 15 Jul 2021 at 14:31, David G. Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
>>
>> Yep, and IIUC running "CREATE EXTENSION pg_stat_statements VERSION
>> '1.5';" works correctly in v13 as does executing
>>
> While it does work there are issues with dumping and restoring a database
> with the old version of pg_stat_statements in it that would only be found
> by dumping and restoring.
>

I'm unsure how this impacts the broader discussion. At worse you'd have a
chance to manually run the update command on the new cluster before using
dump/restore.

>
>> "ALTER EXTENSION pg_stat_statements UPDATE;" while version 1.5 is
>> installed.
>>
>
>
>
>> So even without doing the copying of the old contrib libraries to the new
>> server such a "one at a time" procedure would work just fine for this
>> particular contrib extension.
>>
>
> You cannot copy the old contrib libraries into the new server. This will
> fail due to changes in the API and various exported variables either not
> being there or being renamed.
>

If this is true then the docs have a bug. It sounds more like the
documentation should say "ensure that the new cluster has extension
libraries installed that are compatible with the version of the extension
installed on the old cluster". Whether we want to be even more specific
with regards to contrib I cannot say - it seems like newer versions largely
retain backward compatibility so this is basically a non-issue for contrib
(though maybe individual extensions have their own requirements?)

but it fails to say that the versions that are installed may need to be
> updated.
>

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.
David J.