Quelques corrections après relecture

postgresql/wal.xml

@@ -539,13 +539,13 @@
    checkpoint. Au moment du checkpoint, toutes les
    pages de données modifiées (<foreignphrase>dirty</foreignphrase>)
    sont écrites sur le disque et une
-   entrée spéciale, pour le checkpoint est écrite dans le
+   entrée spéciale, pour le checkpoint, est écrite dans le
    journal. (Les modifications étaient déjà envoyées dans les journaux de
    transactions.)
    En cas de défaillance, la procédure de récupération recherche le
    dernier enregistrement d'un checkpoint
-   pour déterminer le point des journaux
    (enregistrement connus sous le nom de <quote>redo log</quote>)
+   pour déterminer le point des journaux
    à partir duquel il devra lancer l'opération de REDO.
    Toute modification effectuée sur les fichiers de données avant ce point
    a la garantie d'avoir été enregistrée sur disque. Du coup, après un
@@ -630,7 +630,7 @@
    écritures de pages modifiées, leur écriture pendant le checkpoint
    est étalée sur une période de temps. Elle est
    contrôlée par <xref linkend="guc-checkpoint-completion-target"/>,
-   donné comme une fraction de l'intervalle des points de vérification.
+   donné comme une fraction de l'intervalle des checkpoints.
    Le taux d'entrées/sorties est ajusté pour que le checkpoint
    se termine quand la fraction indiquée de
    <varname>checkpoint_timeout</varname> secondes s'est écoulée,
@@ -781,7 +781,7 @@
    certaines plateformes, la résolution d'une requête d'endormissement est de dix
    millisecondes, ce qui implique que toute valeur comprise entre 1 et 10000 pour
    le paramètre <varname>commit_delay</varname> aura le même effet. Notez aussi
-   que,sur certaines plateformes, les opérations d'endormissement
+   que, sur certaines plateformes, les opérations d'endormissement
    peuvent être légèrement plus longues que ce qui a été demandé par le paramètre.
   </para>
 
@@ -841,7 +841,7 @@
    options devraient être identiques en terme de fiabilité, à l'exception de
    <literal>fsync_writethrough</literal>, qui peut parfois forcer une écriture
    du cache disque même quand d'autres options ne le font pas. Néanmoins,
-   savoir quelle est l'option la plus rapide est assez dépendant de la plateforme.
+   connaître l'option la plus rapide est assez dépendant de la plateforme.
    Vous pouvez tester les vitesses des différentes
    options en utilisant le programme <xref
    linkend="pgtestfsync"/>. Notez que ce paramètre est ignoré si
@@ -896,7 +896,7 @@
    chacun d'une taille de 16&nbsp;Mo normalement (cette
    taille pouvant être modifiée en modifiant l'option
    <option>--wal-segsize</option> d'initdb). Chaque fichier est divisé en
-   pages de généralement 8&nbsp;ko (cette taille pouvant être modifiée en
+   pages de généralement 8&nbsp;ko (cette taille pouvant être modifiée
    avec l'option <option>--with-wal-blocksize</option> de
    configure). Les en-têtes d'une entrée de journal sont décrites dans
    <filename>access/xlogrecord.h</filename>&nbsp;; le contenu d'une entrée