Quelques corrections

postgresql/btree-gin.xml

@@ -33,9 +33,10 @@
  </para>
 
  <para>
-  Ce module est considéré comme <quote>trusted</quote>, ce qui signifie qu'il 
-  peut être installé par des utilisateurs simples (pas super-utilisateurs) et 
-  qui ont le droit <literal>CREATE</literal> sur la base de données courante.
+  Ce module est considéré comme <quote>trusted</quote>, ce qui signifie qu'il
+  peut être installé par des utilisateurs simples (sans attribut
+  <literal>SUPERUSER</literal>) et qui ont l'attribut <literal>CREATE</literal>
+  sur la base de données courante.
  </para>
 
  <sect2>

postgresql/btree-gist.xml

@@ -56,8 +56,9 @@
 
  <para>
   Ce module est considéré comme <quote>trusted</quote>, ce qui signifie qu'il 
-  peut être installé par des utilisateurs simples (pas super-utilisateurs) et 
-  qui ont le droit <literal>CREATE</literal> sur la base de données courante.
+  peut être installé par des utilisateurs simples (sans attribut
+  <literal>SUPERUSER</literal>) et qui ont l'attribut <literal>CREATE</literal>
+  sur la base de données courante.
  </para>
 
  <sect2>

postgresql/catalogs.xml

@@ -11287,8 +11287,8 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
        Le LSN de ce nœud auquel <literal>remote_lsn</literal> a été
        répliqué. Utilisé pour vider les enregistrements validés
        avant de sauvegarder les données sur disque lorsque la validation
-       asynchrone des transations est utilisée.
-      </para></entry>
+       asynchrone des transactions est utilisée.
+      </entry>
      </row>
     </tbody>
    </tgroup>

postgresql/high-availability.xml

@@ -147,7 +147,7 @@ https://forge.continuent.org/pipermail/sequoia/2006-November/004070.html
 La technologie Oracle RAC est une approche par disques partagés et renvoie
 aux autres nœuds uniquement les annulations de niveau cache mais pas
 réellement au niveau des données (physiques).
-Puisque les disques sont partagés, les données sont validées une seule 
+Puisque les disques sont partagés, les données sont validées une seule
 fois en s'appuyant sur un protocole de verrouillage distribué, de façon à
 ce que les nœuds s'accordent dans un système transactionnel sérialisable.
 
@@ -898,7 +898,7 @@ archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'
    <sect3 id="streaming-replication-authentication">
     <title>Authentification</title>
     <para>
-     Il est très important que les privilèges d'accès pour la réplication
+     Il est très important que les droits d'accès pour la réplication
      soient paramétrés pour que seuls les utilisateurs de confiance puissent
      lire le flux WAL, parce qu'il est facile d'en extraire des informations
      privilégiées. Les serveurs de standby doivent s'authentifier au serveur
@@ -1009,8 +1009,8 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
     ne conservent que le nombre nécessaire de journaux de transactions. D'un
     autre côté, les slots de réplication peuvent retenir tellement de journaux
     de transactions qu'ils rempliraient l'espace disque alloué à
-    <literal>pg_wal</literal>; <xref linkend="guc-max-slot-wal-keep-size"/>
-    limitera la taille des journaux de transactions à retenir par les slots de
+    <literal>pg_wal</literal>&nbsp;; <xref linkend="guc-max-slot-wal-keep-size"/>
+    limite la taille des journaux de transactions à retenir par les slots de
     réplication.
    </para>
    <para>
@@ -1049,7 +1049,7 @@ postgres=# SELECT * FROM pg_create_physical_replication_slot('node_a_slot');
  node_a_slot |
 
 postgres=# SELECT slot_name, slot_type, active FROM pg_replication_slots;
-  slot_name  | slot_type | active 
+  slot_name  | slot_type | active
 -------------+-----------+--------
  node_a_slot | physical  | f
      </programlisting>
@@ -1279,13 +1279,13 @@ primary_slot_name = 'node_a_slot'
     considérés synchrones confirment la réception de leurs données. Le nombre
     de standbys dont les transactions doivent attendre la réponse est indiqué
     dans le paramètre <varname>synchronous_standby_names</varname>. Ce paramètre
-    indique aussi une liste des noms des serveurs standbys ou l'emploi 
-    de la méthode (<literal>FIRST</literal> ou <literal>ANY</literal>) pour choisir 
+    indique aussi une liste des noms des serveurs standbys ou l'emploi
+    de la méthode (<literal>FIRST</literal> ou <literal>ANY</literal>) pour choisir
     sur quel serveur synchrone basculer parmi l'ensemble des serveurs listés.
    </para>
 
    <para>
-    La méthode <literal>FIRST</literal> définit une réplication synchrone 
+    La méthode <literal>FIRST</literal> définit une réplication synchrone
     priorisée&nbsp;: elle temporise la validation de la transaction
     jusqu'à ce que les enregistrements WAL soient répliqués en
     fonction de la priorité définie des serveurs standbys dans une liste
@@ -1295,45 +1295,45 @@ primary_slot_name = 'node_a_slot'
     Les serveurs standbys suivants sont considérés comme un/des
     serveurs standbys synchrones potentiels.
     Si le premier serveur synchrone venait à tomber,
-    il serait immédiatement remplacé par le serveur 
+    il serait immédiatement remplacé par le serveur
     standby prioritaire suivant.
-    
+
    </para>
    <para>
-    Voici un exemple de configuration de <varname>synchronous_standby_names</varname> pour la 
+    Voici un exemple de configuration de <varname>synchronous_standby_names</varname> pour la
     réplication synchrone priorisée&nbsp;:
 <programlisting>
 synchronous_standby_names = 'FIRST 2 (s1, s2, s3)'
 </programlisting>
     Dans cet exemple, si les quatre serveurs standbys <literal>s1</literal>,
-    <literal>s2</literal>, <literal>s3</literal> et <literal>s4</literal> 
+    <literal>s2</literal>, <literal>s3</literal> et <literal>s4</literal>
     sont fonctionnels et en cours d'exécution, les deux serveurs
     <literal>s1</literal> et <literal>s2</literal> seront choisis comme
-    standbys synchrones car leurs noms apparaissent en premier dans la 
-    liste des serveurs standbys. <literal>s3</literal> est un serveur 
-    standby synchrone potentiel et prendra le rôle d'un standby synchrone 
-    si <literal>s1</literal> ou <literal>s2</literal> tombe. 
+    standbys synchrones car leurs noms apparaissent en premier dans la
+    liste des serveurs standbys. <literal>s3</literal> est un serveur
+    standby synchrone potentiel et prendra le rôle d'un standby synchrone
+    si <literal>s1</literal> ou <literal>s2</literal> tombe.
     <literal>s4</literal> est un standby asynchrone et son nom n'est pas dans la liste.
    </para>
 
    <para>
-	La méthode <literal>ANY</literal> définit une réplication synchrone 
-	basée sur un quorum&nbsp;: elle temporise la validation de la 
-	transaction jusqu'à ce que les enregistrements WAL soient répliqués 
-	<emphasis>au moins</emphasis> sur le nombre de serveurs définis dans 
+	La méthode <literal>ANY</literal> définit une réplication synchrone
+	basée sur un quorum&nbsp;: elle temporise la validation de la
+	transaction jusqu'à ce que les enregistrements WAL soient répliqués
+	<emphasis>au moins</emphasis> sur le nombre de serveurs définis dans
 	la liste.
    </para>
    <para>
-    Voici un exemple de configuration du paramètre <varname>synchronous_standby_names</varname> pour la 
+    Voici un exemple de configuration du paramètre <varname>synchronous_standby_names</varname> pour la
     réplication synchrone avec un quorum&nbsp;:
 <programlisting>
  synchronous_standby_names = 'ANY 2 (s1, s2, s3)'
 </programlisting>
-    Dans cet exemple, sur quatre serveurs standbys démarrés <literal>s1</literal>, 
+    Dans cet exemple, sur quatre serveurs standbys démarrés <literal>s1</literal>,
     <literal>s2</literal>,<literal>s3</literal> et <literal>s4</literal>,
     pour obtenir la validation d'une transaction, le serveur primaire
     attendra la réponse d'au minimum deux standbys parmi <literal>s1</literal>,
-    <literal>s2</literal> et <literal>s3</literal>. <literal>s4</literal>  
+    <literal>s2</literal> et <literal>s3</literal>. <literal>s4</literal>
     est un standby asynchrone et son nom n'est pas dans la liste.
    </para>
    <para>
@@ -1408,7 +1408,7 @@ synchronous_standby_names = 'FIRST 2 (s1, s2, s3)'
     apparaissent en premier seront utilisé comme standbys synchrones.
     Les standbys définis ensuite prendront la place de serveur
     synchrone si l'un des serveurs venait à tomber.
-    
+
    </para>
 
    <para>
@@ -1483,38 +1483,38 @@ synchronous_standby_names = 'FIRST 2 (s1, s2, s3)'
      Lorsque l'archivage continu est utilisé sur un standby, il existe
      deux scénarios possibles&nbsp;: soit les archives sont partagées entre le
      serveur primaire et le serveur de standby, soit le standby peut avoir
-     ses propres archives. Si le serveur possède ses propres archives, 
-     en définissant le paramètre <varname>archive_mode</varname> à 
-     <literal>always</literal>, le standby exécutera la commande 
-     d'archivage pour chaque segment de WAL qu'il aura reçu, peu importe 
-     qu'il utilise la réplication par les archives ou la réplication 
+     ses propres archives. Si le serveur possède ses propres archives,
+     en définissant le paramètre <varname>archive_mode</varname> à
+     <literal>always</literal>, le standby exécutera la commande
+     d'archivage pour chaque segment de WAL qu'il aura reçu, peu importe
+     qu'il utilise la réplication par les archives ou la réplication
      streaming.
-     
-     La gestion par archivage partagé peut être faite de la même manière, 
-     mais <varname>archive_command</varname> doit d'abord tester si le segment 
+
+     La gestion par archivage partagé peut être faite de la même manière,
+     mais <varname>archive_command</varname> doit d'abord tester si le segment
      de WAL existe, et si le fichier existant contient les mêmes informations.
-     Cela demande plus de précaution lors de la définition de la commande, 
+     Cela demande plus de précaution lors de la définition de la commande,
      car elle doit vérifier qu'elle n'écrase pas un fichier existant avec
-     un contenu différent, et doit renvoyer un succès si le même fichier 
-     est archivé deux fois. Tout ceci devant être en plus effectué sans 
-     concurrence si deux serveurs essayent d'archiver le même fichier au 
+     un contenu différent, et doit renvoyer un succès si le même fichier
+     est archivé deux fois. Tout ceci devant être en plus effectué sans
+     concurrence si deux serveurs essayent d'archiver le même fichier au
      même moment.
 
    </para>
 
    <para>
-     Si <varname>archive_mode</varname> est défini à <literal>on</literal>, 
+     Si <varname>archive_mode</varname> est défini à <literal>on</literal>,
      l'archivage n'est pas actif pendant les modes recovery et standby.
-     Si le serveur standby est promu, il commencera à réaliser l'archivage 
+     Si le serveur standby est promu, il commencera à réaliser l'archivage
      après sa promotion, et il archivera uniquement les fichiers qu'il a lui
      même produit. Pour être sûr d'obtenir un jeu complet d'archives, vous
      devez vous assurer que tous les fichiers WAL ont été archivés avant
-     qu'ils atteignent le standby. C'est implicitement toujours le cas 
+     qu'ils atteignent le standby. C'est implicitement toujours le cas
      avec un log-shipping s'appuyant sur les archives, car le standby ne
-     récupère que des informations provenant de ces mêmes fichiers 
+     récupère que des informations provenant de ces mêmes fichiers
      archivés. Ce n'est pas le cas dans le cadre de la réplication
      streaming.
-     Lorsqu'un serveur est en standby il n'y a aucune différence 
+     Lorsqu'un serveur est en standby il n'y a aucune différence
      entre les modes <literal>on</literal> et <literal>always</literal>.
    </para>
   </sect2>
@@ -2376,7 +2376,7 @@ LOG:  database system is ready to accept read only connections
     re-génèreront les fichiers d'information relcache, il n'y a donc pas de morceau de la base
     qui soit réellement en lecture seule en mode hot standby.
     Notez aussi que les écritures dans des bases distantes en utilisant le module
-    <application>dblink</application>, et d'autres opération en dehors de la base s'appuyant sur
+    <application>dblink</application>, et d'autres opérations en dehors de la base s'appuyant sur
     des fonctions PL seront toujours possibles, même si la transaction est en lecture seule localement.
    </para>
 
@@ -2392,7 +2392,7 @@ LOG:  database system is ready to accept read only connections
      </listitem>
      <listitem>
       <para>
-       Privilège et possession&nbsp;: <command>GRANT</command>, <command>REVOKE</command>,
+       Droits et propriété&nbsp;: <command>GRANT</command>, <command>REVOKE</command>,
        <command>REASSIGN</command>
       </para>
      </listitem>
@@ -2446,7 +2446,7 @@ LOG:  database system is ready to accept read only connections
     parce que les informations simples qu'il vérifie existent.
     Le script de supervision <productname>check_postgres</productname> fonctionnera aussi,
     même si certaines valeurs retournées pourraient être différentes ou sujettes à confusion.
-    Par exemple, la date de dernier vacuum ne sera pas mise à jour, puis-qu'aucun vacuum ne se déclenche
+    Par exemple, la date de dernier vacuum ne sera pas mise à jour, puisqu'aucun vacuum ne se déclenche
     sur le standby. Les vacuums s'exécutant sur le primaire envoient toujours leurs modifications
     au standby.
    </para>
@@ -2520,7 +2520,7 @@ LOG:  database system is ready to accept read only connections
    <para>
     En fonctionnement normal (pas en restauration), si vous exécutez
     <command>DROP USER</command> ou <command>DROP ROLE</command>
-    pour un rôle ayant le privilège LOGIN alors que cet utilisateur est toujours
+    pour un rôle ayant l'attribut LOGIN alors que cet utilisateur est toujours
     connecté alors rien ne se produit pour cet utilisateur connecté &mdash; il reste connecté. L'utilisateur
     ne peut toutefois pas se reconnecter. Ce comportement est le même en récupération, un
     <command>DROP USER</command> sur le primaire ne déconnecte donc pas cet utilisateur sur le standby.

postgresql/ref/pgbench.xml

@@ -2326,12 +2326,12 @@ f(x) = PHI(2.0 * parameter * (x - mu) / (max - min + 1)) /
    journaux utilisent un format quelque peu différent :
 
 <synopsis>
-<replaceable>début_intervalle</replaceable> <replaceable>nombre_de_transations</replaceable>&zwsp; <replaceable>somme_latence</replaceable> <replaceable>somme_latence_2</replaceable> <replaceable>latence_minimum</replaceable> <replaceable>latence_maximum</replaceable>&zwsp; <optional> <replaceable>somme_retard</replaceable> <replaceable>somme_retard_2</replaceable> <replaceable>retard_min</replaceable> <replaceable>retard_max</replaceable> <optional> <replaceable>transactions_ignorées</replaceable> </optional> </optional>
+<replaceable>début_intervalle</replaceable> <replaceable>nombre_de_transactions</replaceable>&zwsp; <replaceable>somme_latence</replaceable> <replaceable>somme_latence_2</replaceable> <replaceable>latence_minimum</replaceable> <replaceable>latence_maximum</replaceable>&zwsp; <optional> <replaceable>somme_retard</replaceable> <replaceable>somme_retard_2</replaceable> <replaceable>retard_min</replaceable> <replaceable>retard_max</replaceable> <optional> <replaceable>transactions_ignorées</replaceable> </optional> </optional>
 </synopsis>
 
    où <replaceable>début_intervalle</replaceable> est le début de
    l'intervalle (au format epoch Unix),
-   <replaceable>nombre_de_transations</replaceable> est le nombre de
+   <replaceable>nombre_de_transactions</replaceable> est le nombre de
    transactions dans l'intervalle,
    <replaceable>somme_latence</replaceable> est le cumul des latences dans
    l'intervalle,

postgresql/storage.xml

@@ -84,7 +84,7 @@
      <row>
       <entry><filename>pg_commit_ts</filename></entry>
       <entry>Sous-répertoire contenant des données d'horodatage des
-       validations de transations</entry>
+       validations de transactions</entry>
     </row>
 
      <row>