Re: Catalog version access

From: Vik Fearing <vik(at)postgresfriends(dot)org>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Catalog version access
Date: 2021-03-03 17:52:04
Message-ID: 0ccac3a0-3aad-85cf-c594-24f7c991a3cb@postgresfriends.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/3/21 6:35 PM, Peter Eisentraut wrote:
> On 22.02.21 08:00, Vik Fearing wrote:
>> On 2/22/21 3:24 AM, Andres Freund wrote:
>>> Imagine trying to run regular tests of HEAD, where the tests require a
>>> large database to be loaded. Re-loading the data for every [few] commits
>>> is prohibitively time consuming, and even just running pg_upgrade is
>>> painful. So you'd like to re-use a "template" data directory with the
>>> data loaded if possible (i.e. no catversion / WAL / ... version bumps),
>>> and a pg_upgrade otherwise.
>>
>> This is exactly what I am doing.
>
> If what you want to know is whether a given binary can run against a
> given data directory then CATALOG_VERSION_NO isn't the only thing you
> need to check.  The full truth of this is in ReadControlFile().  The
> best way to get that answer is to start a server and see if it
> complains.  You can even grep the log for "It looks like you need to
> initdb.".

In that case, what would everyone think about a `pg_ctl check` option?
--
Vik Fearing

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2021-03-03 18:02:18 Re: Speeding up GIST index creation for tsvectors
Previous Message Pavel Stehule 2021-03-03 17:47:28 Re: proposal - psql - possibility to redirect only tabular output