Re: Offline enabling/disabling of data checksums
От | Michael Paquier |
---|---|
Тема | Re: Offline enabling/disabling of data checksums |
Дата | |
Msg-id | 20190319230907.GA3488@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Offline enabling/disabling of data checksums (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Offline enabling/disabling of data checksums
|
Список | pgsql-hackers |
On Tue, Mar 19, 2019 at 09:47:17AM -0700, Andres Freund wrote: > I'm not sure it needs to be this patch's responsibility to come up with > a scheme here at all however. pg_rewind, pg_resetwal, pg_upgrade all > don't really have a lockout mechanism, and it hasn't caused a ton of > problems. I think it'd be good to invent something better, but it can't > be some half assed approach that'll lead to people think their database > is gone. Amen. Take it as you wish, but that's actually what I was mentioning upthread one week ago where I argued that it is a problem, but not a problem of this patch and that this problems concerns other tools: https://www.postgresql.org/message-id/20190313093150.GE2988@paquier.xyz And then, my position has been overthrown by anybody on this thread. So I am happy to see somebody chiming in and say the same thing. Honestly, I think that what I sent last week, with a patch in its simplest form, would be enough: https://www.postgresql.org/message-id/20190313021621.GP13812@paquier.xyz In short, you keep the main feature with: - No tweaks with postmaster.pid. - Rely just on the control file indicating an instance shutdown cleanly. - No tweaks with the system ID. - No renaming of the control file. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: