Corrections typos sur section "applevel-consistency"

postgresql/mvcc.xml

@@ -674,7 +674,7 @@ ERREUR:  n'a pas pu sérialiser un accès à cause d'une mise à jour en parall
     des données devra prendre un verrou sur la table entière, ce
     qui pourrait bloquer d'autres utilisateurs voulant utiliser cette
     table, ou pourrait utiliser <literal>SELECT FOR UPDATE</literal> ou
-    <literal>SELECT FOR SELECT</literal> qui non seulement peut bloquer
+    <literal>SELECT FOR SHARE</literal> qui non seulement peut bloquer
     d'autres transactions, mais entraîne un accès au disque.
    </para>
 
@@ -1604,7 +1604,7 @@ SELECT pg_advisory_lock(q.id) FROM
   <para>
    Il est très difficile d'implémenter des règles de gestion sur l'intégrité
    des données en utilisant des transactions Read Committed parce que la vue
-   des données est changeante avec chaque ordre, met même un seul ordre peut
+   des données est changeante avec chaque ordre, et même un seul ordre peut
    ne pas se cantonner à son propre instantané si un conflit en écriture
    se produit.
   </para>
@@ -1616,7 +1616,7 @@ SELECT pg_advisory_lock(q.id) FROM
    vérifier la cohérence des données, impliquant quelque chose connu
    sous le nom de <firstterm>conflits lecture/écriture</firstterm>. Si
    une transaction écrit des données et qu'une transaction
-   concurrent essaye de lire la même donnée (que ce soit avant ou
+   concurrente essaye de lire la même donnée (que ce soit avant ou
    après l'écriture), elle ne peut pas voir le travail de l'autre
    transaction. Le lecteur donne donc l'impression de s'être exécuté
    le premier quel que soit celui qui a commencé le premier ou qui a
@@ -1634,14 +1634,14 @@ SELECT pg_advisory_lock(q.id) FROM
   <para>
    Comme mentionné dans <xref linkend="xact-serializable"/>, les
    transactions Serializable ne sont que des transactions Repeatable
-   Read qui ajoutent une supervision no-bloquante de formes dangereuses
+   Read qui ajoutent une supervision non-bloquante de formes dangereuses
    de conflits lecture/écriture. Quand une de ces formes est détectée
    qui pourrait entraîner un cycle dans l'ordre apparent d'exécution,
    une des transactions impliquées est annulée pour casser le cycle.
   </para>
 
   <sect2 id="serializable-consistency">
-   <title>Garantir la Cohérence avec Des Transactions Serializable</title>
+   <title>Garantir la Cohérence avec des Transactions Serializable</title>
 
    <para>
     Si le niveau d'isolation de transactions Serializable est utilisé
@@ -1656,9 +1656,9 @@ SELECT pg_advisory_lock(q.id) FROM
    <para>
     L'utilisation de cette technique évitera de créer une
     charge de travail inutile aux développeurs d'applications
-    si le logiciel utilise un framework qui réessaye le
-    s transactions annulées pour échec de sérialisation
-    automatiquement. Cela pourrait être une bonne idée de
+    si le logiciel utilise un framework qui réessaye automatiquement
+    les transactions annulées pour échec de sérialisation.
+    Cela pourrait être une bonne idée de
     positionner <literal>default_transaction_isolation</literal> à
     <literal>serializable</literal>. Il serait sage, par ailleurs, de
     vous assurer qu'aucun autre niveau d'isolation n'est utilisé, soit
@@ -1673,7 +1673,7 @@ SELECT pg_advisory_lock(q.id) FROM
 
    <warning>
     <para>
-     Ce niveau de protection de protection de l'intégrité en utilisant
+     Ce niveau de protection de l'intégrité en utilisant
      des transactions Serializable ne s'étend pour le moment pas
      jusqu'au mode standby (<xref linkend="hot-standby"/>). Pour cette
      raison, les utilisateurs du hot standby voudront peut-être utiliser
@@ -1719,19 +1719,19 @@ SELECT pg_advisory_lock(q.id) FROM
    </para>
 
    <para>
-    Les verrifications globales de validité demandent davantage de
+    Les vérifications globales de validité demandent davantage de
     réflexion sous un <acronym>MVCC</acronym> non sérialisable. Par
     exemple, une application bancaire pourrait vouloir vérifier que
     la somme de tous les crédits d'une table est égale à la somme
     de tous les débits d'une autre, alors que les deux tables sont
     en cours de mise à jour. La comparaison des résultas de deux
     <literal>SELECT sum(...)</literal> successifs ne fonctionnera pas
     correctement en mode Read Committed, puisque la seconde requête
-    incluera probablement les résultats de transactions pas prises en
+    incluera probablement les résultats de transactions non prises en
     compte dans la première. Effectuer les deux sommes dans une seule
     transaction repeatable read donnera une image précise des effets
     d'uniquement les transactions  qui ont validé avant le début de la
-    transaction repeatable read $mdash; mais on pourrait légitimement
+    transaction repeatable read — mais on pourrait légitimement
     se demander si la réponse est toujours valide au moment où elle
     est fournie. Si la transaction repeatable read a elle même effectué
     des modifications avant d'effectuer le test de cohérence, l'utilité
@@ -1748,9 +1748,9 @@ SELECT pg_advisory_lock(q.id) FROM
    <para>
     Notez aussi que si on se fie au verrouillage explicite pour
     empêcher les mises à jour concurrentes, on devrait soit utiliser
-    Read Committed, soit utiliser Repeatable Read et faire attenion
+    Read Committed, soit utiliser Repeatable Read et faire attention
     à obtenir les verrous avant d'effectuer les requêtes. Un verrou
-    obtenu par une transaction repeatable read guarantit qu'aucune autre
+    obtenu par une transaction repeatable read garantit qu'aucune autre
     transaction modifiant la table n'est en cours d'exécution, mais si
     l'instantané vu par la transaction est antérieur à l'obtention du
     verrou, il pourrait aussi précéder des modifications maintenant