On 2/22/21 12:48 AM, Andres Freund wrote:
> Hi,
>
> On 2021-02-22 00:15:20 +0100, Vik Fearing wrote:
>> I do some very regular testing on HEAD and my scripts need to know if
>> the catalog version has changed to determine if it needs to pg_restore
>> or if a basebackup is okay. In order to get it, I have to do this:
>>
>>
>> # Get the catalog version (there is no better way to do this)
>> tmp=$(mktemp --directory)
>> $bin/initdb --pgdata=$tmp
>> catversion=$($bin/pg_controldata $tmp | grep "Catalog version" \
>> | cut --delimiter=: --fields=2 | xargs)
>> rm --recursive --force $tmp
>
> That's a pretty heavy way to do it.
That's what I thought, too!
> If you have access to pg_config, you
> could just do
> grep '^#define CATALOG_VER' $(pg_config
> --includedir)/server/catalog/catversion.h|awk '{print $3}'
Oh thanks. That's much better.
>> I find this less than attractive, especially since the catalog version
>> is a property of the binaries and not the data directory. Attached is a
>> patchset so that the above can become simply:
>>
>> catversion=$($bin/pg_config --catversion)
>
> Seems roughly reasonable. Although I wonder if we rather should make it
> something more generic than just catversion? E.g. a wal page magic bump
> will also require a dump/restore or pg_upgrade, but won't be detected by
> just doing this. So perhaps we should instead add a pg_config option
> showing all the different versions that influence on-disk compatibility?
Do you mean one single thing somehow lumped together, or one for each
version number?
--
Vik Fearing
