From: | Sergei Kornilov <sk(at)zsrv(dot)org> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Michael Banck <michael(dot)banck(at)credativ(dot)de>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Offline enabling/disabling of data checksums |
Date: | 2019-03-13 11:40:11 |
Message-ID: | 140161552477211@iva5-84bc572481fe.qloud-c.yandex.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
>> 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
regards, Sergei
From | Date | Subject | |
---|---|---|---|
Next Message | Sergei Kornilov | 2019-03-13 11:43:39 | Re: Offline enabling/disabling of data checksums |
Previous Message | Arthur Zakirov | 2019-03-13 11:36:00 | Re: Unified logging system for command-line programs |