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

From Michael Paquier
Subject Re: Offline enabling/disabling of data checksums
Date
Msg-id 20190315025027.GN3493@paquier.xyz
Whole thread Raw
In response to Re: Offline enabling/disabling of data checksums  (Michael Banck <michael.banck@credativ.de>)
Responses Re: Offline enabling/disabling of data checksums
Re: Offline enabling/disabling of data checksums
Re: Offline enabling/disabling of data checksums
List pgsql-hackers
On Thu, Mar 14, 2019 at 04:26:20PM +0100, Michael Banck wrote:
> Am Donnerstag, den 14.03.2019, 15:26 +0100 schrieb Magnus Hagander:
>> One big-hammer method could be similar to what pg_upgrade does --
>> temporarily rename away the controlfile so postgresql can't start, and
>> when done, put it back.
>
> That sounds like a good solution to me. I've made PoC patch for that,
> see attached.

Indeed.  I did not know this trick from pg_upgrade.  We could just use
the same.

> The only question is whether pg_checksums should try to move pg_control
> back (i) on failure (ii) when interrupted?

Yes, we should have a callback on SIGINT and SIGTERM here which just
moves back in place the control file if the temporary one exists.  I
have been able to grab some time to incorporate the feedback gathered
on this thread, and please find attached a new version of the patch to
add --enable/--disable.  The main changes are:
- When enabling checksums, fsync first the data directory, and at the
end then update/flush the control file and its parent folder as Fabien
has reported.
- When disabling checksums, only work on the control file, as Fabien
has also reported.
- Rename the control file when beginning the enabling operation, with
a callback to rename the file back if the operation is interrupted.

Does this make sense?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: "Tsunakawa, Takayuki"
Date:
Subject: RE: Timeout parameters
Next
From: Michael Paquier
Date:
Subject: Re: Offline enabling/disabling of data checksums