pgbench, traduction vs 15 beta2, fini

postgresql/ref/pgbench.xml

@@ -2942,8 +2942,8 @@ statement latencies in milliseconds, failures and retries:
     <itemizedlist>
       <listitem>
         <para>
-          Les erreurs du programme principal. Ce sont les plus sérieuses
-          et entraînent toujours une sortie immédiate de pgbench avec le
+          Les erreurs du programme principal. Ce sont les plus sérieuses,
+          et elles entraînent toujours une sortie immédiate de pgbench avec le
           message d'erreur correspondant. Elles incluent&nbsp;:
           <itemizedlist>
             <listitem>
@@ -2955,15 +2955,14 @@ statement latencies in milliseconds, failures and retries:
             <listitem>
               <para>
                 les erreurs dans la phase d'initialisation
-                (par exemple quand échoue la requête de création des tables des
-                scripts inclus)
+                (par exemple quand échoue la requête de création des tables pour les scripts inclus)
               </para>
             </listitem>
             <listitem>
               <para>
                 les erreurs avant le démarrage des threads (par exemple
                 l'impossibilité à se connecter au serveur de bases de données,
-                une erreur de syntaxe dans la méta-commande, une erreur à la
+                une erreur de syntaxe dans la métacommande, une erreur à la
                 création du thread)&nbsp;;
               </para>
             </listitem>
@@ -2986,17 +2985,16 @@ statement latencies in milliseconds, failures and retries:
       </listitem>
       <listitem>
         <para>
-          Les erreurs directes du client. Elles ne mènent à un arrêt
-          immédiat de
-          <application>pgbench</application> avec le message d'erreur
-          correspondant que dans le cas d'erreurs internes de pgbench
-          (supposées ne jamais se produire...)
-          Sinon, dans le pire des cas, elles ne mènent qu'à l'arrêt du
-          client en échec alors que les autres continuent leur travail
-          (mais certaines erreurs des clients sont gérées sans un arrêt
-          du client et rapportées séparément, voir plus bas).
+          Les erreurs directes du client. Elles mènent à un arrêt immédiat de
+          <application>pgbench</application>, avec le message d'erreur
+          correspondant, uniquement dans le cas d'une erreur interne de
+          pgbench (supposées ne jamais se produire...).
+          Sinon, dans le pire des cas, ces erreurs n'entraînent que l'arrêt
+          du client en échec, pendant que les autres continuent leur travail
+          (mais certaines erreurs des clients sont gérées sans arrêter
+          le client et sont rapportées séparément, voir plus bas).
           Dans la suite de cette section, on suppose que les erreurs
-          évoquées ne sont que des erreurs du client et ne sont pas des
+          évoquées ne sont que des erreurs du client et non des
           erreurs internes de pgbench.
         </para>
       </listitem>
@@ -3006,19 +3004,19 @@ statement latencies in milliseconds, failures and retries:
    <para>
     L'exécution d'un client n'est interrompue que dans le cas d'une erreur
     sérieuse&nbsp;: par exemple, la connexion au serveur a été perdue,
-    ou la fin du script a été atteinte sans avoir terminé la dernière transaction.
-    De plus, si l'exécution d'une commande SQL ou d'une métacommande
-    échoue pour une autre raison qu'une erreur de sérialisation ou un
-    deadlock, le client s'arrête. Il n'est pas arrêté lors de ces deux erreurs.
-    Dans ce cas, la transaction courante est annulée, ce qui comprend la
-    restauration des variables à leurs valeurs d'avant l'exécution de la
-    transaction (on suppose un script de transaction ne contient qu'une
-    transaction&nbsp; voir
+    ou la fin du script a été atteinte sans avoir terminé la dernière
+    transaction. De plus, si l'exécution d'une commande SQL ou d'une
+    métacommande échoue, le client est arrêté, sauf pour une erreur de
+    sérialisation ou un deadlock.
+    Dans ce dernier cas, la transaction courante est annulée, ce qui comprend
+    la restauration des variables à leurs valeurs d'avant l'exécution de la
+    transaction (on suppose qu'un script de transaction ne contient qu'une
+    transaction&nbsp;; voir
     <xref linkend="transactions-and-scripts"/> pour plus d'informations).
     Les transactions avec des erreurs de sérialisation ou des deadlocks
-    sont répétées après rollback, jusqu'à ce qu'elles se terminent avec
+    sont répétées après le rollback, jusqu'à ce qu'elles se terminent avec
     succès, ou qu'elles atteignent le nombre maximum de tentatives
-    (indiqué avec <option>--max-tries</option>) / le temps maximal
+    (indiqué avec <option>--max-tries</option>) / le délai maximal
     pour les tentatives (indiqué avec <option>--latency-limit</option>)
     / la fin du benchmark (indiqué avec <option>--time</option>).
     Si la dernière tentative d'exécution échoue, la transaction sera
@@ -3031,7 +3029,7 @@ statement latencies in milliseconds, failures and retries:
      Sans définition de <option>--max-tries</option>, une transaction ne
      sera jamais retentée après une erreur de sérialisation ou un
      deadlock, car la valeur par défaut de l'option est 1.
-     Pour ne limiter que la durée totale des tentatives,
+     Pour limiter uniquement la durée totale des tentatives,
      utilisez l'option <option>--latency-limit</option> 
      en indiquant un nombre illimité de tentatives
      (<literal>--max-tries=0</literal>).
@@ -3063,7 +3061,8 @@ statement latencies in milliseconds, failures and retries:
     Le rapport principal contient le nombre de transactions échouées. Si
     <option>--max-tries</option> n'est pas égal à 1, il contiendra aussi
     des statistiques sur les tentatives&nbsp;: le nombre total de
-    nouvelles tentatives et le nombre total de tentatives.
+    transactions tentées plusieurs fois, et le nombre total de
+    nouvelles tentatives.
     Le rapport par script hérite de tous ces champs. Le rapport par
     requête n'affiche les statistiques sur les tentatives que si
     <option>--max-tries</option> n'est pas égal à 1.