From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Michael Banck <michael(dot)banck(at)credativ(dot)de>, Postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Offline enabling/disabling of data checksums |
Date: | 2019-03-13 06:18:32 |
Message-ID: | alpine.DEB.2.21.1903130713260.4059@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bonjour Michaël,
> Yes, that would be nice, for now I have focused. For pg_resetwal yes
> we could do it easily. Would you like to send a patch?
I probably can do that before next Monday. I'll prioritize reviewing the
latest instance of this patch, though.
>> This seem contradictory to me: you want to disable checksum, and they are
>> already disabled, so nothing is needed. How does that qualifies as a
>> "failed" operation?
>
> If the operation is automated, then a proper reaction can be done if
> multiple attempts are done. Of course, I am fine to tune things one
> way or the other depending on the opinion of the crowd here. From the
> opinions gathered, I can see that (Michael * 2) prefer failing with
> exit(1), while (Fabien * 1) would like to just do exit(0).
Yep, that sums it up:-).
>> Indeed. I do not immediately see the use case where no syncing would be a
>> good idea. I can see why it would be a bad idea. So I'm not sure of the
>> concept.
>
> To leverage the buildfarm effort I think this one is worth it. Or we
> finish to fsync the data folder a couple of times, which would make
> the small-ish buildfarm machines suffer more than they need.
Ok for the particular use-case, provided that the documentation is very
clear about the risks, which is the case, so fine with me wrt to the
feature.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-03-13 06:19:23 | Re: [PATCH] remove repetitive characters in fdwhandler.sgml |
Previous Message | Amit Langote | 2019-03-13 06:17:47 | Re: BUG #15668: Server crash in transformPartitionRangeBounds |