Suppression d'un chapitre présent deux fois

postgresql/mvcc.xml

@@ -1539,82 +1539,6 @@ SELECT pg_advisory_lock(q.id) FROM
    </sect2>
   </sect1>
 
-  <sect1 id="locking-indexes">
-   <title>Verrous et index</title>
-
-   <indexterm zone="locking-indexes">
-    <primary>index</primary>
-    <secondary>verrous</secondary>
-   </indexterm>
-
-   <para>
-    Bien que <productname>PostgreSQL</productname> fournisse un accès en
-    lecture/écriture non bloquant aux données de la table, l'accès en
-    lecture/écriture non bloquant n'est pas proposé pour chaque méthode
-    d'accès aux index implémentées dans <productname>PostgreSQL</productname>.
-    Les différents types d'index sont gérés ainsi&nbsp;:
-
-    <variablelist>
-     <varlistentry>
-      <term>
-       Index B-tree, <acronym>GiST</acronym> et <acronym>SP-GiST</acronym>
-      </term>
-      <listitem>
-       <para>
-        Des verrous partagés/exclusifs au niveau page à court terme sont
-        utilisés pour les accès en lecture/écriture. Les verrous sont
-        relachés immédiatement après que chaque ligne d'index soit
-        lu ou inséré. Ces types d'index fournissent la plus grande
-        concurrence d'accès, sans conditions de verrous mortels.
-       </para>
-      </listitem>
-     </varlistentry>
-
-     <varlistentry>
-      <term>
-       Index hash
-      </term>
-      <listitem>
-       <para>
-        Des verrous partagés/exclusifs au niveau des blocs de hachage sont
-        utilisés pour l'accès en lecture/écriture. Les verrous sont relachés
-        après qu'un bloc a été traité entièrement. Les verrous au niveau bloc
-        fournissent une meilleur concurrence d'accès que les verrous au
-        niveau index, mais les verrous mortels sont possibles car les
-        verrous sont détenus plus longtemps que l'opération sur l'index.
-       </para>
-      </listitem>
-     </varlistentry>
-
-     <varlistentry>
-      <term>
-       Index <acronym>GIN</acronym>
-      </term>
-      <listitem>
-       <para>
-        Des verrous partagés/exclusifs au niveau page à court terme sont
-        utilisés pour les accès en lecture/écriture. Les verrous sont
-        relachés immédiatement après que chaque ligne d'index soit
-        lu ou inséré. Cependant, notez que l'insertion d'une valeur indexée
-        par GIN produit généralement plusieurs insertions de clés d'index
-        par ligne, donc GIN peut avoir un travail important à réaliser
-        pour l'insertion d'une seule valeur.
-       </para>
-      </listitem>
-     </varlistentry>
-    </variablelist>
-   </para>
-
-   <para>
-    Actuellement, les index B-tree offrent les meilleures performances pour les
-    applications concurrentes. Comme ils ont plus de fonctionnalités que les
-    index hash, ils sont le type d'index recommandé pour les applications
-    concurrentes qui ont besoin d'indexer des données scalaires. Lors du
-    traitement de données non scalaires, les index B-tree ne sont pas utiles.
-    Les index GiST, SP-GiST ou GIN doivent être utilisés à la place.
-   </para>
-  </sect1>
-
   <sect1 id="mvcc-caveats">
    <title>Avertissements</title>
 
@@ -1674,9 +1598,9 @@ SELECT pg_advisory_lock(q.id) FROM
       </term>
       <listitem>
        <para>
-        Les verrous partagés/exclusifs au niveau hash-bucket sont utilisés
+        Les verrous partagés/exclusifs au niveau des blocs de hachage sont utilisés
         pour des accès en lecture/écriture. Les verrous sont relâchés après la
-        fin des traitements sur le bucket. Les verrous au niveau bucket
+        fin des traitements sur un bloc. Les verrous au niveau bloc
         fournissent un meilleur accès concurrent que les verrous au niveau
         index mais sont sensibles aux interblocages car les verrous sont
         détenus plus longtemps que pour une opération sur un index.