diff --git a/postgresql/doc/src/sgml/maintenance.sgml b/postgresql/doc/src/sgml/maintenance.sgml
index 83a8e303..8aa9d22c 100644
--- a/postgresql/doc/src/sgml/maintenance.sgml
+++ b/postgresql/doc/src/sgml/maintenance.sgml
@@ -55,7 +55,7 @@ ________________________________________________________-->
   </para>
 ________________________________________________________-->
   <para>
-   一个显而易见的维护任务是定期创建数据的后备拷贝。如果没有一个最近的备份，你就不可能在灾难（磁盘失败、或在、错误地删除一个关键表等）后进行恢复。<productname>PostgreSQL</productname>中的备份和恢复机制在<xref linkend="backup"/>中有详细的介绍。
+   一个显而易见的维护任务是定期创建数据的后备拷贝。如果没有一个最近的备份，你就不可能在灾难（磁盘故障、火灾、错误地删除一个关键表等）后进行恢复。<productname>PostgreSQL</productname>中的备份和恢复机制在<xref linkend="backup"/>中有详细的介绍。
   </para>
 <!-- pgdoc-cn_end sig_en=0f7eeeb8c46a383e680a70576515d46c -->
 
@@ -1739,7 +1739,7 @@ ________________________________________________________-->
   </para>
 ________________________________________________________-->
   <para>
-   已经完全变成空的B树索引页面被收回重用。但是，还是有一种低效的空间利用的可能性：如果一个页面上除少量索引键之外的全部键被删除，该页面仍然被分配。因此，在这种每个范围中大部分但不是全部键最终被删除的使用模式中，可以看到空间的使用是很差的。对于这样的使用模式，推荐使用定期重新索引。
+   已经完全变成空的B树索引页面被收回重用。但是，还是有一种低效的空间利用的可能性：如果一个页面上除少量索引键之外的全部键被删除，该页面仍然被分配。因此，在这种每个范围中大部分但不是全部键最终被删除的使用模式中，可以看到空间的使用是很差的。对于这样的使用模式，推荐定期重建索引。
   </para>
 <!-- pgdoc-cn_end sig_en=9f3b6d1c9431389c060175a47f00c973 -->
 
@@ -1765,7 +1765,7 @@ ________________________________________________________-->
   </para>
 ________________________________________________________-->
   <para>
-   还有，对于B树索引，一个新建立的索引比更新了多次的索引访问起来要略快， 因为在新建立的索引上，逻辑上相邻的页面通常物理上也相邻（这样的考虑目前并不适用于非B树索引）。仅仅为了提高访问速度也值得定期重新索引。
+   还有，对于B树索引，一个新建立的索引比更新了多次的索引访问起来要略快， 因为在新建立的索引上，逻辑上相邻的页面通常物理上也相邻（这样的考虑目前并不适用于非B树索引）。仅仅为了提高访问速度也值得定期重建索引。
   </para>
 <!-- pgdoc-cn_end sig_en=7dba770e908d17c268cd99cebeacf3fb -->