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