Merge pull request #4 from gleu/master

Mise à jour mai 2019

postgresql/btree.xml

@@ -14,7 +14,7 @@
 
  <para>
   <productname>PostgreSQL</productname> inclut une implémentation de la
-  structure standard d'index <acronym>btree</acronym> (<foreignphrase>multi-way binary tree</foreignphrase>)
+  structure standard d'index <acronym>btree</acronym> (<foreignphrase>multi-way balanced tree</foreignphrase>)
   N'importe quel type de données pouvant être trié dans un ordre linéaire
   clairement défini peut être indexé par un index btree.  La seule limitation
   est qu'une entrée d'index ne peut dépasser approximativement un tiers de page

postgresql/config.xml

@@ -5309,35 +5309,15 @@ local0.*    /var/log/postgresql
 
 <variablelist>
 
- <varlistentry id="guc-client-min-messages" xreflabel="client_min_messages">
-  <term><varname>client_min_messages</varname> (<type>enum</type>)</term>
-  <listitem>
-   <indexterm>
-    <primary>paramètre de configuration <varname>client_min_messages</varname></primary>
-   </indexterm>
-   <para>
-    Contrôle les niveaux de message envoyés au client. Les valeurs
-    valides sont <literal>DEBUG5</literal>,
-    <literal>DEBUG4</literal>, <literal>DEBUG3</literal>, <literal>DEBUG2</literal>,
-    <literal>DEBUG1</literal>, <literal>LOG</literal>, <literal>NOTICE</literal>,
-    <literal>WARNING</literal>, <literal>ERROR</literal>, <literal>FATAL</literal>,
-    et <literal>PANIC</literal>. Chaque niveau inclut tous les
-    niveaux qui le suivent. Plus on progresse dans la liste,
-    plus le nombre de messages envoyés est faible. <literal>NOTICE</literal>
-    est la valeur par défaut. <literal>LOG</literal> a ici une portée
-    différente de celle de <varname>log_min_messages</varname>.
-   </para>
-  </listitem>
- </varlistentry>
-
  <varlistentry id="guc-log-min-messages" xreflabel="log_min_messages">
   <term><varname>log_min_messages</varname> (<type>enum</type>)</term>
   <listitem>
    <indexterm>
     <primary>paramètre de configuration <varname>log_min_messages</varname></primary>
    </indexterm>
    <para>
-    Contrôle les niveaux de message écrits dans les traces du serveur.
+    Contrôle les <link linkend="runtime-config-severity-levels">niveaux de
+    message</link> écrits dans les traces du serveur.
     Les valeurs valides sont <literal>DEBUG5</literal>, <literal>DEBUG4</literal>,
     <literal>DEBUG3</literal>, <literal>DEBUG2</literal>, <literal>DEBUG1</literal>,
     <literal>INFO</literal>, <literal>NOTICE</literal>, <literal>WARNING</literal>,
@@ -5346,7 +5326,7 @@ local0.*    /var/log/postgresql
     suivent. Plus on progresse dans la liste, plus le nombre de messages
     envoyés est faible. <literal>WARNING</literal> est la valeur par
     défaut. <literal>LOG</literal> a ici une portée différente de celle
-    de <varname>client_min_messages</varname>. Seuls les superutilisateurs peuvent
+    de <xref linkend="guc-client-min-messages"/>. Seuls les superutilisateurs peuvent
     modifier la valeur de ce paramètre.
    </para>
   </listitem>
@@ -5361,9 +5341,9 @@ local0.*    /var/log/postgresql
    <para>
     Contrôle si l'instruction SQL à l'origine d'une erreur doit être
     enregistrée dans les traces du serveur. L'instruction SQL en cours est
-    incluse dans les traces pour tout message de sévérité indiquée ou
-    supérieure. Les valeurs valides sont
-    <literal>DEBUG5</literal>,
+    incluse dans les traces pour tout message de <link
+    linkend="runtime-config-severity-levels">sévérité</link> indiquée ou
+    supérieure. Les valeurs valides sont <literal>DEBUG5</literal>,
     <literal>DEBUG4</literal>, <literal>DEBUG3</literal>,
     <literal>DEBUG2</literal>, <literal>DEBUG1</literal>,
     <literal>INFO</literal>, <literal>NOTICE</literal>,
@@ -6674,6 +6654,32 @@ Ces paramètres contrôlent le comportement de la fonctionnalité appelée
 <title>Comportement des instructions</title>
 <variablelist>
 
+ <varlistentry id="guc-client-min-messages" xreflabel="client_min_messages">
+  <term><varname>client_min_messages</varname> (<type>enum</type>)</term>
+  <listitem>
+   <indexterm>
+    <primary>paramètre de configuration <varname>client_min_messages</varname></primary>
+   </indexterm>
+   <para>
+    Contrôle les <link linkend="runtime-config-severity-levels">niveaux de
+    message</link> envoyés au client. Les valeurs valides sont
+    <literal>DEBUG5</literal>, <literal>DEBUG4</literal>,
+    <literal>DEBUG3</literal>, <literal>DEBUG2</literal>,
+    <literal>DEBUG1</literal>, <literal>LOG</literal>,
+    <literal>NOTICE</literal>, <literal>WARNING</literal> et
+    <literal>ERROR</literal>. Chaque niveau inclut tous les
+    niveaux qui le suivent. Plus on progresse dans la liste,
+    plus le nombre de messages envoyés est faible. <literal>NOTICE</literal>
+    est la valeur par défaut. <literal>LOG</literal> a ici une portée
+    différente de celle de <varname>log_min_messages</varname>.
+   </para>
+   <para>
+    Les messages de niveau <literal>INFO</literal> sont toujours envoyés au
+    client.
+   </para>
+  </listitem>
+ </varlistentry>
+
  <varlistentry id="guc-search-path" xreflabel="search_path">
   <term><varname>search_path</varname> (<type>string</type>)</term>
   <listitem>
@@ -6702,7 +6708,7 @@ Ces paramètres contrôlent le comportement de la fonctionnalité appelée
    <para>
     Si un des éléments de la liste est le nom spécial <literal>$user</literal>,
     alors le schéma dont le nom correspond à la valeur retournée par
-    <function>SESSION_USER</function> est substitué, s'il existe et que
+    <function>CURRENT_USER</function> est substitué, s'il existe et que
     l'utilisateur ait le droit <literal>USAGE</literal> sur ce schéma
     (sinon <literal>$user</literal> est ignoré).
    </para>
@@ -8448,6 +8454,42 @@ SET XML OPTION { DOCUMENT | CONTENT };
     </listitem>
    </varlistentry>
 
+   <varlistentry id="guc-data-sync-retry" xreflabel="data_sync_retry">
+    <term><varname>data_sync_retry</varname> (<type>boolean</type>)
+    <indexterm>
+     <primary>paramètre de configuration <varname>data_sync_retry</varname></primary>
+    </indexterm>
+    </term>
+    <listitem>
+     <para>
+      Lorsqu'il est configuré à false, ce qui est la valeur par défaut,
+      <productname>PostgreSQL</productname> lèvera une erreur de niveau PANIC
+      en cas d'échec de synchronisation des fichiers de données modifiés sur
+      le système de fichiers. Ceci causera le crash du serveur de bases de
+      données.
+     </para>
+     <para>
+      Sur certains systèmes d'exploitation, le statut des données dans le
+      cache disque du noyau n'est pas connu après un échec de synrhconisation.
+      Dans certains cas, ce statut peut être entièrement oublié, rendant
+      risquée toute nouvelle tentative. La deuxième tentative pourrait être
+      rapportée comme réussi alors qu'en fait la donnée a été perdue. Dans ces
+      circonstances, la seule façon d'éviter une perte de données est de
+      rejouer les journaux de transactions après chaque statut d'échec, de
+      préférence après une investigation sur la cause originale de l'échec et
+      de remplacer tout matériel défectueux.
+     </para>
+     <para>
+      S'il est configuré à true, <productname>PostgreSQL</productname>
+      renverra une erreur mais continuera à s'exécuter pour que l'opération de
+      synchronisation sur disque soit tentée de noueau au prochain checkpoint.
+      Il faut le configurer à true après avoir investigué sur le traitement
+      par le système d'exploitation des données en cache dans le cas d'un
+      échec de synchronisation.
+     </para>
+    </listitem>
+   </varlistentry>
+
   </variablelist>
 
  </sect1>
@@ -8633,11 +8675,9 @@ SET XML OPTION { DOCUMENT | CONTENT };
     </indexterm>
     <listitem>
      <para>
-      Retourne le nombre de blocs (pages) qui peuvent être stockés dans un
-      segment de fichier. C'est déterminé par la valeur de <literal>RELSEG_SIZE</literal>
-      à la compilation du serveur. La valeur maximum d'un fichier de segment
-      en octet est égal à <varname>segment_size</varname> multiplié par
-      <varname>block_size</varname>&nbsp;; par défaut, c'est 1&nbsp;Go.
+      Indique la taille des segments de journaux de transactions. La valeur par
+      défaut est 16 Mo. Voir <xref linkend="wal-configuration"/> pour plus
+      d'informations.
      </para>
     </listitem>
    </varlistentry>

postgresql/custom-scan.xml

@@ -42,10 +42,13 @@
   <title>Créer des parcours de chemin personnalisés</title>
 
   <para>
-    Un module de parcours personnalisé ajoutera classiquement des chemins
-    pour une relation de base en mettant en place le hook suivant, qui est
-    appelé après que le code de base ait généré ce qu'il pense être
-    l'ensemble complet et correct des chemins d'accès pour la relation.
+    Un module de parcours personnalisé ajoutera classiquement des chemins pour
+    une relation de base en mettant en place le hook suivant, qui est appelé
+    après que le code de base ait généré tous les chemins d'accès possibles
+    pour la relation (sauf les chemins Gather, qui sont réalisés après cet
+    appel pour qu'ils puissent utiliser les chemins partiels ajoutés par le
+    hook&nbsp;:
+
 <programlisting>
 typedef void (*set_rel_pathlist_hook_type) (PlannerInfo *root,
                                             RelOptInfo *rel,

postgresql/datatype.xml

@@ -1398,17 +1398,16 @@ SELECT b, char_length(b) FROM test2;
     Le format <quote>hex</quote> code les données binaires sous la forme de
     deux chiffres hexadécimaux par octet, le plus significatif en premier. La
     chaîne complète est précédée par la séquence <literal>\x</literal> (pour
-    la distinguer du format d'échappement). Dans la majorité des cas
-    (exactement les mêmes pour lesquels les antislashs sont doublés dans le
-    format d'échappement), l'antislash initial peut avoir besoin d'être
-    échappé par un doublage du caractère&nbsp;; les détails sont disponibles
-    plus bas. Les chiffres hexadécimaux peuvent être soit en majuscules, soit
-    en minuscules, et les espaces blancs sont permis entre les paires de
-    chiffres (mais pas à l'intérieur d'une paire ni dans la séquence
-    <literal>\x</literal> de début). Le format hexadécimal est compatible avec
-    une grande variété d'applications et de protocoles externes, et il a
-    tendance à être plus rapide à convertir que le format d'échappement. Son
-    utilisation est donc préférée.
+    la distinguer du format d'échappement). Dans certains cas, l'antislash
+    initial peut avoir besoin d'être échappé par un doublage du caractère
+    (voir <xref linkend="sql-syntax-strings"/>). En saisie, les chiffres
+    hexadécimaux peuvent être soit en majuscules, soit en minuscules, et les
+    espaces blancs sont permis entre les paires de chiffres (mais pas à
+    l'intérieur d'une paire ni dans la séquence <literal>\x</literal> de
+    début). Le format hexadécimal est compatible avec une grande variété
+    d'applications et de protocoles externes, et il a tendance à être plus
+    rapide à convertir que le format d'échappement. Son utilisation est donc
+    préférée.
    </para>
 
    <para>
@@ -1461,7 +1460,7 @@ SELECT '\xDEADBEEF';
        <entry>Description</entry>
        <entry>Représentation échappée en entrée</entry>
        <entry>Exemple</entry>
-       <entry>Représentation en sortie</entry>
+       <entry>Représentation hexadécimale</entry>
       </row>
      </thead>
 
@@ -1485,7 +1484,7 @@ SELECT '\xDEADBEEF';
       <row>
        <entry>92</entry>
        <entry>antislash</entry>
-       <entry><literal>'\\\'</literal> or <literal>'\134'</literal></entry>
+       <entry><literal>'\\'</literal> or <literal>'\134'</literal></entry>
        <entry><literal>SELECT '\\'::bytea;</literal></entry>
        <entry><literal>\x5c</literal></entry>
       </row>
@@ -1503,34 +1502,29 @@ SELECT '\xDEADBEEF';
    </table>
 
    <para>
-    La nécessité d'échapper les octets <emphasis>non affichables</emphasis> dépend
-    des paramétrages de la locale. Il est parfois possible de s'en sortir sans
-    échappement. Le résultat de chacun des
-    exemples du <xref linkend="datatype-binary-sqlesc"/> fait exactement
-    un octet, même si la représentation en sortie fait plus d'un caractère.
+    La nécessité d'échapper les octets <emphasis>non affichables</emphasis>
+    dépend des paramétrages de la locale. Il est parfois possible de s'en
+    sortir sans échappement.
    </para>
 
    <para>
-    S'il faut écrire tant d'antislashs, comme
-    indiqué dans le <xref linkend="datatype-binary-sqlesc"/>, c'est qu'une
-    chaîne binaire doit passer à travers deux phases d'analyse dans le
-    serveur <productname>PostgreSQL</productname>. Le premier antislash
-    de chaque paire est vu comme un caractère d'échappement par
-    l'analyseur de chaîne (en supposant que la syntaxe d'échappement des
-    chaînes soit utilisée) et est donc consommé, laissant le second antislash
-    de la paire. (Les chaînes à guillemets dollar peuvent être utilisées
-    pour éviter ce niveau d'échappement.) L'antislash restant est
-    compris par la fonction d'entrée de <productname>PostgreSQL</productname>
-    comme le début d'une valeur octale sur trois caractères ou comme
-    l'échappement d'un autre antislash.
-    Par exemple, une chaîne littérale passée au serveur comme
-    <literal>'\001'</literal> devient <literal>\001</literal> après
-    être passée au travers de l'analyseur d'échappement de chaîne.
-    Le <literal>\001</literal> est envoyé à la fonction d'entrée de
-    <type>bytea</type>, qui le convertit en un octet simple ayant une valeur
-    décimale de 1. Le guillemet simple n'est pas traité
-    spécialement par <type>bytea</type> et suit les règles normales
-    des chaînes littérales de chaîne. Voir aussi la <xref linkend="sql-syntax-strings"/>.
+    La raison pour laquelle les guillemets simples doivent être doublés, comme
+    indiqué dans <xref linkend="datatype-binary-sqlesc"/>, est que cela est
+    vrai pour toute chaîne litérale dans une commande SQL. L'analyseur
+    générique des chaînes litérales utilise les guillemets simples externes et
+    réduit toute paire de guillemets simples en un seul caractère. La fonction
+    en entrée du type <type>bytea</type> ne voit qu'un guillemet simple, qu'il
+    traire comme un caractère standard. Néanmoins, la fonction en entrée du
+    type <type>bytea</type> traite les antislashs de façon spéciale et les
+    autres comportements montrés dans <xref linkend="datatype-binary-sqlesc"/>
+    sont implémentés par cette fonction.
+   </para>
+
+   <para>
+    Dans certains contextes, les antislashs doivent être doublés par rapport à
+    ce qui est montré ci-dessus car l'analyseur générique de chaîne litérale
+    réduira aussi les paires d'antislashs en un seul caractère de
+    données&nbsp;; voir <xref linkend="sql-syntax-strings"/>.
    </para>
 
    <para>