Re: Offline enabling/disabling of data checksums

On Wed, Mar 13, 2019 at 4:51 PM Michael Banck <michael(dot)banck(at)credativ(dot)de>
wrote:

> Hi,
>
> Am Mittwoch, den 13.03.2019, 12:43 +0100 schrieb Magnus Hagander:
> > I think this is dangerous enough that it needs to be enforced and not
> > documented.
>
> Changing the cluster ID might have some other side-effects, I think
> there are several cloud-native 3rd party solutions that use the cluster
> ID as some kind of unique identifier for an instance. It might not be an
> issue in practise, but then again, it might break other stuff down the
> road.
>

Well, whatever we do they have to update, right? If we're not changing it,
then we're basically saying that it's (systemid, checksums) that is the
identifier of the cluster, not just systemid. They'd have to go around and
check each node individually for the configuration and not just use
systemid anyway, so what's the actual win?

Another possibility would be to extend the replication protocol's
> IDENTIFY_SYSTEM command to also report the checksum version so that the
> standby can check against the local control file on startup. But I am
> not sure we can easily extend IDENTIFY_SYSTEM this way nor whether we
> should for this rather corner-casey thing?
>

We could, but is it really a win in those scenarios? Vs just making the
systemid different? With systemid being different it's obvious that
something needs to be done. If it's not then at the best, if we check it in
the standby startup, the standby won't start. But people can still end up
with things like unusuable/corrupt backups for example.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>