From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Vik Fearing <vik(at)postgresfriends(dot)org> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Catalog version access |
Date: | 2021-02-22 00:54:01 |
Message-ID: | 3496407.1613955241@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Vik Fearing <vik(at)postgresfriends(dot)org> writes:
> On 2/22/21 12:48 AM, Andres Freund wrote:
>> 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?
FWIW, I think asking pg_config about this is a guaranteed way of having
version-skew-like bugs. If we're going to bother with providing a way
to get this info, we should make it possible to ask the running server.
(That would open up some security questions: do we want to let
unprivileged users know this info? I guess if version() is not
protected then this needn't be either.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2021-02-22 01:21:33 | Re: Hybrid Hash/Nested Loop joins and caching results from subplans |
Previous Message | Euler Taveira | 2021-02-22 00:27:29 | Re: Catalog version access |