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