|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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
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?
|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|