| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Michael Banck <michael(dot)banck(at)credativ(dot)de> |
| Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Andres Freund <andres(at)anarazel(dot)de>, Magnus Hagander <magnus(at)hagander(dot)net>, Sergei Kornilov <sk(at)zsrv(dot)org>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Offline enabling/disabling of data checksums |
| Date: | 2019-03-22 10:39:26 |
| Message-ID: | 20190322103926.GY20192@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Mar 22, 2019 at 10:04:02AM +0100, Michael Banck wrote:
> How about this:
>
> + <refsect1>
> + <title>Notes</title>
> + <para>
> + When enabling checksums in a cluster, the operation can potentially take a
> + long time if the data directory is large. During this operation, the
> + cluster or other programs that write to the data directory must not be
> + started or else data-loss will occur.
> + </para>
Sounds fine to me. Will add an extra paragraph on that.
> Maybe it could be formulated like "If pg_checksums is aborted or killed
> in its operation while enabling or disabling checksums, the cluster
> will have the same state with respect of checksums as before the
> operation and pg_checksums needs to be restarted."?
We could use that as well. With the current patch, and per the
suggestions from Fabien, this holds true as the control file is
updated and flushed last.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Petr Jelinek | 2019-03-22 11:17:43 | Re: Special role for subscriptions |
| Previous Message | David Rowley | 2019-03-22 10:38:32 | Re: Performance issue in foreign-key-aware join estimation |