Re: Offline enabling/disabling of data checksums
От | Andres Freund |
---|---|
Тема | Re: Offline enabling/disabling of data checksums |
Дата | |
Msg-id | 20190320070134.luhicba7wddqpvas@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Offline enabling/disabling of data checksums (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: Offline enabling/disabling of data checksums
|
Список | pgsql-hackers |
Hi, On 2019-03-20 07:55:39 +0100, Fabien COELHO wrote: > > 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:-) 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. > 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. That's just a separate feature. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: