On Wed, Oct 26, 2022 at 01:41:12PM +0530, Bharath Rupireddy wrote:
> We will have bigger problems when a backend corrupts the pg_control
> file, no? The bigger problems could be that the server won't come up
> or it behaves abnormally or some other.
Possibly, yes.
> Can't the CRC check detect any of the above corruptions? Do we have
> any evidence of backend corrupting the pg_control file or any of the
> above variables while running regression tests?
It could be possible that the backend writes an incorrect data
combination though its APIs, where the CRC is correct but the data is
not (say a TLI of 0, as one example).
> If the concern is backend corrupting the pg_control file and CRC check
> can't detect it, then the extra checks (as proposed in the patch) must
> be placed within the core (perhaps before writing/after reading the
> pg_control file), not in regression tests for sure.
Well, that depends on the level of protection you want. Now there are
things in place already when it comes to recovery or at startup.
Anyway, the recent experience with the 56-bit relfilenode thread is
really that we don't check the execution of these functions at all,
and that's the actual minimal requirement, so I have applied a patch
based on count(*) > 0 for now to cover that. I am not sure if any of
the checks for the control file fields are valuable, perhaps some
are..
--
Michael
