|From:||Fabien COELHO <fabien(dot)coelho(at)mines-paristech(dot)fr>|
|To:||Michael Paquier <michael(at)paquier(dot)xyz>|
|Cc:||Michael Banck <michael(dot)banck(at)credativ(dot)de>, Postgres hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Offline enabling/disabling of data checksums|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Here is a partial review:
> - 0001 if a patch to refactor the routine for the control file
> update. I have made it backend-aware, and we ought to be careful with
> error handling, use of fds and such, something that v4 was not very
> careful about.
This refactoring patch is ok for me: applies, compiles, check is ok.
However, Am I right in thinking that the change should propagate to other
tools which manipulate the control file, eg pg_resetwal, postmaster… So
that there would be only one shared API to update the control file?
> - 0002 renames pg_verify_checksums to pg_checksums with a
> straight-forward switch. Docs as well as all references to
> pg_verify_checksums are updated.
Looks ok to me. Applies, compiles, checks are ok. Doc build is ok.
I'm wondering whether there should be something done so that the
inter-release documentation navigation works? Should the section keep the
former name? Is it managed by hand somewhere else? Maybe it would require
to keep the refsect1 id, or to duplicate it, not sure.
In "doc/src/sgml/ref/allfiles.sgml" there seems to be a habit to align on
the SYSTEM keyword, which is not fellowed by the patch.
> - 0003 adds the new options --check, --enable and --disable, with
> --check being the default as discussed.
Looks like the patch I already reviewed, but I'll look at it in details
"If enabling or disabling checksums, the exit status is nonzero if the
+ if (ControlFile->data_checksum_version == 0 &&
+ action == PG_ACTION_DISABLE)
+ fprintf(stderr, _("%s: data checksums are already disabled in cluster.\n"), progname);
This seem contradictory to me: you want to disable checksum, and they are
already disabled, so nothing is needed. How does that qualifies as a
Further review will come later.
> - 0004 adds a -N/--no-sync which I think is nice for consistency with
> other tools. That's also useful for the tests, and was not discussed
> until now on this thread.
Indeed. I do not immediately see the use case where no syncing would be a
good idea. I can see why it would be a bad idea. So I'm not sure of the
|Next Message||Peter Geoghegan||2019-03-12 21:15:06||Re: Making all nbtree entries unique by having heap TIDs participate in comparisons|
|Previous Message||Sergei Kornilov||2019-03-12 20:27:47||Re: using index or check in ALTER TABLE SET NOT NULL|