Hi, On 2021-02-21 19:54:01 -0500, Tom Lane wrote: > Vik Fearing <v...@postgresfriends.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.
Could you elaborate a bit? > If we're going to bother with providing a way > to get this info, we should make it possible to ask the running server. In Vik's case there is no running server to ask, IIUC. He has an existing cluster running an "old" set of binaries, and a set of binaries. He wants to know if he needs to pg_upgrade, or can start from a basebackup. The old version he can get from pg_controldata, or the catalog. But except for initdb'ing a throw-away cluster, there's no way to get that for the new cluster that doesn't involve grepping headers... > (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.) I don't see a reason it'd need to be protected. Furthermore, the ship has sailed: SELECT catalog_version_no FROM pg_control_system(); Greetings, Andres Freund
