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
signature.asc
Description: PGP signature
