Mise à jour en version 9.0.2.

postgresql/catalogs.xml

@@ -6241,6 +6241,11 @@ lourd ! -->
       <entry>utilisateurs des bases de données</entry>
      </row>
 
+     <row>
+      <entry><link linkend="view-pg-user-mappings"><structname>pg_user_mappings</structname></link></entry>
+      <entry>user mappings</entry>
+     </row>
+
      <row>
       <entry><link linkend="view-pg-views"><structname>pg_views</structname></link></entry>
       <entry>vues</entry>

postgresql/config.xml

@@ -1571,8 +1571,8 @@ block : bloc vidé,  dirty bloc : bloc à vider ?
        <para>
         Bien que désactiver <varname>fsync</varname> améliore fréquemment les
         performances, cela peut avoir pour conséquence une corruption des
-        données non récupérables dans le cas d'un arrêt inattendu ou brutal
-        du système. Donc, il est seulement conseillé de désactiver
+        données non récupérables dans le cas d'une perte de courant ou d'un
+        crash du système. Donc, il est seulement conseillé de désactiver
         <varname>fsync</varname> si vous pouvez facilement recréer la base de
         données complète à partir de données externes.
        </para>
@@ -1581,7 +1581,7 @@ block : bloc vidé,  dirty bloc : bloc à vider ?
         Quelques exemples de circonstances permettant de désactiver
         <varname>fsync</varname>&nbsp;: le chargement initial d'une nouvelle
         instance à partir d'une sauvegarde, l'utilisation de l'instance pour
-        traiter des statistiques sur une base horaire qui est ensuite recréée,
+        traiter un flot de données après quoi la base sera supprimée puis recréée,
         la création d'un clone d'une base en lecture seule, clone qui serait
         recréé fréquemment et n'est pas utilisé pour du failover. La haute
         qualité du matériel n'est pas une justification suffisante pour

postgresql/high-availability.xml

@@ -730,11 +730,6 @@ protocol to make nodes agree on a serializable transactional order.
      <varname>primary_conninfo</varname>.
    </para>
 
-   <para>
-    Vous pouvez utiliser <varname>archive_cleanup_command</varname> pour supprimer de
-    l'archive les fichiers qui ne sont plus nécessaires à la base de standby.
-   </para>
-
    <para>
     Si vous mettez en place le serveur de standby pour des besoins de haute disponibilité,
     mettez en place l'archivage de WAL, les connexions et l'authentification à l'identique
@@ -745,13 +740,36 @@ protocol to make nodes agree on a serializable transactional order.
     intention de basculer dessus, <varname>trigger_file</varname> n'est pas nécessaire.
    </para>
 
+   <para>
+    Si vous utilisez une archive WAL, sa taille peut être réduite en utilisant
+    l'option <xref linkend="archive-cleanup-command"/> pour supprimer les
+    fichiers qui ne sont plus nécessaires au serveur de standby. L'outil
+    <application>pg_archivecleanup</application> est conçu spécifiquement pour
+    être utilisé avec <varname>archive_cleanup_command</varname> dans des
+    configurations typiques de standby, voir <xref linkend="pgarchivecleanup"/>.
+    Notez toutefois que si vous utilisez l'archive à des fins de sauvegarde,
+    vous avez besoin de garder les fichiers nécessaires pour restaurer à partir
+    de votre dernière sauvegarde de base, même si ces fichiers ne sont plus
+    nécessaires pour le standby.
+   </para>
+
+   <para>
+    If you're using a WAL archive, its size can be minimized using the  parameter to remove files that are no
+    longer required by the standby server.
+
+    Note however, that if you're using the archive for backup purposes, you
+    need to retain files needed to recover from at least the latest base
+    backup, even if they're no longer needed by the standby.
+   </para>
+
    <para>
     Un simple exemple de <filename>recovery.conf</filename> est:
 <programlisting>
 standby_mode = 'on'
 primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
 restore_command = 'cp /path/to/archive/%f %p'
 trigger_file = '/path/to/trigger_file'
+archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'
 </programlisting>
    </para>
 
@@ -761,15 +779,6 @@ trigger_file = '/path/to/trigger_file'
     <varname>max_wal_senders</varname> suffisamment haut sur le primaire pour leur permettre
     de se connecter simultanément.
    </para>
-
-   <para>
-    Si vous utilisez une archive WAL, sa taille peut être réduite en utilisant
-    l'option <varname>archive_cleanup_command</varname> pour supprimer les fichiers
-    qui ne sont plus nécessaires au serveur de standby. Notez toutefois que si vous
-    utilisez l'archive à des fins de sauvegarde, vous avez besoin de garder les fichiers
-    nécessaires pour restaurer à partir de votre dernière sauvegarde de base, même
-    si ces fichiers ne sont plus nécessaires pour le standby.
-   </para>
   </sect2>
 
   <sect2 id="streaming-replication">
@@ -1856,13 +1865,16 @@ LOG:  database system is ready to accept read only connections
    </para>
 
    <para>
-    Exécuter <command>DROP DATABASE</command>, <command>ALTER DATABASE ... SET
-    TABLESPACE</command> ou <command>ALTER DATABASE ... RENAME</command> sur
+    Exécuter <command>DROP DATABASE</command> ou <command>ALTER DATABASE ...
+    SET TABLESPACE</command> sur
     le serveur maître générera un enregistrement dans les journaux de
     transactions qui causera la déconnexion de tous les utilisateurs
     actuellement connectés à cette base de données. Cette action survient
     immédiatement, quelque soit la valeur du paramètre
-    <varname>max_standby_streaming_delay</varname>.
+    <varname>max_standby_streaming_delay</varname>. Notez que
+    <command>ALTER DATABASE ... RENAME</command> ne déconnecte pas les
+    utilisateurs qui, dans la plupart des cas, ne s'en apercevront pas. Cela
+    peut néanmoins confondre un programme qui dépendrait du nom de la base.
    </para>
 
    <para>
@@ -1936,8 +1948,7 @@ LOG:  database system is ready to accept read only connections
    <listitem>
     <para>
      Les opérations sur les index hash ne sont pas écrits dans la WAL à l'heure
-     actuelle, la récupération ne mettra donc pas ces index à jour. Les index
-     hash ne seront pas utilisés pour les plans d'exécution durant la récupération.
+     actuelle, la récupération ne mettra donc pas ces index à jour.
     </para>
    </listitem>
    <listitem>

postgresql/indices.xml

@@ -187,14 +187,16 @@
 </synopsis>
   </para>
 
-  <note>
+  <caution>
    <para>
-    Les opérations sur les index de hachage
-    ne sont pas tracées par les WAL. Il est dont généralement nécessaire de
-    les reconstruire avec <command>REINDEX</command> après un crash de la base.
-    Pour cette raison, l'utilisation des index de hachage est découragée.
+    Les opérations sur les index de hachage ne sont pas tracées par les journaux
+    de transactions. Il est donc généralement nécessaire de les reconstruire
+    avec <command>REINDEX</command> après un crash de la base. Ils ne sont pas
+    non plus répliqués, que ce soit dans la réplication en flux ou par journaux
+    de transactions. Pour ces raisons, l'utilisation des index de hachage est
+    déconseillée.
    </para>
-  </note>  
+  </caution>  
 
   <para>
    <indexterm>

postgresql/keywords.xml

@@ -3567,7 +3567,7 @@
    </row>
    <row>
     <entry><token>OFF</token></entry>
-    <entry>réservé</entry>
+    <entry>non réservé</entry>
     <entry>non réservé</entry>
     <entry>non réservé</entry>
     <entry>réservé</entry>

postgresql/pgarchivecleanup.xml

@@ -7,13 +7,12 @@
  </indexterm>
 
  <para>
-  <application>pg_archivecleanup</application> est conçu pour nettoyer une
-  archive. Il doit être intégré dans la valeur du paramètre
-  <literal>archive_cleanup_command</literal> lors de l'utilisation d'un
-  serveur en hotstandby (<literal>standby_mode = on</literal>).
-  <application>pg_archivecleanup</application> peut aussi être utilisé comme
-  un programme autonome pour nettoyer les archives de journaux de
-  transactions.
+  <application>pg_archivecleanup</application> est conçu pour être utilisé
+  via le paramètre <literal>archive_cleanup_command</literal> pour nettoyer
+  les archives des journaux de transactions lorsque le serveur est exécuté en
+  tant que serveur en standby (voir <xref linkend="warm-standby"/>).
+  <application>pg_archivecleanup</> peut aussi être utilisé comme un programme
+  autonome pour nettoyer les archives de journaux de transactions.
  </para>
 
  <para>
@@ -47,10 +46,10 @@ archive_cleanup_command = 'pg_archivecleanup <replaceable>RépArchive</replaceab
   </programlisting>
   <para>
    où <replaceable>RépArchive</replaceable> est le répertoire à partir duquel
-   les journaux de transactions doivent être restaurés.
+   les journaux de transactions doivent être supprimés.
   </para>
   <para>
-   S'il est utilisé via <literal>archive_cleanup_command</literal>,
+   S'il est utilisé via <xref linkend="archive-cleanup-command"/>,
    tous les fichiers des journaux de transactions qui précèdent la valeur de
    <literal>%r</literal> de façon logique seront supprimés de
    <replaceable>RépArchive</replaceable>. Ceci minimise le nombre de
@@ -59,7 +58,8 @@ archive_cleanup_command = 'pg_archivecleanup <replaceable>RépArchive</replaceab
    <replaceable>RépArchive</replaceable> est une aire de passage temporaire
    pour ce serveur en attente particulier, mais <emphasis>pas</emphasis> quand
    <replaceable>RépArchive</replaceable> a pour but d'être une archive à long
-   terme des journaux de transactions.
+   terme des journaux de transactions ou quand plusieurs serveurs en standby
+   utilisent le même emplacement pour les archives.
   </para>
   <para>
    La syntaxe complète de la ligne de commande de

postgresql/pgupgrade.xml

@@ -24,7 +24,8 @@
   données change rarement. <application>pg_upgrade</application> fait de son
   mieux pour s'assurer que les clusters, ancien et nouveau, soient compatibles
   binairement, c'est-à-dire en vérificant les paramètres de temps modifiables
-  à la compilation. Il est important que tout module externe soit aussi
+  à la compilation, en incluant les binaires 32/64 bits. Il est important que
+  tout module externe soit aussi
   compatible binairement, bien que cela ne soit pas vérifié
   <application>pg_upgrade</application>.
  </para>

postgresql/plpython.xml

@@ -968,8 +968,8 @@ $$ LANGUAGE plpythonu;
    <function>plpy.error</function> et <literal>plpy.fatal("msg")</literal>
    lèvent une exception Python qui, si non attrapée, se propage à la requête
    appelante causant l'annulation de la transaction ou sous-transaction en
-   cours.  <literal>raise plpy.ERROR(<replaceable>msg</replaceable>)</literal> et
-   <literal>raise plpy.FATAL(<replaceable>msg</replaceable>)</literal> sont équivalent à
+   cours.  <literal>raise plpy.Error(<replaceable>msg</replaceable>)</literal> et
+   <literal>raise plpy.Fatal(<replaceable>msg</replaceable>)</literal> sont équivalent à
    appeler, respectivement, <function>plpy.error</function> et
    <function>plpy.fatal</function>. Les autres fonctions génèrent uniquement
    des messages de

postgresql/recovery-config.xml

@@ -83,21 +83,30 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows
       </indexterm>
       <listitem>
        <para>
-        Ce paramètre spécifie une commande d'interpréteur qui sera exécuté à
-        chaque point de reprise. Ce paramètre est optionnel. Le but de
-        <varname>archive_cleanup_command</varname> est de fournir un mécanisme de
-        nettoyage des vieux fichiers WAL archivés qui ne sont plus nécessaires
-        au serveur de standby.
-        Tout <literal>%r</literal> est remplacé par le nom du fichier contenant
-        le dernier point de reprise (restartpoint) valide. Autrement dit, le
-        fichier le plus ancien qui doit être gardé pour permettre à la récupération
-        d'être redémarrable. Cette information peut donc être utilisée pour tronquer
-        l'archive au strict minimum nécessaire pour permettre de reprendre la
-        restauration en cours. <literal>%r</literal> n'est typiquement utilisé
-        que dans des configurations de warn-standby.
-        (voir <xref linkend="warm-standby" />).
-        Écrivez <literal>%%</literal> pour inclure un vrai caractère
-        <literal>%</literal>.
+        Ce paramètre optionel spécifie une commande d'interpréteur qui sera
+        exécuté à chaque point de reprise. Le but de
+        <varname>archive_cleanup_command</varname> est de fournir un mécanisme
+        de nettoyage des vieux fichiers WAL archivés qui ne sont plus
+        nécessaires au serveur de standby. Tout <literal>%r</literal> est
+        remplacé par le nom du fichier contenant le dernier point de reprise
+        (restartpoint) valide. Autrement dit, le fichier le plus ancien qui
+        doit être <emphasis>conservé</emphasis> pour permettre à la
+        récupération d'être redémarrable. Du coup, tous les fichiers créés
+        avant <literal>%r</literal> peuvent être supprimés sans problème.
+        Cette information peut être utilisée pour tronquer les archives au
+        minimum nécessaire pour redémarrer à partir de la restauration en
+        L'outil <application>pg_archivecleanup</application> fourni en module
+        <literal>contrib</literal> (voir <xref linkend="pgarchivecleanup">/)
+        sert de configuration simple pour <varname>archive_cleanup_command</varname>
+        dans des configurations de standby seuls. Par exemple&nbsp;:
+<programlisting> archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r' </programlisting>
+        Notez néanmoins que si plusieurs serveurs en standby sont mis à jour
+        à partir du même répertoire d'archives, vous devez vous assurer que
+        vous ne supprimez que les journaux de transactions qui ne sont plus
+        utiles à tous les serveurs. <varname>archive_cleanup_command</varname>
+        n'est typiquement utilisé que dans des configurations de warm-standby
+        (voir <xref linkend="warm-standby" />). Écrivez <literal>%%</literal>
+        pour inclure un vrai caractère <literal>%</literal>.
        </para>
        <para>
         Si la commande retourne un code de retour différent de zéro alors

postgresql/ref/create_view.xml

@@ -142,10 +142,13 @@
 
    <para>
     L'accès aux tables référencées dans la vue est déterminé par les droits
-    du propriétaire de la vue.  Cependant, les fonctions appelées dans la vue
-    sont traitées comme si elles étaient appelées directement
-    par la requête utilisant la vue.  Par conséquent, l'utilisateur de la vue
-    doit avoir le droit d'appeler toutes les fonctions utilisées par la vue.
+    du propriétaire de la vue. Dans certains cas, cela peut être utilisé pour
+    fournir un accès sécurisé. Cependant, toutes les vues ne sont pas
+    sécurisables&nbsp;; voir <xref linkend="rules-privileges"/> pour des
+    détails.  Les fonctions appelées dans la vue sont traitées de la même façon
+    que si elles avaient été appelées directement dans la requête utilisant la
+    vue. Du coup, l'utilisateur d'une vue doit avoir les droits pour appeler
+    toutes les fonctions utilisées par la vue.
    </para>
 
    <para>

postgresql/ref/explain.xml

@@ -18,8 +18,17 @@
  </refnamediv>
 
  <refsynopsisdiv>
-<synopsis>EXPLAIN [ ( { ANALYZE <replaceable class="parameter">boolean</replaceable> | VERBOSE <replaceable class="parameter">boolean</replaceable> | COSTS <replaceable class="parameter">boolean</replaceable> | BUFFERS <replaceable class="parameter">boolean</replaceable> | FORMAT { TEXT | XML | JSON | YAML } } [, ...] ) ] <replaceable class="parameter">instruction</replaceable>
+<synopsis>EXPLAIN [ ( <replaceable class="parameter">option</replaceable> [, ...] ) ] <replaceable class="parameter">instruction</replaceable>
 EXPLAIN [ ANALYZE ] [ VERBOSE ] <replaceable class="parameter">instruction</replaceable>
+
+<phrase>où <replaceable class="parameter">option</replaceable> est&nbsp;:</phrase>
+
+    ANALYZE [ <replaceable class="parameter">boolean</replaceable> ]
+    VERBOSE [ <replaceable class="parameter">boolean</replaceable> ]
+    COSTS [ <replaceable class="parameter">boolean</replaceable> ]
+    BUFFERS [ <replaceable class="parameter">boolean</replaceable> ]
+    FORMAT { TEXT | XML | JSON | YAML }
+
 </synopsis>
  </refsynopsisdiv>
 

postgresql/ref/grant.xml

@@ -341,8 +341,10 @@ GRANT <replaceable class="PARAMETER">nom_rôle</replaceable> [, ...] TO <replace
       </para>
       <para>
        Pour les serveurs distants, ce droit autorise son bénéficiaire à
-       interroger les options du serveur et les correspondances d'utilisateurs
-       associées.
+       créer, modifier et supprimer les correspondances utilisateur de
+       l'utilisateur associé à ce serveur. De plus, il autorise son
+       bénéficiaire à interroger les options du serveur et les correspondances
+       d'utilisateurs associées.
       </para>
      </listitem>
     </varlistentry>