Offline enabling/disabling of data checksums - Mailing list pgsql-hackers

From Michael Banck
Subject Offline enabling/disabling of data checksums
Date
Msg-id 20181221201616.GD4974@nighthawk.caipicrew.dd-dns.de
Whole thread Raw
Responses Re: Offline enabling/disabling of data checksums  (Michael Paquier <michael@paquier.xyz>)
Re: Offline enabling/disabling of data checksums  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
Hi,

the attached patch adds offline enabling/disabling of checksums to
pg_verify_checksums. It is based on independent work both Michael
(Paquier) and me did earlier this year and takes changes from both, see
https://github.com/credativ/pg_checksums and
https://github.com/michaelpq/pg_plugins/tree/master/pg_checksums

It adds an (now mandatory) --action parameter that takes either verify,
enable or disable as argument.

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?

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.

2. Rename the scan_* functions (Michael renamed them to operate_file and
operate_directory but I am not sure it is worth it.

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).


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

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Compiling on Termux
Next
From: David Rowley
Date:
Subject: Re: Performance issue in foreign-key-aware join estimation