Re: Offline enabling/disabling of data checksums
Fabien COELHO <coelho@cri.ensmp.fr>
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Michael Paquier <michael@paquier.xyz>
Cc: Michael Banck <michael.banck@credativ.de>,
Postgres hackers <pgsql-hackers@postgresql.org>
Date: 2018-12-27T08:52:31Z
Lists: pgsql-hackers
Bonjour Michaël, >>> It adds an (now mandatory) --action parameter that takes either verify, >>> enable or disable as argument. >> >> I'd rather have explicit switches for verify, enable & disable, and verify >> would be the default if none is provided. > > Okay, noted for the separate switches. But I don't agree with the > point of assuming that --verify should be enforced if no switches are > defined. That feels like a trap for newcomers of this tool.. Hmmm. It does something safe and useful, especially if it also works online (patch pending), and the initial tool only does checking. However, I'd be okay for no default. >> For enable/disable, while the command is running, it should mark the cluster >> as opened to prevent an unwanted database start. I do not see where this is >> done. > > You have pretty much the same class of problems if you attempt to > start a cluster on which pg_rewind or the existing pg_verify_checksums > is run after these have scanned the control file to make sure that > they work on a cleanly-stopped instance. In short, this is a deal > between code simplicity and trying to have the tool outsmart users in > the way users use the tool. I tend to prefer keeping the code simple > and not worry about cases where the users mess up with their > application, as there are many more things which could go wrong. Hmmm. I do not buy the comparison. A verify that fails is not a big problem, you can run it again. If pg_rewind fails, you can probably run it again as well, the source is probably still consistent even if it has changed, and too bad for the target side, but it was scheduled to be overwritten anyway. However, a tool which overwrites files beyond the back of a running server is a recipee for data-loss, so I think it should take much more care, i.e. set the server state into some specific safe state. About code simplicity: probably there is, or there should be, a change-the-state function somewhere, because quite a few tools could use it? -- Fabien.
Commits
-
Reorganize Notes section in documentation of pg_checksums
- a7cc52370b2b 12.0 landed
-
Add option -N/--no-sync to pg_checksums
- e0090c869008 12.0 landed
-
Add options to enable and disable checksums in pg_checksums
- ed308d783790 12.0 landed
-
Refactor more code logic to update the control file
- 8b938d36f744 12.0 landed
-
Rename pg_verify_checksums to pg_checksums
- 6dd263cfaa84 12.0 landed
-
Fix cross-version compatibility checks of pg_verify_checksums
- 501f58359b59 11.3 landed
- c9ae7f704c67 12.0 landed
-
Add routine able to update the control file to src/common/
- ce6afc6823fb 12.0 landed