Quelques corrections en relisant le patch de Cédric

postgresql/config.xml

@@ -2335,7 +2335,7 @@ block : bloc vidé,  dirty bloc : bloc à vider ?
    <listitem>
     <para>
      Configure le nombre maximum de processus parallèles pouvant être lancé
-     par un seul noeud <literal>Gather</literal> ou <literal>Gather
+     par un seul nœud <literal>Gather</literal> ou <literal>Gather
      Merge</literal>. Les processus parallèles sont pris dans l'ensemble de
      processus établi par <xref
      linkend="guc-max-worker-processes"/>, limité par
@@ -5521,7 +5521,7 @@ SELECT * FROM parent WHERE clef = 2400;</programlisting>
 
        <para>
         Plus spécifiquement, configurer cette valeur à <literal>on</literal>
-        ajoutera un noeud <literal>Gather</literal> au -dessus de tout plan
+        ajoutera un nœud <literal>Gather</literal> au -dessus de tout plan
         d'exécution pour lequel cela semble sain, permettant ainsi à la
         requête d'être exécuté par un processus parallélisé. Même si un
         processus parallélisé n'est pas disponible ou ne peut pas être
@@ -5543,7 +5543,7 @@ SELECT * FROM parent WHERE clef = 2400;</programlisting>
         incluent une ligne de contexte le précisant, mais une configuration de
         ce paramètre à la valeur <literal>regress</literal> supprime cette
         ligne pour que la sortie soit identique à une sortie pour une
-        exécution non parallélisée. De plus, les noeuds
+        exécution non parallélisée. De plus, les nœuds
         <literal>Gather</literal> ajoutés au plan par ce paramètre sont cachés
         dans la sortie <literal>EXPLAIN</literal> pour que la sortie
         corresponde à ce qui serait obtenue si ce paramètre était désactivé

postgresql/custom-scan.xml

@@ -382,7 +382,7 @@ void (*ReInitializeDSMCustomScan) (CustomScanState *node,
                                    void *coordinate);
 </programlisting>
     Ré-initialise la mémoire partagée dynamique requise pour des opérations
-    parallélisées lorsque le noeud du plan pour le parcours personnalisé doit
+    parallélisées lorsque le nœud du plan pour le parcours personnalisé doit
     être réalisé de nouveau. Cette fonction est optionnelle et doit seulement
     être fournie si le fournisseur de ce parcours personnalisé supporte les
     exécutions parallélisées. La pratique recommandée est que cette fonction

postgresql/func.xml

@@ -5269,7 +5269,7 @@ une affaiblissement conceptuel du message original lors de sa traduction... -->
   <literal>print</literal> (caractères affichables avec l'espace),
   <literal>punct</literal> (ponctuation),
   <literal>space</literal> (tout espace blanc),
-  <literal>upper</literal> (lettres en majuscules)p
+  <literal>upper</literal> (lettres en majuscules)
   et <literal>xdigit</literal> (chiffres hexadécimaux).
   Le comportement de classes de caractères standards est généralement cohérent
   parmi les différentes plateformes en ce qui concerne les ensembles ASCII 7
@@ -15647,7 +15647,7 @@ END</synopsis>
 SELECT xmlagg(x) FROM (SELECT x FROM test ORDER BY y DESC) AS tab;
 ]]></screen>
 
-   Attention : cette approche peut échouer si la requête externe contient un
+   Attention&nbsp;: cette approche peut échouer si la requête externe contient un
    traitement supplémentaire, telle qu'une jointure, car cela pourrait causer
    le tri de la sortie de la sous-requête avant le calcul de l'agrégat.
   </para>
@@ -17446,7 +17446,6 @@ AND
          Cette section décrit des fonctions qui peuvent renvoyer plus d'une
          ligne. Les fonctions les plus utilisées dans cette classe sont celles
          générant des séries de données, comme détaillé dans <xref
-         générant des séries de données, comme détaillé dans <xref
          linkend="functions-srf-series"/> et <xref
          linkend="functions-srf-subscripts"/>.  D'autres fonctions plus spécialisées
          sont décrites ailleurs dans ce manuel.
@@ -18355,7 +18354,7 @@ SELECT * FROM pg_ls_dir('.') WITH ORDINALITY AS t(ls,n);
         </entry>
         <entry><type>boolean</type></entry>
         <entry>l'utilisateur courant a-t-il le privilège
-	<parameter>privilège</parameter> sur <parameter>langage</parameter><&nbsp;?/entry>
+	<parameter>privilège</parameter> sur <parameter>langage</parameter>&nbsp;?</entry>
       </row>
       <row>
        <entry><literal><function>has_schema_privilege</function>(<parameter>utilisateur</parameter>,
@@ -20066,7 +20065,7 @@ SELECT collation for ('foo' COLLATE "de_DE");
     <literal>in progress</literal>,
     <literal>committed</literal>, ou <literal>aborted</literal>, sous réserve
     que la transaction soit suffisamment récente pour que le système ait gardé
-    le status du commit de cette transaction. Si elle est trop ancienne
+    le statut du commit de cette transaction. Si elle est trop ancienne
     pour qu'aucune référence à cette transaction ne survive dans le système et que
     l'information du statut ait été supprimée, cette fonction renverra NULL.
     Veuillez notez que les transactions préparées sont affichées comme

postgresql/high-availability.xml

@@ -145,11 +145,11 @@
      <!--
 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 noeuds uniquement les annulations de niveau cache mais pas
+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 
 fois en s'appuyant sur un protocole de verrouillage distribué, de façon à
-ce que les noeuds s'accordent dans un système transactionnel sérialisable.
+ce que les nœuds s'accordent dans un système transactionnel sérialisable.
 
 
 -->
@@ -632,7 +632,7 @@ ce que les noeuds s'accordent dans un système transactionnel sérialisable.
     Il est habituellement préférable de créer les serveurs primaire et de standby
     de façon à ce qu'ils soient aussi similaires que possible, au moins du
     point de vue du serveur de bases de données. En particulier, les chemins
-    associés avec les tablespaces seront passés d'un noeud à l'autre sans conversion, ce qui
+    associés avec les tablespaces seront passés d'un nœud à l'autre sans conversion, ce qui
     implique que les serveurs primaire et de standby doivent avoir les mêmes chemins de montage pour
     les tablespaces si cette fonctionnalité est utilisée. Gardez en tête que si
     <xref linkend="sql-createtablespace"/>
@@ -1533,7 +1533,7 @@ synchronous_standby_names = 'FIRST 2 (s1, s2, s3)'
    nouveau primaire, et que l'ancien primaire redémarre, vous devez avoir
    un mécanisme pour informer l'ancien primaire qu'il n'est plus primaire. C'est aussi
    quelquefois appelé <acronym>STONITH</acronym> (Shoot The Other Node In The Head, ou
-   Tire Dans La Tête De L'Autre Noeud), qui est nécessaire pour éviter les situations où
+   Tire Dans La Tête De L'Autre Nœud), qui est nécessaire pour éviter les situations où
    les deux systèmes pensent qu'ils sont le primaire, ce qui amènerait de la confusion, et
    finalement de la perte de données.
   </para>
@@ -2027,7 +2027,7 @@ if (!triggered)
    <title>Gestion des conflits avec les requêtes</title>
 
    <para>
-    Les noeuds primaire et standby sont de bien des façons faiblement couplés. Des
+    Les nœuds primaire et standby sont de bien des façons faiblement couplés. Des
     actions sur le primaire auront un effet sur le standby. Par conséquent, il y a
     un risque d'interactions négatives ou de conflits entre eux. Le conflit le
     plus simple à comprendre est la performance : si un gros chargement de données a

postgresql/monitoring.xml

@@ -4158,7 +4158,7 @@ référez-vous au <xref linkend="mvcc"/>.
     <row>
      <entry><literal>truncating heap</literal></entry>
      <entry>
-       <command>VACUUM</command> est en cours de tronquage de la table pour
+       <command>VACUUM</command> est en cours de troncage de la table pour
        pouvoir redonner au système d'exploitation les pages vides en fin de
        relation. Ceci survient après le nettoyage des index.
      </entry>

postgresql/protocol.xml

@@ -1701,8 +1701,8 @@ SELECT 1/0;
    Chaque transaction envoyée contient zéro ou plusieurs messages DML (Insert,
    Update, Delete). Dans le cas d'une configuration en cascade, elle peut
    aussi contenir des messages Origin. Le message d'origine indiquait que la
-   transaction avait pour origine un noeud de réplication différent. Comme le
-   noeud de réplication dans le cas d'une réplication logique peut provenir de
+   transaction avait pour origine un nœud de réplication différent. Comme le
+   nœud de réplication dans le cas d'une réplication logique peut provenir de
    n'importe où, le seul identificateur est le nom de l'origine. C'est de la
    responsabilité du receveur de gérer cette information si nécessaire. Le
    message Origin est toujours envoyé avant tout message DML dans la

postgresql/ref/truncate.xml

@@ -137,9 +137,9 @@
    déclenchera les triggers <literal>ON TRUNCATE</literal>. Si des triggers
    <literal>ON TRUNCATE</literal> sont définis sur certaines des tables,
    alors tous les triggers <literal>BEFORE TRUNCATE</literal> sont déclenchés
-   avant que le tronquage n'intervienne, et tous les triggers <literal>AFTER
+   avant que le troncage n'intervienne, et tous les triggers <literal>AFTER
     TRUNCATE</literal> sont déclenchés après la réalisation du dernier
-   tronquage et toutes les séquences sont réinitialisées. Les triggers se
+   troncage et toutes les séquences sont réinitialisées. Les triggers se
    déclencheront dans l'ordre de traitement des
    tables (tout d'abord celles listées dans la commande, puis celles ajoutées
    à cause des cascades).

postgresql/ref/vacuum.xml

@@ -230,7 +230,7 @@ VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ ANALYZE ] [ <replaceable class="paramet
       <literal>vacuum_truncate</literal> a été désactivée pour la table en
       cours de traitement. Configurer cette option à false peut être utile
       pour éviter un verrou <literal>ACCESS EXCLUSIVE</literal> sur la table
-      que le tronquage requiert. Cette option est ignorée si l'option
+      que le troncage requiert. Cette option est ignorée si l'option
       <literal>FULL</literal> est utilisée.
      </para>
     </listitem>