11.2版本 补充原文修改 wal.sgml

Author: Steve888888

postgresql/doc/src/sgml/wal.sgml

@@ -25,7 +25,7 @@ ____________________________________________________________________________-->
 <!--==========================orignal english content==========================
   <para>
    Reliability is an important property of any serious database
-   system, and <productname>PostgreSQL</> does everything possible to
+   system, and <productname>PostgreSQL</productname> does everything possible to
    guarantee reliable operation. One aspect of reliable operation is
    that all data recorded by a committed transaction should be stored
    in a nonvolatile area that is safe from power loss, operating
@@ -51,8 +51,8 @@ ____________________________________________________________________________-->
    First, there is the operating system's buffer cache, which caches
    frequently requested disk blocks and combines disk writes. Fortunately,
    all operating systems give applications a way to force writes from
-   the buffer cache to disk, and <productname>PostgreSQL</> uses those
-   features.  (See the <xref linkend="guc-wal-sync-method"> parameter
+   the buffer cache to disk, and <productname>PostgreSQL</productname> uses those
+   features.  (See the <xref linkend="guc-wal-sync-method"/> parameter
    to adjust how this is done.)
   </para>
 ____________________________________________________________________________-->
@@ -63,14 +63,14 @@ ____________________________________________________________________________-->
 <!--==========================orignal english content==========================
   <para>
    Next, there might be a cache in the disk drive controller; this is
-   particularly common on <acronym>RAID</> controller cards. Some of
-   these caches are <firstterm>write-through</>, meaning writes are sent
+   particularly common on <acronym>RAID</acronym> controller cards. Some of
+   these caches are <firstterm>write-through</firstterm>, meaning writes are sent
    to the drive as soon as they arrive. Others are
-   <firstterm>write-back</>, meaning data is sent to the drive at
+   <firstterm>write-back</firstterm>, meaning data is sent to the drive at
    some later time. Such caches can be a reliability hazard because the
    memory in the disk controller cache is volatile, and will lose its
    contents in a power failure.  Better controller cards have
-   <firstterm>battery-backup units</> (<acronym>BBU</>s), meaning
+   <firstterm>battery-backup units</firstterm> (<acronym>BBU</acronym>s), meaning
    the card has a battery that
    maintains power to the cache in case of system power loss.  After power
    is restored the data will be written to the disk drives.
@@ -1083,13 +1083,12 @@ ____________________________________________________________________________-->
    <acronym>WAL</acronym> logs are stored in the directory
    <filename>pg_wal</filename> under the data directory, as a set of
    segment files, normally each 16 MB in size (but the size can be changed
-   by altering the <option>-&minus;with-wal-segsize</> configure option when
-   building the server).  Each segment is divided into pages, normally
-   8 kB each (this size can be changed via the <option>-&minus;with-wal-blocksize</>
-   configure option).  The log record headers are described in
-   <filename>access/xlogrecord.h</filename>; the record content is dependent
-   on the type of event that is being logged.  Segment files are given
-   ever-increasing numbers as names, starting at
+   by altering the <option>-&minus;with-wal-segsize</> initdb option).  Each segment is
+   divided into pages, normally 8 kB each (this size can be changed via the
+   <option>-&minus;with-wal-blocksize</> configure option).  The log record headers
+   are described in <filename>access/xlogrecord.h</filename>; the record
+   content is dependent on the type of event that is being logged.  Segment
+   files are given ever-increasing numbers as names, starting at
    <filename>000000010000000000000000</filename>.  The numbers do not wrap,
    but it will take a very, very long time to exhaust the
    available stock of numbers.