Re: Offline enabling/disabling of data checksums

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Michael Banck <michael(dot)banck(at)credativ(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, Magnus Hagander <magnus(at)hagander(dot)net>, 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
Date: 2019-03-20 06:55:39
Message-ID: alpine.DEB.2.21.1903200742030.24709@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hallo Andres,

> And you're basically adding it because Fabien doesn't like
> postmaster.pid and wants to invent another lockout mechanism in this
> thread.

I did not suggest to rename the control file, but as it is already done by
another command it did not look like a bad idea in itself, or at least an
already used bad idea:-)

I'd be okay with anything that works consistently accross all commands
that may touch a cluster and are mutually exclusive (postmater, pg_rewind,
pg_resetwal, pg_upgrade, pg_checksums…), without underlying race
conditions. It could be locking, a control file state, a special file
(which one ? what is the procedure to create/remove it safely and avoid
potential race conditions ?), possibly "postmaster.pid", whatever really.

I'll admit that I'm moderately enthousiastic about "posmaster.pid" because
it does not do anymore what the file names says, but if it really works
and is used consistently by all commands, why not. In case of unexpected
problems, the file will probably have to be removed/fixed by hand. I also
think that the implemented mechanism should be made available in
"control_utils.c", not duplicated in every command.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-03-20 07:01:34 Re: Offline enabling/disabling of data checksums
Previous Message Iwata, Aya 2019-03-20 06:15:38 RE: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead