pgbench, traduction vs 15 beta2, presque fin

postgresql/ref/pgbench.xml

@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
+<<?xml version="1.0" encoding="UTF-8"?>
 <refentry id="pgbench">
  <indexterm zone="pgbench">
   <primary>pgbench</primary>
@@ -2940,132 +2940,147 @@ statement latencies in milliseconds, failures and retries:
    <title>Nouvelles tentatives suite à des erreurs de sérialisation ou des deadlocks</title>
 
    <para>
-    When executing <application>pgbench</application>, there are three main types
-    of errors:
+    À l'exécution de <application>pgbench</application>, il y a trois
+    principaux types d'erreurs, qui comprennent&nbsp;:
     <itemizedlist>
       <listitem>
         <para>
-          Errors of the main program. They are the most serious and always result
-          in an immediate exit from <application>pgbench</application> with the
-          corresponding error message. They include:
+          Les erreurs du programme principal. Ce sont les plus sérieuses
+          et entraînent toujours une sortie immédiate de pgbench avec le
+          message d'erreur correspondant. Elles incluent&nbsp;:
           <itemizedlist>
             <listitem>
               <para>
-                errors at the beginning of <application>pgbench</application>
-                (e.g. an invalid option value);
+                les erreurs au lancement de <application>pgbench</application>
+                (par exemple une valeur d'option invalide)&nbsp;;
               </para>
             </listitem>
             <listitem>
               <para>
-                errors in the initialization mode (e.g. the query to create
-                tables for built-in scripts fails);
+                les erreurs dans la phase d'initialisation
+                (par exemple quand échoue la requête de création des tables des
+                scripts inclus)
               </para>
             </listitem>
             <listitem>
               <para>
-                errors before starting threads (e.g. could not connect to the
-                database server, syntax error in the meta command, thread
-                creation failure);
+                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
+                création du thread)&nbsp;;
               </para>
             </listitem>
             <listitem>
               <para>
-                internal <application>pgbench</application> errors (which are
-                supposed to never occur...).
+                les erreurs internes de <application>pgbench</application>
+                (supposées ne jamais se produire...).
               </para>
             </listitem>
           </itemizedlist></para>
       </listitem>
       <listitem>
         <para>
-          Errors when the thread manages its clients (e.g. the client could not
-          start a connection to the database server / the socket for connecting
-          the client to the database server has become invalid). In such cases
-          all clients of this thread stop while other threads continue to work.
+          Les erreurs quand le thread gère ses clients (par exemple
+          si le client ne peut démarrer une connexion au serveur /
+          si la socket pour connecter le client au serveur est devenu invalide).
+          Dans ces cas, tous les clients du thread s'arrêtent pendant que
+          les autres continuent de fonctionner.
         </para>
       </listitem>
       <listitem>
         <para>
-          Direct client errors. They lead to immediate exit from
-          <application>pgbench</application> with the corresponding error message
-          only in the case of an internal <application>pgbench</application>
-          error (which are supposed to never occur...). Otherwise in the worst
-          case they only lead to the abortion of the failed client while other
-          clients continue their run (but some client errors are handled without
-          an abortion of the client and reported separately, see below). Later in
-          this section it is assumed that the discussed errors are only the
-          direct client errors and they are not internal
-          <application>pgbench</application> errors.
+          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).
+          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
+          erreurs internes de pgbench.
         </para>
       </listitem>
     </itemizedlist>
    </para>
 
    <para>
-    A client's run is aborted in case of a serious error; for example, the
-    connection with the database server was lost or the end of script was reached
-    without completing the last transaction. In addition, if execution of an SQL
-    or meta command fails for reasons other than serialization or deadlock errors,
-    the client is aborted. Otherwise, if an SQL command fails with serialization or
-    deadlock errors, the client is not aborted. In such cases, the current
-    transaction is rolled back, which also includes setting the client variables
-    as they were before the run of this transaction (it is assumed that one
-    transaction script contains only one transaction; see
-    <xref linkend="transactions-and-scripts"/> for more information).
-    Transactions with serialization or deadlock errors are repeated after
-    rollbacks until they complete successfully or reach the maximum
-    number of tries (specified by the <option>--max-tries</option> option) / the maximum
-    time of retries (specified by the <option>--latency-limit</option> option) / the end
-    of benchmark (specified by the <option>--time</option> option). If
-    the last trial run fails, this transaction will be reported as failed but
-    the client is not aborted and continues to work.
+    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
+    <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
+    succès, ou qu'elles atteignent le nombre maximum de tentatives
+    (indiqué avec <option>--max-tries</option>) / le temps maximal
+    pour les tentatives (indiqué avec <option>--latency-limit</option>)
+    / la fin du test (indiqué avec <option>--time</option>).
+    Si la dernière tentative d'exécution échoue, la transaction sera
+    comptabilisée comme échouée, mais le client n'est pas arrếté et
+    continue de fonctionner.
    </para>
 
    <note>
     <para>
-     Without specifying the <option>--max-tries</option> option, a transaction will
-     never be retried after a serialization or deadlock error because its default
-     value is 1. Use an unlimited number of tries (<literal>--max-tries=0</literal>)
-     and the <option>--latency-limit</option> option to limit only the maximum time
-     of tries. You can also use the <option>--time</option> option to limit the
-     benchmark duration under an unlimited number of tries.
+     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,
+     utilisez l'option <option>--latency-limit</option> 
+     en indiquant un nombre illimité de tentatives
+     (<literal>--max-tries=0</literal>).
+     Vous pouvez aussi utiliser <option>--time</option> pour limiter la 
+     durée du test alors que le nombre de tentatives est illimité.
     </para>
     <para>
-     Be careful when repeating scripts that contain multiple transactions: the
-     script is always retried completely, so successful transactions can be
-     performed several times.
+     Faites attention lors de la répétition de scripts avec de
+     multiples transactions&nbsp;: le script est toujours intégralement
+     réexécuté, et les transactions réussies peuvent donc être exécutées
+     plusieurs fois.
     </para>
     <para>
-     Be careful when repeating transactions with shell commands. Unlike the
-     results of SQL commands, the results of shell commands are not rolled back,
-     except for the variable value of the <command>\setshell</command> command.
+     Faites aussi attention lors de la répétition de scripts avec des
+     commandes shell. Leur résultat n'est pas annulé, contrairement
+     à ce qui passe avec des commandes SQL, à part pour une valeur assignée
+     avec la commande <command>\setshell</command>.
     </para>
    </note>
 
    <para>
-    The latency of a successful transaction includes the entire time of
-    transaction execution with rollbacks and retries. The latency is measured
-    only for successful transactions and commands but not for failed transactions
-    or commands.
+    La latence d'une transaction réussie inclut la durée entière de
+    l'exécution, y compris les rollbacks et les diverses tentatives.
+    La latence n'est mesurée que pour les transactions et commandes réussies,
+    mais pas pour celles en échec.
    </para>
 
    <para>
-    The main report contains the number of failed transactions. If the
-    <option>--max-tries</option> option is not equal to 1, the main report also
-    contains statistics related to retries: the total number of retried
-    transactions and total number of retries. The per-script report inherits all
-    these fields from the main report. The per-statement report displays retry
-    statistics only if the <option>--max-tries</option> option is not equal to 1.
+    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.
+    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.
    </para>
 
    <para>
-    If you want to group failures by basic types in per-transaction and
-    aggregation logs, as well as in the main and per-script reports, use the
-    <option>--failures-detailed</option> option. If you also want to distinguish
-    all errors and failures (errors without retrying) by type including which
-    limit for retries was exceeded and how much it was exceeded by for the
-    serialization/deadlock failures, use the <option>--verbose-errors</option>
-    option.
+    Si vous voulez regrouper les échecs par types dans les journaux
+    par transaction et les journaux agrégés, utilisez l'option
+    <option>--failures-detailed</option>.
+    Si vous voulez aussi distinguer toutes les erreurs et les échecs
+    (c'est-à-dire les erreurs sans nouvelle tentative), en incluant
+    quelles limites sur les tentatives ont été dépassées, et de combien,
+    pour les échecs de sérialisation ou sur deadlock,
+    utilisez <option>--verbose-errors</option>.
    </para>
   </refsect2>
 
@@ -3093,11 +3108,11 @@ statement latencies in milliseconds, failures and retries:
 
    <para>
     Pour le scénario de test par défaut typé TPC-B, le facteur d'échelle
-    d'initialisation (<option>-s</option>) devrait être au moins
+    d'initialisation (<option>-s</option>) doit être au moins
     aussi grand que le nombre maximum de clients que vous avez
-    l'intention de tester (<option>-c</option>)&nbsp;; sinon vous allez
-    principalement tester la contention induite par les mises à jour.
-    il n'y a que <option>-s</option> lignes dans la table
+    l'intention de tester (<option>-c</option>)&nbsp;; sinon vous
+    testez surtout la contention induite par les mises à jour.
+    Il n'y a que <option>-s</option> lignes dans la table
     <structname>pgbench_branches</structname>, et chaque transaction
     veut mettre à jour l'une de ces lignes, donc si la valeur de
     <option>-c</option> est supérieure à la valeur de <option>-s</option>,
@@ -3138,7 +3153,7 @@ statement latencies in milliseconds, failures and retries:
      sécurisée d'utilisation des schémas</link>, il ne faut pas exécuter
     <application>pgbench</application> dans cette base.
     <application>pgbench</application> utilise des noms non qualifiés et ne
-    modifie le chemin de recherche.
+    modifie pas le chemin de recherche.
    </para>
   </refsect2>
  </refsect1>