通过脚本更新全体注释

Author: ChenHuajun

postgresql/doc/src/sgml/amcheck.sgml

@@ -217,7 +217,8 @@ ____________________________________________________________________________-->
       structure.  When the optional <parameter>rootdescend</parameter>
       argument is <literal>true</literal>, verification re-finds
       tuples on the leaf level by performing a new search from the
-      root page for each tuple.  The checks that can be performed by      <function>bt_index_parent_check</function> are a superset of the
+      root page for each tuple.  The checks that can be performed by
+      <function>bt_index_parent_check</function> are a superset of the
       checks that can be performed by <function>bt_index_check</function>.
       <function>bt_index_parent_check</function> can be thought of as
       a more thorough variant of <function>bt_index_check</function>:

postgresql/doc/src/sgml/arch-dev.sgml

@@ -179,7 +179,7 @@ ____________________________________________________________________________-->
 
   <sect1 id="connect-estab">
 <!--==========================orignal english content==========================
-   <title>How Connections are Established</title>
+   <title>How Connections Are Established</title>
 ____________________________________________________________________________-->
    <title>连接如何建立</title>
 

postgresql/doc/src/sgml/backup.sgml

@@ -2046,7 +2046,7 @@ ____________________________________________________________________________-->
    <para>
     The key part of all this is to set up a recovery configuration that
     describes how you want to recover and how far the recovery should
-    run.   The one thing that you absolutely must specify is the <varname>restore_command</varname>,
+    run.  The one thing that you absolutely must specify is the <varname>restore_command</varname>,
     which tells <productname>PostgreSQL</productname> how to retrieve archived
     WAL file segments.  Like the <varname>archive_command</varname>, this is
     a shell command string.  It can contain <literal>%f</literal>, which is
@@ -2284,7 +2284,7 @@ ____________________________________________________________________________-->
     that was current when the base backup was taken.  If you wish to recover
     into some child timeline (that is, you want to return to some state that
     was itself generated after a recovery attempt), you need to specify the
-    target timeline ID in <xref linkend="guc-recovery-target-timeline"/>.  You cannot recover into
+    target timeline ID in <xref linkend="guc-recovery-target-timeline"/>. You cannot recover into
     timelines that branched off earlier than the base backup.
    </para>
 ____________________________________________________________________________-->

postgresql/doc/src/sgml/bki.sgml

@@ -586,18 +586,65 @@ ____________________________________________________________________________-->
     要为一个新的预装载行找到一个可用的OID，可以运行脚本<filename>src/include/catalog/unused_oids</filename>。它能打印出未被使用的OID的闭区间范围（例如，输出行<quote>45-900</quote>表示OID 45到900都还没有被分配出去）。当前，OID 1-9999被保留给手工分配，<filename>unused_oids</filename>脚本会简单地查看目录头部以及<filename>.dat</filename>文件来看看哪些OID没有出现。也可以使用<filename>duplicate_oids</filename>脚本来检查错误（<filename>genbki.pl</filename>将为没有手工分配给他们的任何行分配OID，还会在编译时检测重复的OID）。
    </para>
 
+<!--==========================orignal english content==========================
+   <para>
+    When choosing OIDs for a patch that is not expected to be committed
+    immediately, best practice is to use a group of more-or-less
+    consecutive OIDs starting with some random choice in the range
+    8000&mdash;9999.  This minimizes the risk of OID collisions with other
+    patches being developed concurrently.  To keep the 8000&mdash;9999
+    range free for development purposes, after a patch has been committed
+    to the master git repository its OIDs should be renumbered into
+    available space below that range.  Typically, this will be done
+    near the end of each development cycle, moving all OIDs consumed by
+    patches committed in that cycle at the same time.  The script
+    <filename>renumber_oids.pl</filename> can be used for this purpose.
+    If an uncommitted patch is found to have OID conflicts with some
+    recently-committed patch, <filename>renumber_oids.pl</filename> may
+    also be useful for recovering from that situation.
+   </para>
+____________________________________________________________________________-->
    <para>
     在为一个不会立即提交的补丁选择OID时，最佳实践是使用一组接近连续的OID，以8000&mdash;9999范围中随机选择的值作为开始。这样就将其与其他同时开发的补丁的冲突的风险降至最低。为了保持8000&mdash;9999范围对于开发来讲可自由使用，在补丁提交到git库之后，应使用低于该范围的可用空间重新编号。通常这项工作会在接近每次开发周期的尾声时做，与此同时移动由该周期提交的补丁所消费掉的所有OID。<filename>renumber_oids.pl</filename>脚本可用来完成该项工作。如果发现一个未提交的补丁与一些近来提交的补丁有OID冲突，<filename>renumber_oids.pl</filename>也可用于从此状况下的恢复。
    </para>
 
+<!--==========================orignal english content==========================
+   <para>
+    Because of this convention of possibly renumbering OIDs assigned by
+    patches, the OIDs assigned by a patch should not be considered stable
+    until the patch has been included in an official release.  We do not
+    change manually-assigned object OIDs once released, however, as that
+    would create assorted compatibility problems.
+   </para>
+____________________________________________________________________________-->
    <para>
     因为此约定可能会对补丁程序分配的OID重新编号，在补丁纳入到官方发布版本之前，补丁所分配的OID不应该认为是稳定的。一旦发布，我们并不修改手工分配的对象OID，但是那样会产生各种各样的兼容性问题。
    </para>
 
+<!--==========================orignal english content==========================
+   <para>
+    If <filename>genbki.pl</filename> needs to assign an OID to a catalog
+    entry that does not have a manually-assigned OID, it will use a value in
+    the range 10000&mdash;11999.  The server's OID counter is set to 12000
+    at the start of a bootstrap run.  Thus objects created by regular SQL
+    commands during the later phases of bootstrap, such as objects created
+    while running the <filename>information_schema.sql</filename> script,
+    receive OIDs of 12000 or above.
+   </para>
+____________________________________________________________________________-->
    <para>
     如果需要为没有手工分配的OID的目录条目分配OID，<filename>genbki.pl</filename>将使用10000&mdash;11999范围内的值。在自举运行的开始，服务器的OID计数器设置为12000 。这样自举的后期由SQL命令创建的对象，例如运行<filename>information_schema.sql</filename>脚本时创建的对象，接收的OID为12000或更高。
    </para>
 
+<!--==========================orignal english content==========================
+   <para>
+    OIDs assigned during normal database operation are constrained to be
+    16384 or higher.  This ensures that the range 10000&mdash;16383 is free
+    for OIDs assigned automatically by <filename>genbki.pl</filename> or
+    during bootstrap.  These automatically-assigned OIDs are not considered
+    stable, and may change from one installation to another.
+   </para>
+____________________________________________________________________________-->
    <para>
     在正常数据库操作期间分配的OID限制为16384或更高。这样确保对于<filename>genbki.pl</filename>自动分配或自举过程中的OID可以使用范围10000&mdash;16383内的值 。这些自动分配的OID不稳定，从一种安装到另一安装可能会改变。
    </para>
@@ -1153,7 +1200,6 @@ ____________________________________________________________________________-->
      <replaceable class="parameter">tableoid</replaceable>
      <optional><literal>bootstrap</literal></optional>
      <optional><literal>shared_relation</literal></optional>
-     <optional><literal>without_oids</literal></optional>
      <optional><literal>rowtype_oid</literal> <replaceable>oid</replaceable></optional>
      (<replaceable class="parameter">name1</replaceable> =
      <replaceable class="parameter">type1</replaceable>

postgresql/doc/src/sgml/btree.sgml

@@ -465,7 +465,7 @@ returns bool
 <!--==========================orignal english content==========================
  <para>
   The essential semantics of an <function>in_range</function> function
-  depend on the two boolean flag parameters.  It should add or
+  depend on the two Boolean flag parameters.  It should add or
   subtract <replaceable>base</replaceable>
   and <replaceable>offset</replaceable>, then
   compare <replaceable>val</replaceable> to the result, as follows: