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 08:00:54
Message-ID: alpine.DEB.2.21.1903200838180.24709@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hallo Andres,

>> [...]
>
> pg_upgrade in link mode intentionally wants to *permanently* disable a
> cluster. And it explicitly writes a log message about it. That's not a
> case to draw inferrence for this case.

Ok. My light knowledge of pg_upgrade inner working does not extend to this
level of precision.

>> I'd be okay with anything that works consistently accross all commands
>> [...]
>>
>> 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.
>
> That's just a separate feature.

Possibly, although I'm not sure what in the above is a "separate feature",
I assume from the "pg_checksum --enable" implementation.

Is it the fact that there could (should, IMO) be some mechanisms to ensure
that mutually exclusive direct cluster-modification commands are not run
concurrently?

As "pg_checksums -e" is a potentially long running command, the likelyhood
of self-inflected wounds is raised significantly: I could do absurd things
on an enable-checksum-in-progress cluster on a previous version of the
patch. Thus as a reviewer I'm suggesting to fix the issue.

Or is it the fact that fixing on some critical errors would possibly
involve some manual intervention at some point?

Or is it something else?

--
Fabien.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2019-03-20 08:17:54 Re: [HACKERS] WAL logging problem in 9.4.3?
Previous Message Peter Eisentraut 2019-03-20 07:51:39 Re: REINDEX CONCURRENTLY 2.0