Skip to content

Commit

Permalink
Réindentation
Browse files Browse the repository at this point in the history
  • Loading branch information
@gleu
gleu committed Nov 23, 2020
1 parent b9d1dcb commit e43a0ac
Show file tree
Hide file tree
Showing 179 changed files with 54,573 additions and 54,573 deletions.
8 changes: 4 additions & 4 deletions postgresql/acronyms.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -410,10 +410,10 @@
<term><acronym>LSN</acronym></term>
<listitem>
<para>
Log Sequence Number, Numéro de séquence dans les journaux de
transaction. Voir <link
linkend="datatype-pg-lsn"><type>pg_lsn</type></link> et <link
linkend="wal-internals">Vue interne des journaux de transaction</link>.
Log Sequence Number, Numéro de séquence dans les journaux de
transaction. Voir <link
linkend="datatype-pg-lsn"><type>pg_lsn</type></link> et <link
linkend="wal-internals">Vue interne des journaux de transaction</link>.
</para>
</listitem>
</varlistentry>
Expand Down
228 changes: 114 additions & 114 deletions postgresql/amcheck.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -56,9 +56,9 @@

<listitem>
<para>
<function>bt_index_check</function> que sa cible, un index B-Tree,
<function>bt_index_check</function> que sa cible, un index B-Tree,
respecte une vériété de propriétés invariables. Exemple d'utilisation :
<screen>
<screen>
test=# SELECT bt_index_check(c.oid), c.relname, c.relpages
FROM pg_index i
JOIN pg_opclass op ON i.indclass[0] = op.oid
Expand All @@ -71,7 +71,7 @@ AND c.relpersistence != 't'
-- La fonction peut renvoyer une erreur si cela est omis :
AND i.indisready AND i.indisvalid
ORDER BY c.relpages DESC LIMIT 10;
bt_index_check | relname | relpages
bt_index_check | relname | relpages
----------------+---------------------------------+----------
| pg_depend_reference_index | 43
| pg_depend_depender_index | 40
Expand All @@ -84,7 +84,7 @@ ORDER BY c.relpages DESC LIMIT 10;
| pg_amop_opr_fam_index | 5
| pg_amop_fam_strat_index | 5
(10 rows)
</screen>
</screen>
Cet exemple montre une session qui effectue une vérification des dix plus
gros index sur le catalogue dans la base de données <quote>test</quote>.
Puisqu'aucune erreur n'est retournée, tous les index testés semblent être
Expand Down Expand Up @@ -169,122 +169,122 @@ ORDER BY c.relpages DESC LIMIT 10;
<sect2>
<title>Utiliser <filename>amcheck</filename> efficacement</title>

<para>
<filename>amcheck</filename> peut être efficace pour détecter différents
types de modes d'échec que les <link
linkend="app-initdb-data-checksums"><application>sommes de contrôle de
page </application></link> n'arriveront jamais à détecter. Cela inclut :
<para>
<filename>amcheck</filename> peut être efficace pour détecter différents
types de modes d'échec que les <link
linkend="app-initdb-data-checksums"><application>sommes de contrôle de
page </application></link> n'arriveront jamais à détecter. Cela inclut :

<itemizedlist>
<listitem>
<para>
Les incohérences structurelles causée par des implémentations incorrectes
de classe d"opérateur.
</para>
<para>
Cela inclue également des problèmes causés par le changement des règles de
comparaison des collations du système d'exploitation. Les comparaisons
des données d'un type ayant une collation comme <type>text</type> doivent
être immuables (tout comme toutes les autres comparaisons utilisées pour
les parcours d'index B-Tree doivent être immuables), ce qui implique que
les règles de collation du système d'exploitation ne dois jamais changer.
Bien que cela soit rare, des mises à jour des règles des collations du
système d'exploitation peuvent causer ces problèmes. Plus généralement,
une incohérence dans l'ordre de collation entre un serveur primaire et son
réplicat est impliqué, peut-être parce que la version
<emphasis>major</emphasis> du système d'exploitation utilisée était
incohérente. De telles incohérences ne surviendront généralement que sur
des serveur secondaires, et ne pourront par conséquent être détectées que
sur des serveurs secondaires.
</para>
<para>
Si un tel problème survient, il se peut que cela n'affecte par
individuellement chaque index qui utilise le tri d'une collation affectée,
tout simplement car les valeurs <emphasis>indexée</emphasis> pourraient
avoir le même ordre de tri absolu indépendamment des incohérences
comportementales. Voir
<xref linkend="locale"/> et <xref linkend="collation"/> pour plus de
détails sur comment <productname>PostgreSQL</productname> utilise les
locales et collations du système d'exploitation.
</para>
</listitem>
<listitem>
<itemizedlist>
<listitem>
<para>
Une corruption causée par un hypothétique bug non encore découvert dans
l'implémentation associée à la méthode d'accès ou au code effectuant le
tri.
</para>
<para>
La vérification automatique de l'intégrité structurelle des index joue un
rôle sur les principaux tests des fonctionnalités nouvelles ou proposées
dans <productname>PostgreSQL</productname> qui pourraient possiblement
autoriser l'introduction d'incohérence logiques. Une stratégie de test
évidente est d'appeler les fonctions d'<filename>amcheck</filename> de
manière continue en même temps que les tests de régression standard sont
lancés. Voir <xref
linkend="regress-run"/> pour plus de détail sur commencer lancer les
tests.
</para>
</listitem>
<listitem>
<para>
Les défauts du système de fichiers ou du sous système de stockage quand
les vérifications des sommes de contrôles ne sont pas activées.
</para>
<para>
Il est à noter que <filename>amcheck</filename> examine les pages telles
que représentées dans des tampons en mémoire partagée au moment de la
vérification s'il y a seulement un accès en mémoire partagée lors de
l'accès au bloc. Par conséquent, <filename>amcheck</filename> n'examine
pas forcément les données lues depuis le système de fichiers au moment de
la vérification. De plus, quand les sommes de contrôles sont activées,
<filename>amcheck</filename> peut lever une erreur de somme de contrôle
incorrecte quand un block corrompu est lu vers un tampon.
</para>
</listitem>
<listitem>
<para>
Les corruptions causée par une mémoire RAM défaillante, et plus largement
le sous système mémoire.
</para>
<para>
<productname>PostgreSQL</productname> ne protège pas contre les erreurs
mémoire corrigibles et il est supposé que vous utilisez de la mémoire RAM
utilisant le standard de l'instrie Error Correcting Codes (ECC) ou une
meilleure protection. Cependant, la mémoire ECC est typiquement immunisée
uniquement contre les erreurs d'un seul bit, et il ne faut pas partir du
principe que ce type de mémoire fournit une protection
<emphasis>absolue</emphasis> contre les défaillances résultant en une
corruption mémoire.
</para>
</listitem>
</itemizedlist>
De manière générale, <filename>amcheck</filename> ne peut que prouver la
présence d'une corruption; il ne peut pas en prouver l'absence.
</para>
Les incohérences structurelles causée par des implémentations incorrectes
de classe d"opérateur.
</para>
<para>
Cela inclue également des problèmes causés par le changement des règles de
comparaison des collations du système d'exploitation. Les comparaisons
des données d'un type ayant une collation comme <type>text</type> doivent
être immuables (tout comme toutes les autres comparaisons utilisées pour
les parcours d'index B-Tree doivent être immuables), ce qui implique que
les règles de collation du système d'exploitation ne dois jamais changer.
Bien que cela soit rare, des mises à jour des règles des collations du
système d'exploitation peuvent causer ces problèmes. Plus généralement,
une incohérence dans l'ordre de collation entre un serveur primaire et son
réplicat est impliqué, peut-être parce que la version
<emphasis>major</emphasis> du système d'exploitation utilisée était
incohérente. De telles incohérences ne surviendront généralement que sur
des serveur secondaires, et ne pourront par conséquent être détectées que
sur des serveurs secondaires.
</para>
<para>
Si un tel problème survient, il se peut que cela n'affecte par
individuellement chaque index qui utilise le tri d'une collation affectée,
tout simplement car les valeurs <emphasis>indexée</emphasis> pourraient
avoir le même ordre de tri absolu indépendamment des incohérences
comportementales. Voir
<xref linkend="locale"/> et <xref linkend="collation"/> pour plus de
détails sur comment <productname>PostgreSQL</productname> utilise les
locales et collations du système d'exploitation.
</para>
</listitem>
<listitem>
<para>
Une corruption causée par un hypothétique bug non encore découvert dans
l'implémentation associée à la méthode d'accès ou au code effectuant le
tri.
</para>
<para>
La vérification automatique de l'intégrité structurelle des index joue un
rôle sur les principaux tests des fonctionnalités nouvelles ou proposées
dans <productname>PostgreSQL</productname> qui pourraient possiblement
autoriser l'introduction d'incohérence logiques. Une stratégie de test
évidente est d'appeler les fonctions d'<filename>amcheck</filename> de
manière continue en même temps que les tests de régression standard sont
lancés. Voir <xref
linkend="regress-run"/> pour plus de détail sur commencer lancer les
tests.
</para>
</listitem>
<listitem>
<para>
Les défauts du système de fichiers ou du sous système de stockage quand
les vérifications des sommes de contrôles ne sont pas activées.
</para>
<para>
Il est à noter que <filename>amcheck</filename> examine les pages telles
que représentées dans des tampons en mémoire partagée au moment de la
vérification s'il y a seulement un accès en mémoire partagée lors de
l'accès au bloc. Par conséquent, <filename>amcheck</filename> n'examine
pas forcément les données lues depuis le système de fichiers au moment de
la vérification. De plus, quand les sommes de contrôles sont activées,
<filename>amcheck</filename> peut lever une erreur de somme de contrôle
incorrecte quand un block corrompu est lu vers un tampon.
</para>
</listitem>
<listitem>
<para>
Les corruptions causée par une mémoire RAM défaillante, et plus largement
le sous système mémoire.
</para>
<para>
<productname>PostgreSQL</productname> ne protège pas contre les erreurs
mémoire corrigibles et il est supposé que vous utilisez de la mémoire RAM
utilisant le standard de l'instrie Error Correcting Codes (ECC) ou une
meilleure protection. Cependant, la mémoire ECC est typiquement immunisée
uniquement contre les erreurs d'un seul bit, et il ne faut pas partir du
principe que ce type de mémoire fournit une protection
<emphasis>absolue</emphasis> contre les défaillances résultant en une
corruption mémoire.
</para>
</listitem>
</itemizedlist>
De manière générale, <filename>amcheck</filename> ne peut que prouver la
présence d'une corruption; il ne peut pas en prouver l'absence.
</para>

</sect2>
<sect2>
<title>Réparer une corruption</title>
<para>
Aucune erreur concernant une corruption remontée par
<filename>amcheck</filename> ne devrait être un faux positif. Dans la
pratique, <filename>amcheck</filename> est plus à même de trouver des bugs
logiciels que des problèmes matériels.
<filename>amcheck</filename> remonte des erreurs dans le cas où des
conditions, par définition, ne devraient jamais arriver, et par conséquent
une analyse minutieuse des erreurs remontées par <filename>amcheck</filename>
est souvent nécessaire.
</para>
<para>
Il n'y a pas de méthode générale pour réparer les problèmes que
<filename>amcheck</filename> détecte. Une explication de la cause principale
menant à ce que la propriété invariable soit violée devrait être étudiée.
<xref linkend="pageinspect"/> pourrait jouer un rôle utile dans le
diagnostique de la corruption qu'<filename>amcheck</filename> détecte. Un
<command>REINDEX</command> pourrait ne pas être efficace pour réparer la
corruption.
</para>
<para>
Aucune erreur concernant une corruption remontée par
<filename>amcheck</filename> ne devrait être un faux positif. Dans la
pratique, <filename>amcheck</filename> est plus à même de trouver des bugs
logiciels que des problèmes matériels.
<filename>amcheck</filename> remonte des erreurs dans le cas où des
conditions, par définition, ne devraient jamais arriver, et par conséquent
une analyse minutieuse des erreurs remontées par <filename>amcheck</filename>
est souvent nécessaire.
</para>
<para>
Il n'y a pas de méthode générale pour réparer les problèmes que
<filename>amcheck</filename> détecte. Une explication de la cause principale
menant à ce que la propriété invariable soit violée devrait être étudiée.
<xref linkend="pageinspect"/> pourrait jouer un rôle utile dans le
diagnostique de la corruption qu'<filename>amcheck</filename> détecte. Un
<command>REINDEX</command> pourrait ne pas être efficace pour réparer la
corruption.
</para>

</sect2>

Expand Down
76 changes: 38 additions & 38 deletions postgresql/array.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -285,38 +285,38 @@ SELECT planning[:][1:1] FROM sal_emp WHERE nom = 'Bill';
------------------------
{{meeting},{training}}
(1 row)
</programlisting>
</para>
</programlisting>
</para>

<para>
Une expression indicée de tableau retourne NULL si le tableau ou une
des expressions est NULL. De plus, NULL est renvoyé si un indice se trouve en
dehors de la plage du tableau (ce cas n'amène pas d'erreur).
Par exemple, si <literal>planning</literal> a les dimensions
<literal>[1:3][1:2]</literal>, faire référence à
<literal>planning[3][3]</literal> donne un
résultat NULL. De la même façon, une référence sur un tableau avec une
valeur d'indices incorrecte retourne une valeur NULL plutôt qu'une erreur.
</para>
<para>
Une expression indicée de tableau retourne NULL si le tableau ou une
des expressions est NULL. De plus, NULL est renvoyé si un indice se trouve en
dehors de la plage du tableau (ce cas n'amène pas d'erreur).
Par exemple, si <literal>planning</literal> a les dimensions
<literal>[1:3][1:2]</literal>, faire référence à
<literal>planning[3][3]</literal> donne un
résultat NULL. De la même façon, une référence sur un tableau avec une
valeur d'indices incorrecte retourne une valeur NULL plutôt qu'une erreur.
</para>

<para>
Une expression de découpage d'un tableau est aussi NULL si, soit le
tableau, soit une des expressions indicées est NULL. Néanmoins, dans
certains cas particuliers comme la sélection d'une partie d'un tableau
complètement en dehors de la plage de ce dernier, l'expression de
cette partie est un tableau vide (zéro dimension) et non pas un tableau
NULL. (Ceci ne correspond pas au comportement sans indice, et est fait
pour des raisons historiques.)
Si la partie demandée surcharge partiellement les limites du
tableau, alors elle est réduite silencieusement à la partie surchargée
au lieu de renvoyer NULL.
</para>
<para>
Une expression de découpage d'un tableau est aussi NULL si, soit le
tableau, soit une des expressions indicées est NULL. Néanmoins, dans
certains cas particuliers comme la sélection d'une partie d'un tableau
complètement en dehors de la plage de ce dernier, l'expression de
cette partie est un tableau vide (zéro dimension) et non pas un tableau
NULL. (Ceci ne correspond pas au comportement sans indice, et est fait
pour des raisons historiques.)
Si la partie demandée surcharge partiellement les limites du
tableau, alors elle est réduite silencieusement à la partie surchargée
au lieu de renvoyer NULL.
</para>

<para>
Les dimensions actuelles de toute valeur de type tableau sont disponibles avec la
fonction <function>array_dims</function>&nbsp;:
<para>
Les dimensions actuelles de toute valeur de type tableau sont disponibles avec la
fonction <function>array_dims</function>&nbsp;:

<programlisting>SELECT array_dims(planning) FROM sal_emp WHERE nom = 'Carol';
<programlisting>SELECT array_dims(planning) FROM sal_emp WHERE nom = 'Carol';

array_dims
------------
Expand Down Expand Up @@ -637,7 +637,7 @@ SELECT * FROM sal_emp WHERE paye_par_semaine &amp;&amp; ARRAY[10000];
La seconde renvoie un tableau avec les indices de toutes les occurrences de la valeur
dans le tableau. Par exemple&nbsp;:

<programlisting>SELECT array_position(ARRAY['sun','mon','tue','wed','thu','fri','sat'], 'mon');
<programlisting>SELECT array_position(ARRAY['sun','mon','tue','wed','thu','fri','sat'], 'mon');
array_positions
-----------------
2
Expand Down Expand Up @@ -758,15 +758,15 @@ SELECT f1[1][-2][3] AS e1, f1[1][-1][5] AS e2
caractères autres que des espaces ne sont pas ignorées.
</para>

<tip>
<para>
La syntaxe du constructeur <literal>ARRAY</literal> (voir <xref
linkend="sql-syntax-array-constructors"/>) est souvent plus facile à utiliser
que la syntaxe de tableau littéral lors de l'écriture des valeurs du tableau
en commandes SQL. Avec <literal>ARRAY</literal>, les valeurs de l'élément individuel
sont écrites comme elles le seraient si elles ne faisaient pas partie d'un tableau.
</para>
</tip>
<tip>
<para>
La syntaxe du constructeur <literal>ARRAY</literal> (voir <xref
linkend="sql-syntax-array-constructors"/>) est souvent plus facile à utiliser
que la syntaxe de tableau littéral lors de l'écriture des valeurs du tableau
en commandes SQL. Avec <literal>ARRAY</literal>, les valeurs de l'élément individuel
sont écrites comme elles le seraient si elles ne faisaient pas partie d'un tableau.
</para>
</tip>
</sect2>

</sect1>

0 comments on commit e43a0ac

Please sign in to comment.