1
0
mirror of https://github.com/postgres/postgres.git synced 2025-09-02 04:21:28 +03:00

Revert "Allow on-line enabling and disabling of data checksums"

This reverts the backend sides of commit 1fde38beaa.
I have, at least for now, left the pg_verify_checksums tool in place, as
this tool can be very valuable without the rest of the patch as well,
and since it's a read-only tool that only runs when the cluster is down
it should be a lot safer.
This commit is contained in:
Magnus Hagander
2018-04-09 19:02:42 +02:00
parent 03c11796a9
commit a228cc13ae
39 changed files with 34 additions and 1658 deletions

View File

@@ -230,87 +230,6 @@
</para>
</sect1>
<sect1 id="checksums">
<title>Data checksums</title>
<indexterm>
<primary>checksums</primary>
</indexterm>
<para>
Data pages are not checksum protected by default, but this can optionally be enabled for a cluster.
When enabled, each data page will be assigned a checksum that is updated when the page is
written and verified every time the page is read. Only data pages are protected by checksums,
internal data structures and temporary files are not.
</para>
<para>
Checksums are normally enabled when the cluster is initialized using
<link linkend="app-initdb-data-checksums"><application>initdb</application></link>. They
can also be enabled or disabled at runtime. In all cases, checksums are enabled or disabled
at the full cluster level, and cannot be specified individually for databases or tables.
</para>
<para>
The current state of checksums in the cluster can be verified by viewing the value
of the read-only configuration variable <xref linkend="guc-data-checksums" /> by
issuing the command <command>SHOW data_checksums</command>.
</para>
<para>
When attempting to recover from corrupt data it may be necessary to bypass the checksum
protection in order to recover data. To do this, temporarily set the configuration parameter
<xref linkend="guc-ignore-checksum-failure" />.
</para>
<sect2 id="checksums-enable-disable">
<title>On-line enabling of checksums</title>
<para>
Checksums can be enabled or disabled online, by calling the appropriate
<link linkend="functions-admin-checksum">functions</link>.
Disabling of checksums takes effect immediately when the function is called.
</para>
<para>
Enabling checksums will put the cluster in <literal>inprogress</literal> mode.
During this time, checksums will be written but not verified. In addition to
this, a background worker process is started that enables checksums on all
existing data in the cluster. Once this worker has completed processing all
databases in the cluster, the checksum mode will automatically switch to
<literal>on</literal>.
</para>
<para>
The process will initially wait for all open transactions to finish before
it starts, so that it can be certain that there are no tables that have been
created inside a transaction that has not committed yet and thus would not
be visible to the process enabling checksums. It will also, for each database,
wait for all pre-existing temporary tables to get removed before it finishes.
If long-lived temporary tables are used in the application it may be necessary
to terminate these application connections to allow the process to complete.
Information about open transactions and connections with temporary tables is
written to log.
</para>
<para>
If the cluster is stopped while in <literal>inprogress</literal> mode, for
any reason, then this process must be restarted manually. To do this,
re-execute the function <function>pg_enable_data_checksums()</function>
once the cluster has been restarted. It is not possible to resume the work,
the process has to start over and re-process the cluster.
</para>
<note>
<para>
Enabling checksums can cause significant I/O to the system, as most of the
database pages will need to be rewritten, and will be written both to the
data files and the WAL.
</para>
</note>
</sect2>
</sect1>
<sect1 id="wal-intro">
<title>Write-Ahead Logging (<acronym>WAL</acronym>)</title>