From 63d8f520976622b77025fd156bb080412d646ed5 Mon Sep 17 00:00:00 2001 From: Emmanuelle Helly Date: Thu, 7 Apr 2022 17:07:38 +0200 Subject: [PATCH] Fix some typo --- src/SupportCoursPostgreSQL3.md | 16 ++++++++-------- src/SupportCoursPostgreSQL4.md | 10 +++++----- 2 files changed, 13 insertions(+), 13 deletions(-) diff --git a/src/SupportCoursPostgreSQL3.md b/src/SupportCoursPostgreSQL3.md index c3ce235..eec88c3 100644 --- a/src/SupportCoursPostgreSQL3.md +++ b/src/SupportCoursPostgreSQL3.md @@ -410,7 +410,7 @@ deux types de problèmes: * les lectures **non reproductibles** * les lectures **fantômes**. -A partir du moment ou on tape **BEGIN** on fait « sauter » le mode auto-commit. +A partir du moment où on tape **BEGIN** on fait « sauter » le mode auto-commit. Il faudra donc à un moment ou un autre taper **ROLLBACK** ou **COMMIT** dans ces sessions, ou atteindre un ROLLBACK par un **timeout** de la transaction, ou @@ -425,14 +425,14 @@ la session. le BEGIN a peut-être déjà été modifié.

- Règle #2 : Une transaction sans locks est quasi assurée de provoquer + Règle #2 : Une transaction sans lock est quasi assurée de provoquer des erreurs fonctionnelles. C'est une règle beaucoup trop ignorée (Au point que depuis MySQL 5.1, par exemple, les locks sont automatiques sur les sélections dans les transactions MySQL-- ne cherchez pas ce qui se passe dans MySQL 5.0, c'est instable).

- Règles #3: Attendez vous à ce qu'une transaction puisse être annulée + Règles #3: Attendez-vous à ce qu'une transaction puisse être annulée par le moteur. Pour des problèmes d'isolation ou de deadlock. Votre programme devrait peut-être essayer de jouer les transactions plusieurs fois.

@@ -663,7 +663,7 @@ COMMIT; -- ou ROLLBACK; -------------------------------------------------------------------------------- ### utilisation de locks (for update) -Testons la mise en places de LOCKS avec le mot clef FOR UPDATE ([http://docs.postgresqlfr.org/13/sql-select.html#sql-for-update-share](http://docs.postgresqlfr.org/13/sql-select.html#sql-for-update-share)): +Testons la mise en places de LOCKS avec le mot clef FOR UPDATE ([http://docs.postgresqlfr.org/9.5/sql-select.html#sql-for-update-share](http://docs.postgresqlfr.org/9.5/sql-select.html#sql-for-update-share)):
@@ -1748,7 +1748,7 @@ Nous ne pouvons pas couvrir l'ensemble des outils mis à disposition dans une ba sans l'enregistrer? **Do** permet de **définir à la volée** une fonction pour l'utiliser immédiatement. * **Create Aggregate** : [http://docs.postgresqlfr.org/13/sql-createaggregate.html](http://docs.postgresqlfr.org/13/sql-createaggregate.html) -* **Vues materialisées** (> 9.3): la vue est cachée comme une table réèlle, +* **Vues materialisées** (> 9.3): la vue est cachée comme une table réelle, elle peut être recalculée à la volée `REFRESH MATERIALIZED VIEW nom;`. Gain de temps immense à l'usage (il ne s'agit d'une requête mais bien d'une table). * etc. @@ -1791,7 +1791,7 @@ Ou encore le support natif du type **UUID** avec postgreSQL **13** (extension ** -------------------------------------------------------------------------------- ## 18.3 pg_upgrade, migration 9.x vers 11 -Avant de tester le partionnement sur un PostgreSQL 11, si votre base est installée sur une version 9.x, nous pouvonsla migrer automatiquement vers une version 11. +Avant de tester le partionnement sur un PostgreSQL 11, si votre base est installée sur une version 9.x, nous pouvons la migrer automatiquement vers une version 11. On suppose que vous avez une version de postgresql 11 installée (via un `apt-get install postgresql-11`). Elle tourne donc sur votre machine, sur un port différent (par exemple **5435**). Vérifiez le fichier `pg_hba.conf` de cette instance. @@ -1921,7 +1921,7 @@ Vous pouvez remarquer que les index ont été créés automatiquement sur la sou Si vous générez de l'activité, vous verrez que les sous tables se remplissent. Et si vous altérez à la main la colonne `operation` d'un des enregsitrements de l'audit -vous verrez qu'il change de table de parti onnement. +vous verrez qu'il change de table de partionnement. SELECT count(1),tableoid::regclass FROM commande_audit GROUP by 2 order by 2; @@ -1934,7 +1934,7 @@ vous verrez qu'il change de table de parti onnement.

* une table existante ne peut devenir automatiquement partionnée, il faut surement passer par des migrations de données -* il y a un grand nombre de limites (par exemple les types de foreign keys supportés, les champs utilisés dans les Primary Key, les types de triggers supportés, de la partition par défaut, des création sde sous tables à l'avance). +* il y a un grand nombre de limites (par exemple les types de foreign keys supportés, les champs utilisés dans les Primary Key, les types de triggers supportés, de la partition par défaut, des créations de sous tables à l'avance). * il y a de fortes différences entre les version 10,11 et 12 de PostgreSQL sur les éléments supportés * il faut prendre le temps de bien valider tous les développements (tests unitaires), les indexs, et les choix de partionnements. diff --git a/src/SupportCoursPostgreSQL4.md b/src/SupportCoursPostgreSQL4.md index 5c206ed..3a2542f 100644 --- a/src/SupportCoursPostgreSQL4.md +++ b/src/SupportCoursPostgreSQL4.md @@ -386,7 +386,7 @@ Faisons le point sur les principaux paramètres... si vous utilisez plusieurs rôles cela va aussi augmenter la consommation de connexions. **Pensez à utiliser des pooler de connexions pour des besoins dépassants le milliers de connexions.** -* **superuser_reserved_connections** : Parmi toutes les connexions disponible +* **superuser_reserved_connections** : Parmi toutes les connexions disponibles ce nombre de connexions (3 par défaut) sera réservé au superadmin postgres. Cela vous permettra de vous connecter à postgreSQL y compris au moment des pics. Intégrez dans ce nombre la consommation des membres de l'équipe d'admin et des @@ -522,7 +522,7 @@ J2EE. Donnez lui une machine dédiée, avec aussi des disques rapides et sûrs. Pour la **consommation par processus** le paramètre important est : -* **work_mem** : cela représente la mémoire que le processus à le droit +* **work_mem** : cela représente la mémoire que le processus a le droit d'utiliser pour effectuer ses opérations de hachage et de tris (celles que le explain montre). S'il a besoin de plus de mémoire il devra passer par un **stockage temporaire sur disque** des opérations en cours. La difficulté de ce @@ -555,7 +555,7 @@ importantes de données pourront avoir un work_mem par défaut plus important. * **maintenance_work_mem** : 16MB par défaut, montez à 100MB voir plus. Il s'agit de la mémoire allouée aux processus du superutilisateur effectuant des opérations de maintenance comme les **vacuums** ou les **réindexations**, - les clusters etc. Il n'y a normalement pas de parallélisations de ces tâches + les clusters etc. Il n'y a normalement pas de parallélisation de ces tâches Lors d'un import de données massif, il n'y aura à priori que des connexions destinées à cet import (si vous coupez les autres via le pg_hba.conf par @@ -563,7 +563,7 @@ exemple), pensez à augmenter les valeurs de work_mem et maintenance_work_mem ** -------------------------------------------------------------------------------- -Signalons enfin d'autre paramètres proches de l'utilisation mémoire mais qui +Signalons enfin d'autres paramètres proches de l'utilisation mémoire mais qui sont plus des réglages informatifs: * **effective_io_concurrency** : indiquez le nombre de disque présents sur le @@ -2644,4 +2644,4 @@ l'on trouve encore pour raisons historiques. ### 20.13.8. d'autres? * [https://wiki.postgresql.org/wiki/Performance_Analysis_Tools](https://wiki.postgresql.org/wiki/Performance_Analysis_Tools) -* [https://wiki.postgresql.org/wiki/Monitoring](https://wiki.postgresql.org/wiki/Monitoring) \ No newline at end of file +* [https://wiki.postgresql.org/wiki/Monitoring](https://wiki.postgresql.org/wiki/Monitoring)