Re: Catalog version access

From: Andres Freund <andres(at)anarazel(dot)de>
To: Vik Fearing <vik(at)postgresfriends(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Catalog version access
Date: 2021-02-21 23:48:15
Message-ID: 20210221234815.g6ghvillyxbif6tt@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. 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}'

> 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?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2021-02-21 23:52:24 Re: Is a connection max lifetime useful in a connection pool?
Previous Message Thomas Munro 2021-02-21 23:19:41 Re: Finding cause of test fails on the cfbot site