Re: Offline enabling/disabling of data checksums

Bonjour Michaël,

> On Wed, Mar 20, 2019 at 05:46:32PM +0100, Fabien COELHO wrote:
>> I think that the motivation/risks should appear before the solution. "As xyz
>> ..., ...", or there at least the logical link should be outlined.
>>
>> It is not clear for me whether the following sentences, which seems specific
>> to "pg_rewind", are linked to the previous advice, which seems rather to
>> refer to streaming replication?
>
> Do you have a better idea of formulation?

I can try, but I must admit that I'm fuzzy about the actual issue. Is 
there a problem on a streaming replication with inconsistent checksum 
settings, or not?

You seem to suggest that the issue is more about how some commands or 
backup tools operate on a cluster.

I'll reread the thread carefully and will make a proposal.

> Imagine for example a primary-standby with checksums disabled: [...]

Yep, that's cool.

>> Should not disabling in reverse order be safe? the checksum are not checked
>> afterwards?
>
> I don't quite understand your comment about the ordering.  If all the 
> standbys are destroyed first, then enabling/disabling checksums happens 
> at a single place.

Sure. I was suggesting that disabling on replicated clusters is possibly 
safer, but do not know the detail of replication & checksumming with 
enough precision to be that sure about it.

>> After the reboot, some data files are not fully updated with their
>> checksums, although the controlfiles tells that they are. It should then
>> fail after a restart when a no-checksum page is loaded?
>>
>> What am I missing?
>
> Please note that we do that in other tools as well and we live fine
> with that as pg_basebackup, pg_rewind just to name two.

The fact that other commands are exposed to the same potential risk is not 
a very good argument not to fix it.

> I am not saying that it is not a problem in some cases, but I am saying 
> that this is not a problem that this patch should solve.

As solving the issue involves exchanging two lines and turning one boolean 
parameter to true, I do not see why it should not be done. Fixing the 
issue takes much less time than writing about it...

And if other commands can be improved fine with me.

> If we were to do something about that, it could make sense to make 
> fsync_pgdata() smarter so as the control file is flushed last there, or 
> define flush strategies there.

ISTM that this would not work: The control file update can only be done 
*after* the fsync to describe the cluster actual status, otherwise it is 
just a question of luck whether the cluster is corrupt on an crash while 
fsyncing. The enforced order of operation, with a barrier in between, is 
the important thing here.

-- 
Fabien.