Re: Offline enabling/disabling of data checksums

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Offline enabling/disabling of data checksums
Дата
Msg-id 20181227011534.GD2106@paquier.xyz
обсуждение исходный текст
Ответ на Re: Offline enabling/disabling of data checksums  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: Offline enabling/disabling of data checksums  (Fabien COELHO <coelho@cri.ensmp.fr>)
Re: Offline enabling/disabling of data checksums  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-hackers
On Wed, Dec 26, 2018 at 07:43:17PM +0100, Fabien COELHO wrote:
>> It adds an (now mandatory) --action parameter that takes either verify,
>> enable or disable as argument.
>
> I'd rather have explicit switches for verify, enable & disable, and verify
> would be the default if none is provided.

Okay, noted for the separate switches.  But I don't agree with the
point of assuming that --verify should be enforced if no switches are
defined.  That feels like a trap for newcomers of this tool..

> For enable/disable, while the command is running, it should mark the cluster
> as opened to prevent an unwanted database start. I do not see where this is
> done.

You have pretty much the same class of problems if you attempt to
start a cluster on which pg_rewind or the existing pg_verify_checksums
is run after these have scanned the control file to make sure that
they work on a cleanly-stopped instance.  In short, this is a deal
between code simplicity and trying to have the tool outsmart users in
the way users use the tool.  I tend to prefer keeping the code simple
and not worry about cases where the users mess up with their
application, as there are many more things which could go wrong.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pgsql: Fix failure to check for open() or fsync() failures.
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: random() (was Re: New GUC to sample log queries)