|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||Michael Banck <michael(dot)banck(at)credativ(dot)de>|
|Cc:||Magnus Hagander <magnus(at)hagander(dot)net>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Sergei Kornilov <sk(at)zsrv(dot)org>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Offline enabling/disabling of data checksums|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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 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
- 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?
|Next Message||Michael Paquier||2019-03-15 03:00:41||Re: Offline enabling/disabling of data checksums|
|Previous Message||Tsunakawa, Takayuki||2019-03-15 02:23:48||RE: Timeout parameters|