Relecture du workshop sur la v15

dalibo · Jun 7, 2023 · 1f2f811 · 1f2f811
1 parent 18ec7eb
commit 1f2f811
Show file tree

Hide file tree

Showing 23 changed files with 52 additions and 53 deletions.
diff --git a/fr/ws15/150-postgresql_15.md b/fr/ws15/150-postgresql_15.md
@@ -113,7 +113,7 @@ hide_author_in_slide: true
 
 ---
 
-### Plus de checkpoint lors de la création d'une database
+### Plus de checkpoint lors de la création d'une base
 
 <!-- https://gitlab.dalibo.info/formation/workshops/-/issues/177 -->
 !include include/177-plus-de-checkpoint-lors-de-la-creation-d-une-database.md
@@ -403,14 +403,14 @@ https://gitlab.dalibo.info/formation/workshops/-/issues/NUMERO_ISSUE
 
 ---
 
-## Permettre l'usage d'index pour les condition basées sur ^@ et starts_with()
+## Permettre l'usage d'index pour les conditions basées sur ^@ et starts_with()
 
 <!-- https://gitlab.dalibo.info/formation/workshops/-/issues/173 -->
 !include include/173-w15-permettre-l-usage-d-index-pour-les-condition-basees-sur-et-starts_with.md
 
 ---
 
-## Ajout de fonctions d'expression régulières pour la compatibilité avec d'autres SGBD
+## Ajout de fonctions d'expressions régulières pour la compatibilité avec d'autres SGBD
 
 <!-- https://gitlab.dalibo.info/formation/workshops/-/issues/175 -->
 !include include/175-ajout-de-fonctions-d-expression-regulieres-pour-la-compatibilite-avec-d-autres-sgbd.md

diff --git a/fr/ws15/include/149-icu.md b/fr/ws15/include/149-icu.md
@@ -148,7 +148,7 @@ La version 15 de PostgreSQL rend possible l'utilisation d'ICU pour gérer les
 collations pour l'ensemble de l'instance ou d'une base de données.
 
 Les commandes  `initdb` et `createdb` disposent désormais de deux nouvelles
-option `--locale-provider={icu|libc}` et `--icu-locale=LOCALE` pour spécifier
+options `--locale-provider={icu|libc}` et `--icu-locale=LOCALE` pour spécifier
 la collation ICU utilisée pour les nouvelles instances.
 
 ```bash

diff --git a/fr/ws15/include/150-archive_library-module-basic-archive.md b/fr/ws15/include/150-archive_library-module-basic-archive.md
@@ -36,9 +36,9 @@ l'établissement d'une connexion à un serveur distant. Il pourrait également
 accumulation de WAL en attente d'archivage.
 
 L'écriture d'un module d'archivage est décrite dans la documentation. Il faut
-pour cela écrire un programme en C, en plus de requérir des compétences
+pour cela écrire un programme en C. En plus de nécessiter des compétences
 particulières, les chances de planter le serveur sont grandes en cas de bug. Il
-semble donc plus raisonnable de s'appuyer et participer à des projets
+semble donc plus raisonnable de s'appuyer et de participer à des projets
 communautaires. Les outils de sauvegardes comme pgBackRest ou Barman vont sans
 doute également s'emparer du sujet.
 

diff --git a/fr/ws15/include/152-backup-targets.md b/fr/ws15/include/152-backup-targets.md
@@ -70,7 +70,7 @@ et `--target=server` sont spécifiés, l'erreur suivante est affichée.
 pg_basebackup: error: cannot specify both format and backup target
 ```
 
-Il est prévu de pouvoir étendre le fonctionnement `pg_basebackup` en ajoutant
+Il est prévu de pouvoir étendre le fonctionnement de `pg_basebackup` en ajoutant
 de nouveaux types de cibles. Le module de test `basebackup_to_shell` est fourni
 à titre d'exemple. Il permet d'exécuter une commande qui prend en entrée
 standard un fichier généré par la sauvegarde.

diff --git a/fr/ws15/include/155-compression-lz4-et-zstandard.md b/fr/ws15/include/155-compression-lz4-et-zstandard.md
@@ -41,7 +41,7 @@ Les commits sur ce sujet sont :
 
 <div class="notes">
 
-PostgreSQL permet désormais d'utiliser les algorithmes de compressions _LZ4_,
+PostgreSQL permet désormais d'utiliser les algorithmes de compression _LZ4_,
 _Zstandard_ en plus de  _gzip_ pour la compression des sauvegardes, des WAL et
 des écritures de page complètes.
 
@@ -214,7 +214,7 @@ Si le format `tar` est spécifié (`--format=t` / `Ft`) avec `gzip`, `lz4` et
 ou `.zst`.
 
 Dans cet exemple d'une compression avec `gzip`, on voit que `pg_wal.tar` est
-compressé et que l'extension des fichiers compressé est `.gz`.
+compressé et que l'extension des fichiers compressés est `.gz`.
 
 ```bash
 $ pg_basebackup -Ft --compress=gzip --pgdata tgzip
@@ -225,7 +225,7 @@ backup_manifest base.tar.gz pg_wal.tar.gz
 ```
 
 Exemple d'une compression avec `lz4`, on voit que `pg_wal.tar` n'est pas
-compressé et que l'extension des fichiers compressé est `.lz4`.
+compressé et que l'extension des fichiers compressés est `.lz4`.
 
 ```bash
 $ pg_basebackup -Ft --compress=lz4 --pgdata tlz4 --progress
@@ -236,7 +236,7 @@ backup_manifest base.tar.lz4 pg_wal.tar
 ```
 
 Exemple d'une compression avec `zstd`, on voit que `pg_wal.tar` n'est pas
-compressé et que l'extension des fichiers compressé est `.zst`.
+compressé et que l'extension des fichiers compressés est `.zst`.
 
 ```bash
 $ pg_basebackup -Ft --compress=zstd --pgdata tzstd --progress
@@ -351,12 +351,12 @@ supportés par PostgreSQL est `pg_receivewal`. Là aussi, l'option
 Le principe est le même que pour `pg_basebackup` à quelques différences près :
 
 * `pg_receivewal` compresse forcément les WAL côté client ;
-* les algorithmes de compression disponible sont `gzip` et `lz4`. Cette
+* les algorithmes de compression disponibles sont `gzip` et `lz4`. Cette
   évolution permettra donc d'avoir le choix entre taux de compression (`gzip`)
   et vitesse de compression (`lz4`).
 
 La compression par défaut est `gzip`, les fichiers produits se terminent donc
-pas l'extension `.gz`. Le niveau de compression peut être ajouté après la
+par l'extension `.gz`. Le niveau de compression peut être ajouté après la
 méthode de compression sous forme d'un entier ou avec l'ensemble clé valeur
 `level=nombre entier`.
 

diff --git a/fr/ws15/include/156-journalisation_checkpoints_et_autovacuum.md b/fr/ws15/include/156-journalisation_checkpoints_et_autovacuum.md
@@ -22,8 +22,8 @@ https://www.postgresql.org/message-id/flat/CALj2ACX-rW_OeDcp4gqrFUAkf1f50Fnh138d
 
 **`log_checkpoints`**
 
-Le paramètre `log_checkpoints` est désormais à `on` par défaut, chaque 
-`CHECKPOINT` sera par conséquent journalisé dans les traces de l'instance.
+Le paramètre `log_checkpoints` est désormais à `on` par défaut. Chaque 
+`CHECKPOINT` sera par conséquent rapporté dans les traces de l'instance.
 
 Les traces générées par  ce paramètre contiennent des informations sur la durée
 des `CHECKPOINT` et sur les écritures effectuées :
@@ -71,4 +71,4 @@ sur les opérations de `VACUUM` et `ANALYZE` exécutées par l'_autovacuum_ :
 ```
 
 
-</div>
+</div>
diff --git a/fr/ws15/include/157-traces-au-format-json.md b/fr/ws15/include/157-traces-au-format-json.md
@@ -89,7 +89,7 @@ spécifiques dans les traces, par exemple pour n'afficher que les erreurs :
 ```
 
 Les données peuvent également être chargées dans une table. Il n'est pas possible
-d'utiliser `COPY` directement pour cela car les caractère d'échappement disparaissent.
+d'utiliser `COPY` directement pour cela car les caractères d'échappement disparaissent.
 
 ```
 postgres=# CREATE TABLE pglog( data jsonb);
@@ -102,4 +102,4 @@ postgres=# SELECT data->>'timestamp' AS starttime FROM pglog WHERE data ->> 'mes
  2022-08-19 16:47:48.412 CEST
 (1 row)
 ```
-</div>
+</div>
diff --git a/fr/ws15/include/159_nouvelle_vue_pg_ident_file_mappings.md b/fr/ws15/include/159_nouvelle_vue_pg_ident_file_mappings.md
@@ -20,7 +20,7 @@ Discussion
 
 De façon similaire à la vue `pg_hba_file_rules`, la nouvelle vue système `pg_ident_file_mappings` donne 
 un résumé du fichier de configuration `pg_ident.conf`. En plus des informations contenues dans le fichier 
-`pg_ident.conf`, elle va fournir une colonne `error` qui va permettre de vérifier le fonctionnement de la 
+`pg_ident.conf`, elle fournit une colonne `error` qui va permettre de vérifier le fonctionnement de la 
 configuration avant application ou de diagnostiquer un éventuel problème.
 
 Cette vue n'intervient que sur le contenu actuel du fichier, et non pas sur ce qui a pu être chargé par 

diff --git a/fr/ws15/include/160_guc_shared_memory_size_and_shared_memory_size_in_huge_pages.md b/fr/ws15/include/160_guc_shared_memory_size_and_shared_memory_size_in_huge_pages.md
@@ -77,6 +77,6 @@ postgres -C shared_memory_size_in_huge_pages -D $PGDATA
 ```
 
 On peut donc dorénavant savoir combien de mémoire partagée et de _Huge Pages_
-le système à besoin avant de démarrer une instance PostgreSQL.
+le système a besoin avant de démarrer une instance PostgreSQL.
 
 </div> 
diff --git a/fr/ws15/include/162_grant_pour_parametrage_via_set_et_alter_system.md b/fr/ws15/include/162_grant_pour_parametrage_via_set_et_alter_system.md
@@ -12,7 +12,7 @@ Discussion
 <div class="slide-content">
 
 * Apparition de deux nouveaux privilèges :
-  + `SET` : permet de modifier les paramètres avec le context `superuser`
+  + `SET` : permet de modifier les paramètres avec le contexte `superuser`
   + `ALTER SYSTEM` : permet à un utilisateur non `superuser` de modifier des paramètres avec `ALTER SYSTEM SET ...`
 * Donne des droits par rôle et par paramètre
 * Nouvelle table système `pg_parameter_acl` qui stocke la configuration 

diff --git a/fr/ws15/include/165_nouvelle_variable_d_environnement_psql_watch_pager.md b/fr/ws15/include/165_nouvelle_variable_d_environnement_psql_watch_pager.md
@@ -42,7 +42,7 @@ Thu 18 Aug 2022 02:12:00 PM CEST (every 1s)
 Afin de faciliter la lecture du résultat des requêtes exécutées de cette manière, il 
 est maintenant possible de définir un _pager_ via la variable d'environnement `PSQL_WATCH_PAGER`.
 
-N'importe quel _pager_ peut-être utilisé. Cependant, seul _pspg_ semble pour le moment réussir à interpréter correctement 
+N'importe quel _pager_ peut être utilisé. Cependant, seul _pspg_ semble pour le moment réussir à interpréter correctement 
 le flux renvoyé par la commande `\watch`. Des _pager_ traditionnels peuvent être utilisés (`less` par exemple), 
 mais le résultat n'est pas particulièrement pratique à analyser et il finit généralement par être inutilisable.
 

diff --git a/fr/ws15/include/167-ws15-ajout-de-l-option-config-file-a-pg_rewind.md b/fr/ws15/include/167-ws15-ajout-de-l-option-config-file-a-pg_rewind.md
@@ -19,11 +19,11 @@ Discussion
 <div class="notes">
 
 L'option `-c/--restore-target-wal` ajoutée en version 13 permet d'utiliser la
-commande de restauration des archives (`restore_command`) stockées dans le
+commande de restauration des archives (`restore_command`) stockée dans le
 fichier de configuration de l'instance pour récupérer les WAL nécessaires à
 l'opération de _rewind_, s'ils ne sont plus dans le répertoire `pg_wal`.
 
-Ce mode de fonctionnement pose problème pour les installations ou les fichiers
+Ce mode de fonctionnement pose problème pour les installations où les fichiers
 de configuration de PostgreSQL ne sont pas stockés dans le répertoire de
 données de l'instance. C'est par exemple le cas par défaut sur les
 installations DEBIAN. Sur ce genre d'installation, le fichier de

diff --git a/...include/168_les_donnees_publiees_peuvent_etre_filtrees_avec_une_clause_where.md b/...include/168_les_donnees_publiees_peuvent_etre_filtrees_avec_une_clause_where.md
@@ -38,7 +38,7 @@ sont également inutilisables.
 Si une publication ne publie que des ordres INSERT, il n'y a pas de limitation sur les colonnes
 utilisées dans le filtre. En revanche, si la publication concerne les ordres UPDATE et DELETE,
 il faut que les colonnes du filtre fassent partie de l'identité de réplica. Cela signifie que
-ces colonnes doivent faire partie de la clé primaire si `` [`REPLICA IDENTITY`](https://www.postgresql.org/docs/current/logical-replication-publication.html) ``
+ces colonnes doivent faire partie de la clé primaire si [REPLICA IDENTITY](https://www.postgresql.org/docs/current/logical-replication-publication.html) ``
 est laissé à sa valeur par défaut. Si un index unique est créé et utilisé pour la clause
 `REPLICA IDENTITY USING INDEX`, ces colonnes doivent en faire partie. Enfin, si 
 `REPLICA IDENTITY` est valorisé à `FULL`, n'importe quelle colonne peut faire partie du filtre.
@@ -65,7 +65,7 @@ Voici comment est mis en place le filtre :
   et sont répliqués depuis PostgreSQL 11 ;
 - les `INSERT` et les `DELETE` sont répliqués normalement du moment que 
   le filtre est validé ;
-- les UPDATE sont plus compliqué. Les exemples suivant décrivent les
+- les UPDATE sont plus compliqués. Les exemples suivant décrivent les
   trois cas de figure et la façon dont PostgreSQL les gère. 
 
   ```sql

diff --git a/...on-du-comportement-des-cles-etrangere-lors-de-mises-a-jour-qui-deplacent-des.md b/...on-du-comportement-des-cles-etrangere-lors-de-mises-a-jour-qui-deplacent-des.md
@@ -33,9 +33,9 @@ En version 15, le trigger posé par la contrainte de clé étrangère ne se
 déclenche plus sur le `DELETE` exécuté sur la partition, mais sur un `UPDATE`
 exécuté sur la table mère. Cela permet d'obtenir le comportement attendu.
 
-L'implémentation choisie à une limitation : elle ne fonctionne que si la
+L'implémentation choisie a une limitation : elle ne fonctionne que si la
 contrainte de clé étrangère concerne la table partitionnée. Cela ne devrait pas
-être un facteur limitant, en effet, il est rare d'avoir des clés étrangères
+être un facteur limitant. En effet, il est rare d'avoir des clés étrangères
 différentes qui pointent vers les différentes partitions. On trouve
 généralement plutôt une clé étrangère qui pointe vers une ou plusieurs
 colonnes de la table partitionnée dans son ensemble.

diff --git a/fr/ws15/include/172-ajout-de-la-commande-sql-merge.md b/fr/ws15/include/172-ajout-de-la-commande-sql-merge.md
@@ -313,7 +313,7 @@ La commande `MERGE` fonctionne également avec les _triggers_ :
 **INSERT ON CONFLICT vs MERGE**
 
 La version 9.5 a vu l'arrivée de la commande `INSERT ON CONFLICT` qui permet
-d'exécuter une action lorsque une erreur de violation de contrainte d'unicité
+d'exécuter une action lorsqu'une erreur de violation de contrainte d'unicité
 ou d'exécution est détectée. Le cas d'utilisation le plus fréquent est la
 réalisation d'un `UPSERT` (`INSERT` ou `UPDATE` atomique). On remarque ici que
 les fonctionnalités couvertes par la commande `MERGE` se recoupe en partie mais

diff --git a/...3-w15-permettre-l-usage-d-index-pour-les-condition-basees-sur-et-starts_with.md b/...3-w15-permettre-l-usage-d-index-pour-les-condition-basees-sur-et-starts_with.md
@@ -18,7 +18,7 @@ Les commits sur ce sujet sont :
 
 <div class="notes">
 
-Le planificateur est désormais capable de traiter la fonction `stars_with()` et
+Le planificateur est désormais capable de traiter la fonction `starts_with()` et
 l'opérateur équivalent `^@` de la même manière que l'expression `chaine LIKE
 'foo%'`. Le prédicat est transformé en deux conditions `>=` et `<` qui sont
 indexables si la collation est `C`.

diff --git a/...e-fonctions-d-expression-regulieres-pour-la-compatibilite-avec-d-autres-sgbd.md b/...e-fonctions-d-expression-regulieres-pour-la-compatibilite-avec-d-autres-sgbd.md
@@ -7,20 +7,20 @@ Les commits sur ce sujet sont :
 
 <div class="slide-content">
 
- * nouvelles fonctions :
+ * Nouvelles fonctions :
    + `regexp_count()`
    + `regexp_instr()`
    + `regexp_like()`
    + `regexp_substr()`
- * fonction améliorée :
+ * Fonction améliorée :
    + `regexp_replace()`
 
 </div>
 
 <div class="notes">
 
 Les [fonctions] `regexp_count()`, `regexp_instr()`, `regexp_like()` et `regexp_substr()`
-ont été ajouté à PostgreSQL afin d'augmenter la compatibilité avec les autres
+ont été ajoutées à PostgreSQL afin d'augmenter la compatibilité avec les autres
 SGBD et de faciliter la réalisation de certaines tâches. La fonction
 `regexp_replace()` a également été étendue.
 

diff --git a/fr/ws15/include/177-plus-de-checkpoint-lors-de-la-creation-d-une-database.md b/fr/ws15/include/177-plus-de-checkpoint-lors-de-la-creation-d-une-database.md
@@ -28,8 +28,8 @@ réaliser un checkpoint, copier les fichiers de la base de référence, puis fai
 un nouveau checkpoint.
 
 Le premier checkpoint permet de s'assurer que les données des buffers sales
-sont sur écrits sur disque, y compris ceux des tables _UNLOGGED_. Il permet
-aussi de s'assurer que les commandes de suppressions de fichiers ont été
+sont écrits sur disque, y compris ceux des tables _UNLOGGED_. Il permet
+aussi de s'assurer que les commandes de suppression de fichiers ont été
 traitées, ce qui évite la disparition d'un fichier pendant sa copie. 
 
 La copie des fichiers de la base de référence est tracée dans les WAL sous forme

diff --git a/...ackground-writer-et-du-checkpointer-lors-d-une-recuperation-suite-a-un-crash.md b/...ackground-writer-et-du-checkpointer-lors-d-une-recuperation-suite-a-un-crash.md
@@ -16,7 +16,7 @@ Les commits sur ce sujet sont :
 
 <div class="notes">
 
-Le checkpointer et le bgwriter son désormais lancés pendant la phase de _crash
+Le checkpointer et le bgwriter sont désormais lancés pendant la phase de _crash
 recovery_ de la même manière qu'on le fait pour la réplication. L'objectif est
 de limiter la duplication de code en supprimant ce cas particulier.
 Il est possible que, dans certains cas, cela améliore les performances. Par

diff --git a/fr/ws15/include/179-preservation-de-l-oid-des-relfilenodes-dans-pg_upgrade.md b/fr/ws15/include/179-preservation-de-l-oid-des-relfilenodes-dans-pg_upgrade.md
@@ -41,7 +41,7 @@ Le _database oid_ est l'identifiant unique d'une base de données. Il est
 utilisé pour nommer le répertoire qui regroupe toutes les données d'une base
 de données dans un tablespace.
 
-Ce changement permet donc limiter les changements de noms de fichiers,
+Ce changement permet donc de limiter les changements de noms de fichiers,
 répertoires et lien symboliques suite à une montée de version avec
 `pg_upgrade`. Les bénéfices sont multiples :
 
@@ -85,4 +85,4 @@ référencé ce qui est le principal.
 ça ne me semble pas indispensable donc je le squeeze pour plus d'info voir le
 patch dont le lien est la haut.
 
--->
+-->
diff --git a/...e/180-permettre-le-pre-fetch-du-contenu-des-fichiers-wal-pendant-le-recovery.md b/...e/180-permettre-le-pre-fetch-du-contenu-des-fichiers-wal-pendant-le-recovery.md
@@ -35,8 +35,8 @@ blocs.
 Cette nouvelle fonctionnalité devrait accélérer grandement la recovery suite à
 un crash, une restauration ou lorsque la réplication utilise le _log shipping_.
 
-Précédemment, pour réaliser ce genre d'optimisation, il fallait passer des
-outils externes comme [pg_prefaulter] qui a servi d'inspiration à cette
+Précédemment, pour réaliser ce genre d'optimisation, il fallait passer par des
+outils externes comme [pg_prefaulter] qui a servi d'inspiration pour cette
 fonctionnalité.
 
 [pg_prefaulter]: https://github.com/TritonDataCenter/pg_prefaulter
@@ -169,7 +169,7 @@ LOG:  checkpoint complete:
 LOG:  database system is ready to accept connections
 ```
 
-On voit que le _redo_ a duré 11.46s au lieu de 1min 8s du test lors du
+On voit que le _redo_ a duré 11.46s au lieu de 1min 8s lors du test
 précédent.
 
 Des statistiques peuvent être lues dans la nouvelle vue
@@ -193,22 +193,21 @@ io_depth       | 0
 
 La signification des colonnes est la suivante :
 
-* prefetch : Nombre de blocs récupérés avec le prefetch parce que le les blocs
-  ne sont pas le buffer pool ;
+* prefetch : Nombre de blocs récupérés avec le prefetch parce que les blocs
+  ne sont pas dans le buffer pool ;
 * hit : Nombre de blocs qui n'ont pas été récupérés avec le prefetch car ils
   étaient déjà dans le buffer pool ;
 * skip_init : Nombre de blocs qui n'ont pas été récupérés avec le prefetch car
-  ils auraient été initialisé à zéro ;
+  ils auraient été initialisés à zéro ;
 * skip_init : Nombre de blocs qui n'ont pas été récupérés avec le prefetch car
   ils n'existaient pas encore ;
 * skip_fpw : Nombre de blocs qui n'ont pas été récupérés avec le prefetch car
-  une lecture de page complête était incluse dans le WAL ;
+  une lecture de page complète était incluse dans le WAL ;
 * skip_rep : Nombre de blocs qui n'ont pas été récupérés avec le prefetch car
-  elles ont déjà été préfetchées récemment ;
-* wal_distance : De combien de bytes le prefetcher est entrain de lire en
-  avance ; block_distance : De combien de blocs le prefetcher est en train de
+  ils ont déjà été préfetchés récemment ;
+* wal_distance : nombre d'octets en cours de lecture par le prefetcher ;
+* block_distance : nombre de blocs en cours de lecture par le prefetcher ;
   lire en avance ;
-* io_depth : Combien de prefetch ont été initialisés mais ne sont pas encore
-  terminés.
+* io_depth : nombre de prefetchs initialisés mais non terminés.
 
 </div>
diff --git a/...5/include/181-pg_stat_statements-ajout-de-metriques-supplementaires-pour-jit.md b/...5/include/181-pg_stat_statements-ajout-de-metriques-supplementaires-pour-jit.md
@@ -18,7 +18,7 @@ Les commits sur ce sujet sont :
 
 <div class="notes">
 
-La vue [`pg_stat_statement`], fournie avec l'extension éponyme, s'est vue
+La vue [pg_stat_statement], fournie avec l'extension éponyme, s'est vue
 ajouter une série de compteurs permettant de suivre l'activité du compilateur à la volée (JIT) sur un
 serveur. Ces informations sont très intéressantes car jusqu'à maintenant, il n'y
 avait aucun moyen de superviser l'utilisation de JIT. Bien souvent, les seules
@@ -58,6 +58,6 @@ Des informations concernant les temps d'accès aux fichiers temporaires ont
 
 Suite à l'ajout de ces fonctionnalités, l'extension passe en version 1.10.
 
-[`pg_stat_statements`]: https://www.postgresql.org/docs/15/pgstatstatements.html
+[pg_stat_statements]: https://www.postgresql.org/docs/15/pgstatstatements.html
 
 </div>
diff --git a/fr/ws15/include/186-psql-ne-supporte-plus-9-1-et-versions-anterieures.md b/fr/ws15/include/186-psql-ne-supporte-plus-9-1-et-versions-anterieures.md
@@ -17,7 +17,7 @@ Les sources pour ce sujet sont :
 <div class="notes">
 
 Cette version contient des modifications de catalogue qui impactent la 
-compatibilité avec d'anciennes version. Le client `psql` ne supporte
+compatibilité avec d'anciennes versions. Le client `psql` ne supporte
 ainsi plus d'accéder à des serveurs de versions 9.1 ou antérieures.
 
 Les outils `pg_dump` et `pg_dumpall` ne supportent plus d'effectuer des exports de