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.
