Mise à jour en version 14.6

postgresql/acronyms.xml

@@ -323,9 +323,7 @@
     <term><acronym>HOT</acronym></term>
     <listitem>
      <para>
-      <ulink
-      url="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/access/heap/README.HOT;hb=HEAD">Heap-Only
-       Tuples</ulink>, tuples en mémoire seule
+      <link linkend="storage-hot">Heap-Only Tuples</link>
      </para>
     </listitem>
    </varlistentry>

postgresql/btree.xml

@@ -669,8 +669,9 @@ options(<replaceable>relopts</replaceable> <type>local_relopts *</type>) returns
     version originale) des lignes peut parfois s'accumuler et nuire à la
     latence et au débit des requêtes. Ceci se produit typiquement avec des
     charges élevées en <command>UPDATE</command> où la plupart des mises à
-    jour individuelles ne peuvent appliquer l'optimisation
-    <acronym>HOT</acronym>. Changer la valeur de seulement une colonne
+    jour individuelles ne peuvent appliquer l'<link
+    linkend="storage-hot">optimisation <acronym>HOT</acronym></link>.
+    Changer la valeur de seulement une colonne
     couverte par un index durant un <command>UPDATE</command> nécessite
     <emphasis>toujours</emphasis> un nouveau ensemble d'entrées
     d'index &mdash; un pour <emphasis>chaque et tous les</emphasis> index sur

postgresql/catalogs.xml

@@ -4443,8 +4443,8 @@ SCRAM-SHA-256$<replaceable>&lt;nombre d'itération&gt;</replaceable>:<replaceabl
         <structfield>xmin</structfield> de cette ligne de
         <structname>pg_index</structname> est en-dessous de leur horizon
         d'événements <symbol>TransactionXmin</symbol>, car la table peut
-        contenir des chaînes
-        HOT cassées avec des lignes incompatibles qu'elles peuvent voir.
+        contenir des <link linkend="storage-hot">chaînes HOT</link> cassées avec
+        des lignes incompatibles qu'elles peuvent voir.
        </para></entry>
      </row>
 

postgresql/config.xml

@@ -2887,9 +2887,10 @@ block : bloc vidé,  dirty bloc : bloc à vider ?
      serveur.
     </para>
     <para>
-     Au niveau <literal>minimal</literal>, aucune information n'est tracée
-     pour les tables permanentes pour le reste d'une transaction qui les crée
-     et les réécrit. Ceci peut rendre certaines opérations bien plus rapides
+     Le niveau <literal>minimal</literal> génère la plus petite quantité de WAL.
+     Il ne trace aucun information de ligne pour les relations permanentes
+     dans des transactions qui les crée ou les réécrive.
+     Ceci peut rendre certaines opérations bien plus rapides
      (voir <xref linkend="populate-pitr"/>). Les opérations qui initient cette
      optimisation incluent&nbsp;:
      <simplelist>
@@ -2905,21 +2906,21 @@ block : bloc vidé,  dirty bloc : bloc à vider ?
       <member><command>REINDEX</command></member>
       <member><command>TRUNCATE</command></member>
      </simplelist>
-     Mais, du coup, les journaux au niveau minimal ne contiennent pas suffisamment
-     d'informations pour reconstruire les données à partir d'une sauvegarde
-     de base et des journaux de transactions. Donc, les niveaux
-     <literal>replica</literal> ou supérieurs doivent
-     être utilisés pour activer l'archivage des journaux de transactions
-     (<xref linkend="guc-archive-mode"/>) et la réplication en flux.
-     Note that changing <varname>wal_level</varname> to
-     <literal>minimal</literal> makes any base backups taken before
-     unavailable for archive recovery and standby server, which may
-     lead to data loss.
+     Néanmoins, le niveau minimal des WAL ne contient pas suffisamment
+     d'information pour la restauration PITR, donc les niveaux
+     <literal>replica</literal> ou supérieur doivent être utilisés pour activer
+     l'archivage continu (<xref linkend="guc-archive-mode"/>) et pour la
+     réplication binaire en flux.  EN fait, le serveur ne démarrera même pas
+     dans ce mode si le paramètre <varname>max_wal_senders</varname> a une
+     valeur différente de zéro.  Notez que modifier <varname>wal_level</varname>
+     à <literal>minimal</literal> rend toute sauvegarde PITR effectuée avant
+     inutilisable pour la restauration d'archive et pour la création d'un
+     serveur standby.
     </para>
     <para>
      Dans le niveau <literal>logical</literal>, les mêmes informations sont
      enregistrées que pour le mode <literal>replica</literal>. Des
-     informations supplémentaires sont ajoutées pour permettre d'extraire les
+     informations supplémentaires sont ajoutées pour extraire les
      modifications logiques depuis les journaux de transactions. En utilisant
      le niveau <literal>logical</literal>, le volume des journaux de
      transactions va augmenter, tout particulièrement si plusieurs tables
@@ -4592,7 +4593,8 @@ ANY <replaceable class="parameter">nb_sync</replaceable> ( <replaceable class="p
     </indexterm>
     <para>
      Indique le nombre de transactions pour lesquelles <command>VACUUM</command>
-     et les mises à jour <acronym>HOT</acronym> vont différer le nettoyage des
+     et les <link linkend="storage-hot">mises à jour
+     <acronym>HOT</acronym></link> vont différer le nettoyage des
      versions de lignes mortes. La valeur par défaut est de 0 transactions.
      Cela signifie que les versions de lignes mortes peuvent être supprimées
      dès que possible, autrement dit dès qu'elles ne sont plus visibles par
@@ -6918,6 +6920,13 @@ local0.*    /var/log/postgresql
 <sect2 id="runtime-config-logging-what">
  <title>Que tracer</title>
 
+ <note>
+  <para>
+   Ce que vous choisissez de tracer peut avoir des implications sur la sécurité&nbsp;;
+   voir <xref linkend="logfile-maintenance"/>.
+  </para>
+ </note>
+
  <variablelist>
 
   <varlistentry id="guc-application-name" xreflabel="application_name">
@@ -7523,6 +7532,10 @@ log_line_prefix = '%m [%p] %q%u@%d/%a '
       <varname>log_min_error_statement</varname> doit être positionné à
       <literal>ERROR</literal> pour tracer ce type d'instructions.
      </para>
+     <para>
+      Les requêtes tracées peuvent révéler des données sensibles et même
+      contenir des mots de passe en clair.
+     </para>
     </note>
    </listitem>
   </varlistentry>

postgresql/datatype.xml

@@ -1194,6 +1194,8 @@ SELECT '52093.89'::money::numeric::float8;
     <type>char(<replaceable>n</replaceable>)</type> sont des alias de
     <type>character varying(<replaceable>n</replaceable>)</type> et
     <type>character(<replaceable>n</replaceable>)</type>, respectivement.
+    Si indiqué, la longueur doit être supérieure à zéro et ne peut pas
+    excéder 10485760.
     <type>character</type> sans indication de taille est équivalent à
     <type>character(1)</type>. Si <type>character varying</type> est
     utilisé sans indicateur de taille, le type accepte des chaînes de

postgresql/ddl.xml

@@ -4220,12 +4220,13 @@ ALTER INDEX measurement_city_id_logdate_key
      <itemizedlist>
       <listitem>
        <para>
-        Les contraintes d'unicité (et de ce fait les clés primaires) sur des
-        tables partitionnées doivent inclure toutes les colonnes faisant
-        partie de la clé de partitionnement. Cette limitation existe parce
-        que les index individuels créant la contrainte peuvent seulement
-        forcer l'unicité sur leur propre partition&nbsp;; de ce fait, la
-        structure même de la partition doit garantir qu'il n'existe pas de
+        Pour créer une contrainte d'unicité ou de clé primaire sur une table
+        partitionnée, la clé de partitionnement ne doit pas inclure d'expressions
+        ou d'appels de fonction, et les colonnes de la contrainte doivent inclure
+        toutes les colonnes de la clé de partitionnement. Cette limitation existe
+        parce que les index individuels forçant la contrainte peuvent seulement
+        garantir l'unicité dans leur propre partition&nbsp;; de ce fait, la
+        structure même de la partition doit garantir qu'il n'y aura pas de
         duplicats dans les différentes partitions.
        </para>
       </listitem>

postgresql/docguide.xml

@@ -65,7 +65,7 @@
    lecture en ligne. Le <ulink
    url="http://newbiedoc.sourceforge.net/metadoc/docbook-guide.html">guide
     DocBook des nouveaux venus</ulink> est très utile pour les débutants. Le
-   <ulink url="https://www.freebsd.org/docproj/docproj.html">projet de
+   <ulink url="https://www.freebsd.org/docproj/">projet de
     documentation FreeBSD</ulink> utilise également DocBook et fournit
    également de bonnes informations, incluant un certain nombre de
    lignes directrices qu'il peut être bon de prendre en considération.

postgresql/func.xml

@@ -14935,6 +14935,12 @@ table2-mapping
    sont disponibles pour le type <type>jsonb</type>, mais pas pour le type
    <type>json</type>. Les opérateurs de comparaison suivent les règles de tri
    des opérateurs B-tree indiqués dans <xref linkend="json-indexing"/>.
+   Voir aussi <xref linkend="functions-aggregate"/> pour la fonction
+   d'agrégat <function>json_agg</function> qui agrège les valeurs
+   d'enregistrements sous la forme d'un JSON, pour la fonction d'agrégat
+   <function>json_object_agg</function> qui agrège des paires de valeurs dans
+   un objet JSON, et leurs équivalents <type>jsonb</type>, à savoir
+   <function>jsonb_agg</function> et <function>jsonb_object_agg</function>.
   </para>
 
   <table id="functions-json-op-table">
@@ -16102,7 +16108,7 @@ table2-mapping
       </para>
       <para>
        <literal>jsonb_set_lax('[{"f1":1,"f2":null},2,null,3]', '{0,f1}', null)</literal>
-       <returnvalue>[{"f1":null,"f2":null},2,null,3]</returnvalue>
+       <returnvalue>[{"f1": null, "f2": null}, 2, null, 3]</returnvalue>
       </para>
       <para>
        <literal>jsonb_set_lax('[{"f1":99,"f2":null},2]', '{0,f3}', null, true, 'return_target')</literal>
@@ -16337,7 +16343,7 @@ table2-mapping
        demande ce type de comparaison.
       </para>
       <para>
-       <literal>jsonb_path_exists_tz('["2015-08-01 12:00:00 -05"]', '$[*] ? (@.datetime() &lt; "2015-08-02".datetime())')</literal>
+       <literal>jsonb_path_exists_tz('["2015-08-01 12:00:00-05"]', '$[*] ? (@.datetime() &lt; "2015-08-02".datetime())')</literal>
        <returnvalue>t</returnvalue>
       </para></entry>
     </row>
@@ -16408,15 +16414,6 @@ table2-mapping
    </tbody>
   </tgroup>
  </table>
-
- <para>
-  Voir aussi <xref linkend="functions-aggregate"/> pour la fonction
-  d'agrégat <function>json_agg</function> qui agrège les valeurs
-  d'enregistrements sous la forme d'un JSON, pour la fonction d'agrégat
-  <function>json_object_agg</function> qui agrège des paires de valeurs dans
-  un objet JSON, et leurs équivalents <type>jsonb</type>, à savoir
-  <function>jsonb_agg</function> et <function>jsonb_object_agg</function>.
- </para>
 </sect2>
 
 <sect2 id="functions-sqljson-path">
@@ -26188,7 +26185,7 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
       <indexterm>
        <primary>pg_create_physical_replication_slot</primary>
       </indexterm>
-      <function>pg_create_physical_replication_slot</function> ( <parameter>slot_name</parameter> <type>name</type> <optional>, <parameter>immediately_reserve</parameter> <type>boolean</type>, <parameter>temporary</parameter> <type>boolean</type>, <parameter>two_phase</parameter> <type>boolean</type> </optional> )
+      <function>pg_create_physical_replication_slot</function> ( <parameter>slot_name</parameter> <type>name</type> <optional>, <parameter>immediately_reserve</parameter> <type>boolean</type>, <parameter>temporary</parameter> <type>boolean</type>, <parameter>twophase</parameter> <type>boolean</type> </optional> )
       <returnvalue>record</returnvalue>
       ( <parameter>slot_name</parameter> <type>name</type>,
       <parameter>lsn</parameter> <type>pg_lsn</type> )
@@ -26208,7 +26205,7 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
       permanente sur disque et qu'il a seulement pour but d'être utilisé
       dans la session en cours. Les slots temporaires sont aussi supprimés
       dès qu'une erreur survient. Le quatrième paramètre optionnel,
-      <parameter>two_phase</parameter>, quand il vaut true, indique
+      <parameter>twophase</parameter>, quand il vaut true, indique
       que le décodage des transactions préparées est autorisé pour ce
       slot. Cette fonction correspond à la commande
       <literal>CREATE_REPLICATION_SLOT ... PHYSICAL</literal> du protocole
@@ -26238,7 +26235,7 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
       <indexterm>
        <primary>pg_create_logical_replication_slot</primary>
       </indexterm>
-      <function>pg_create_logical_replication_slot</function> ( <parameter>slot_name</parameter> <type>name</type>, <parameter>plugin</parameter> <type>name</type> <optional>, <parameter>temporary</parameter> <type>boolean</type> </optional> )
+      <function>pg_create_logical_replication_slot</function> ( <parameter>slot_name</parameter> <type>name</type>, <parameter>plugin</parameter> <type>name</type> <optional>, <parameter>temporary</parameter> <type>boolean</type>, <parameter>twophase</parameter> <type>boolean</type> </optional> )
       <returnvalue>record</returnvalue>
       ( <parameter>slot_name</parameter> <type>name</type>,
       <parameter>lsn</parameter> <type>pg_lsn</type> )

postgresql/indexam.xml

@@ -47,7 +47,8 @@
   est un objet indépendant qui a besoin de sa propre entrée. En conséquence,
   la mise à jour d'une ligne crée toujours de nouvelles entrées
   dans l'index pour cette ligne, même si les valeurs de la clé ne changent pas.
-  (Les lignes HOT sont une exception ; mais les index ne s'en occupent pas).
+  (Les <link linkend="storage-hot">lignes HOT</link>
+  sont une exception&nbsp;; mais les index ne s'en occupent pas).
   Les entrées d'index pour les lignes mortes sont nettoyées (par
   le VACUUM) lorsque les lignes mortes elles-même sont nettoyées.
  </para>

postgresql/indices.xml

@@ -101,9 +101,10 @@
 
   <para>
    Après la création d'un index, le système doit le maintenir synchronisé avec
-   la table. Cela rend plus lourdes les opérations de manipulation de
-   données. C'est pourquoi les index qui sont peu, voire jamais, utilisés
-   doivent être supprimés.
+   la table. Cela rend plus lourdes les opérations de manipulation de données.
+   Les index peuvent aussi empêcher la création d'enregistrements <link
+   linkend="storage-hot">heap-only tuples</link>. C'est pourquoi les index qui
+   sont peu, voire jamais, utilisés doivent être supprimés.
   </para>
  </sect1>
 
@@ -113,7 +114,8 @@
 
    <para>
     <productname>PostgreSQL</productname> propose plusieurs types
-    d'index&nbsp;: B-tree, Hash, GiST, SP-GiST, GIN et BRIN. Chaque type
+    d'index&nbsp;: B-tree, Hash, GiST, SP-GiST, GIN, BRIN et l'extension
+    <link linkend="bloom">bloom</link>. Chaque type
     d'index utilise un algorithme différent qui convient à un type
     particulier de requêtes. Par défaut, la commande <link
     linkend="sql-createindex"><command>CREATE INDEX</command></link> crée un
@@ -760,14 +762,14 @@ CREATE INDEX test3_desc_index ON test3 (id DESC NULLS LAST);
 
   <para>
    Les expressions d'index sont relativement coûteuses à calculer, car
-   l'expression doit être recalculée à chaque insertion ou mise à jour (non HOT) de
-   ligne. Néanmoins, les expressions d'index ne sont
-   <emphasis>pas</emphasis> recalculées lors d'une recherche par index, car elles sont
-   déjà stockées dans l'index. Dans les deux exemples ci-dessus, le système
-   voit la requête comme un <literal>WHERE colonne_indexée =
-   'constante'</literal>. De ce fait, la recherche est aussi rapide que toute
-   autre requête d'index. Ainsi, les index d'expressions sont utiles
-   lorsque la rapidité de recherche est plus importante que la rapidité
+   l'expression doit être recalculée à chaque insertion ou <link
+   linkend="storage-hot">mise à jour non-HOT</link> de ligne. Néanmoins, les
+   expressions d'index ne sont <emphasis>pas</emphasis> recalculées lors d'une
+   recherche par index, car elles sont déjà stockées dans l'index. Dans les deux
+   exemples ci-dessus, le système voit la requête comme un <literal>WHERE
+   colonne_indexée = 'constante'</literal>. De ce fait, la recherche est aussi
+   rapide que toute autre requête d'index. Ainsi, les index d'expressions sont
+   utiles lorsque la rapidité de recherche est plus importante que la rapidité
    d'insertion et de mise à jour.
   </para>
  </sect1>

postgresql/install-windows.xml

@@ -134,7 +134,7 @@
   </para>
 
   <para>
-   Avant de compiler, il faudra peut-être éditer le fichier
+   Avant de compiler, vous pouvez créer le fichier
    <filename>config.pl</filename> pour y modifier toutes les options de
    configuration nécessaires, ainsi que les chemins utilisés par les
    bibliothèques tierces. La configuration complète est déterminée

postgresql/installation.xml

@@ -1144,7 +1144,7 @@ build-postgresql:
       <listitem>
        <para>
         <option>bsd</option> pour utiliser les fonctions UUID trouvées dans
-        FreeBSD, NetBSD et d'autres systèmes dérivés de BSD
+        FreeBSD et d'autres systèmes dérivés de BSD
        </para>
       </listitem>
       <listitem>

postgresql/libpq.xml

@@ -1455,16 +1455,6 @@ postgresql://user@localhost:5433/mydb?options=-c%20synchronous_commit%3Doff
       </listitem>
      </varlistentry>
 
-     <varlistentry id="libpq-connect-tty" xreflabel="tty">
-      <term><literal>tty</literal></term>
-      <listitem>
-       <para>
-        Ignoré (autrefois, ceci indiquait où envoyer les traces de débogage du
-        serveur).
-       </para>
-      </listitem>
-     </varlistentry>
-
      <varlistentry id="libpq-connect-replication" xreflabel="replication">
       <term><literal>replication</literal></term>
       <listitem>
@@ -2641,10 +2631,8 @@ const char *PQsslAttribute(const PGconn *conn, const char *attribute_name);
          <term><literal>compression</literal></term>
          <listitem>
           <para>
-           Si la compression SSL est utilisée, renvoie le nom de
-           l'algorithme de compression, ou "on" si la compression est
-           utilisée mais que l'algorithme est inconnu. Si la compression
-           n'est pas utilisée, renvoie "off".
+           Renvoie <literal>on</literal> si la compression SSL est en cours
+           d'utilisation. Renvoie <literal>off</literal> dans le cas contraire.
           </para>
          </listitem>
         </varlistentry>

postgresql/maintenance.xml

@@ -1041,7 +1041,27 @@ limite insertion vacuum = limite insertion base vacuum + facteur échelle insert
    Sauvegarder les journaux de trace du serveur de bases de données dans un
    fichier plutôt que dans <filename>/dev/null</filename> est une bonne idée.
    Les journaux sont d'une utilité incomparable lorsqu'arrive le moment où
-   des problèmes surviennent. Néanmoins, les journaux ont tendance à être
+   des problèmes surviennent.
+  </para>
+
+  <note>
+   <para>
+    Les traces d'un serveur peuvent contenir des informations sensibles et ont
+    besoin d'être protégées, peu importe où et comment ils sont enregistrés, ou
+    leur destination d'envoi. Par exemple, certaines requêtes DDL pourraient
+    contenir des mots de passe en clair ou d'autres détails d'authentification.
+    Les instructions tracées au niveau <literal>ERROR</literal> pourraient
+    afficher le code source SQL des applications, et pourraient aussi contenir
+    une partie des lignes de données. Enregistrer des données, événements et
+    informations relatives est le but assumé de cette fonctionnalité, donc il ne
+    s'agit pas d'une fuite d'information ou d'un bug. Merci de vous assurer que
+    les traces du serveur sont visibles uniquement par les personnes
+    appropriées.
+   </para>
+  </note>
+
+  <para>
+   Les journaux ont tendance à être
    volumineux (tout spécialement à des niveaux de débogage importants) et
    vous ne voulez pas les sauvegarder indéfiniment. Vous avez besoin de faire
    une <quote>rotation</quote> des journaux pour que les nouveaux journaux