From: Michael Banck <michael.banck@credativ.de>
To: Michael Paquier <michael@paquier.xyz>
Cc: Postgres hackers <pgsql-hackers@postgresql.org>
Subject: Re: Offline enabling/disabling of data checksums
Date: Sat, 22 Dec 2018 14:42:55 +0100
Message-ID: <20181222134255.GE4974@nighthawk.caipicrew.dd-dns.de> (raw)
In-Reply-To: <20181221232834.GB1948@paquier.xyz>
References: <20181221201616.GD4974@nighthawk.caipicrew.dd-dns.de>
<20181221232834.GB1948@paquier.xyz>
Hi,
I have added it to the commitfest now:
https://commitfest.postgresql.org/21/1944/
On Sat, Dec 22, 2018 at 08:28:34AM +0900, Michael Paquier wrote:
> 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.
I am for it, but don't mind whether it's before or afterwards, your
call.
> 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.
Even though my fork has the separate switches, I like the --action one.
On the other hand, it is a bit more typing as you always have to spell
out the action (is there precendent of accepting also incomplete option
arguments like 'v', 'e', 'd'?).
> > 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.
OK; we have also used that at clients - if the instance has a size of
less than a few dozen GBs, enabling checksums during a routine minor
upgrade restart is not delaying things much.
> > 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.
Ok, will do in the next version.
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax: +49 2166 9901-100
Email: michael.banck@credativ.de
credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
Unser Umgang mit personenbezogenen Daten unterliegt
folgenden Bestimmungen: https://www.credativ.de/datenschutz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: michael.banck@credativ.de, michael@paquier.xyz
Subject: Re: Offline enabling/disabling of data checksums
In-Reply-To: <20181222134255.GE4974@nighthawk.caipicrew.dd-dns.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox