Re: Offline enabling/disabling of data checksums
От | Magnus Hagander |
---|---|
Тема | Re: Offline enabling/disabling of data checksums |
Дата | |
Msg-id | CABUevExnUEaCafeswWU_MK4WmY10EDQ-kjPTj3i_Eb=AOJgOOA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Offline enabling/disabling of data checksums (Sergei Kornilov <sk@zsrv.org>) |
Ответы |
Re: Offline enabling/disabling of data checksums
|
Список | pgsql-hackers |
On Wed, Mar 13, 2019 at 12:40 PM Sergei Kornilov <sk@zsrv.org> wrote:
Hi
>> One new question from me: how about replication?
>> Case: primary+replica, we shut down primary and enable checksum, and "started streaming WAL from primary" without any issue. I have master with checksums, but replica without.
>> Or cluster with checksums, then disable checksums on primary, but standby think we have checksums.
>
> Enabling or disabling the checksums offline on the master quite clearly requires a rebuild of the standby, there is no other way (this is one of the reasons for the online enabling in that patch, so I still hope we can get that done -- but not for this version).
I mean this should be at least documented.
Change system id... Maybe is reasonable
I think this is dangerous enough that it needs to be enforced and not documented.
Most people who care about checksums are also going to be having either replication or backup...
>> Also we support ./configure --with-blocksize=(not equals 8)? make check on HEAD fails for me. If we support this - i think we need recheck BLCKSZ between compiled pg_checksum and used in PGDATA
>
> You mean if the backend and pg_checksums is built with different blocksize? Yeah, that sounds like something which is a cheap check and should be done.
Yep
This one I could more live with it only being a documented problem rather than enforced, but it also seems very simple to enforce.
В списке pgsql-hackers по дате отправления: