Re: Offline enabling/disabling of data checksums

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Offline enabling/disabling of data checksums
Дата
Msg-id CABUevEwCbzgmvOaYN+ZnmVQrgCX1jS75nUS2_CGtF0pSLnY6GQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Offline enabling/disabling of data checksums  (Christoph Berg <myon@debian.org>)
Ответы Re: Offline enabling/disabling of data checksums
Список pgsql-hackers


On Thu, Mar 14, 2019 at 3:28 PM Christoph Berg <myon@debian.org> wrote:
Re: Magnus Hagander 2019-03-14 <CABUevEx7QZLOjWDvwTdm1VM+mjsDm7=ZmB8qck7nDmcHEY5O5g@mail.gmail.com>
> Are you suggesting we should support running with a master with checksums
> on and a standby with checksums off in the same cluster? That seems.. Very
> fragile.

The case "shut down master and standby, run pg_checksums on both, and
start them again" should be supported. That seems safe to do, and a
real-world use case.

I can agree with that, if we can declare it safe. You might need some way to ensure it was shut down cleanly on both sides, I'm guessing. 


Changing the system id to a random number would complicate this.

(Horrible idea: maybe just adding 1 (= checksum version) to the system
id would work?)

Or any other way of changing the systemid in a predictable way would also work, right? As long as it's done the same on both sides. And that way it would look different to any system that *doesn't* know what it means, which is probably a good thing.

--

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

Предыдущее
От: Christoph Berg
Дата:
Сообщение: Re: Offline enabling/disabling of data checksums
Следующее
От: tushar
Дата:
Сообщение: [sqlsmith] Failed assertion at relnode.c