| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
| Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Vik Fearing <vik(at)postgresfriends(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Catalog version access |
| Date: | 2022-01-31 07:57:13 |
| Message-ID: | YfeWWfUB8Z5cB3Pi@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jan 25, 2022 at 01:12:32PM +0900, Michael Paquier wrote:
> Once you remove the requirement of a running server, we have basically
> what has been recently implemented with postgres -C for
> runtime-computed GUCs, because we already go through a read of the
> control file to be able to print those GUCs with their correct
> values. This also means that it is already possible to check if a
> data folder is compatible with a set of binaries with this facility,
> as any postgres -C command with a runtime GUC would trigger this
> check. Using any of the existing runtime GUCs may be confusing, but
> that would work. And I am not really convinced that we have any need
> to add a specific GUC for this purpose, be it a sort of
> is_controlfile_valid or controlfile_checksum (CRC32 of the control
> file).
Thinking more about this one, we can already do that, so I have
marked the patch as RwF. Perhaps we could just add a GUC, but that
feels a bit dummy.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2022-01-31 08:15:33 | Re: drop tablespace failed when location contains .. on win32 |
| Previous Message | Bharath Rupireddy | 2022-01-31 07:41:57 | Re: Is there a way (except from server logs) to know the kind of on-going/last checkpoint? |