On Fri, Dec 21, 2018 at 09:16:16PM +0100, Michael Banck wrote: > It adds an (now mandatory) --action parameter that takes either verify, > enable or disable as argument.
There are two discussion points which deserve attention here: 1) Do we want to rename pg_verify_checksums to something else, like pg_checksums. I like a lot if we would do a simple renaming of the tool, which should be the first step taken. 2) Which kind of interface do we want to use? When I did my own flavor of pg_checksums, I used an --action switch able to use the following values: - enable - disable - verify The switch cannot be specified twice (perhaps we could enforce the last value as other binaries do in the tree, not sure if that's adapted here). A second type of interface is to use one switch per action. For both interfaces if no action is specify then the tool fails. Vote is open. > This is basically meant as a stop-gap measure in case online activation > of checksums won't make it for v12, but maybe it is independently > useful? I think that this is independently useful, I got this stuff part of an upgrade workflow where the user is ready to accept some extra one-time offline time so as checksums are enabled. > Things I have not done so far: > > 1. Rename pg_verify_checksums to e.g. pg_checksums as it will no longer > only verify checksums. Check. That sounds right to me. > 2. Rename the scan_* functions (Michael renamed them to operate_file and > operate_directory but I am not sure it is worth it. The renaming makes sense, as scan implies only reading while enabling checksums causes a write. > 3. Once that patch is in, there would be a way to disable checksums so > there'd be a case to also change the initdb default to enabled, but that > required further discussion (and maybe another round of benchmarks). Perhaps, that's unrelated to this thread though. I am not sure that all users would be ready to pay the extra cost of checksums enabled by default. -- Michael
signature.asc
Description: PGP signature
