Mise à jour en version 9.2 RC1

postgresql/config.xml

@@ -1773,63 +1773,70 @@ block : bloc vidé,  dirty bloc : bloc à vider ?
        </indexterm> 
        <para>
         Indique si la validation des transactions doit attendre l'écriture des
-	enregistrements WAL avant que la commande ne renvoie une indication de
-	<quote>réussite</quote> au client. Les valeurs valides sont <literal>on</literal>, <literal>remote_write</literal>,
-        <literal>local</literal> et <literal>off</literal>. La configuration par
-	défaut, et la plus sûre, est <literal>on</literal>. Quand ce
-	paramètre est désactivé (<literal>off</literal>), il peut exister un
-	délai entre le moment où le succès est rapporté et le moment où la
-	transaction est vraiment protégée d'un arrêt brutal du serveur. (Le
-	délai maximum est de trois fois <xref linkend="guc-wal-writer-delay"/>.) 
-	Contrairement à <xref linkend="guc-fsync"/>, la configuration de ce paramètre à
-	<literal>off</literal> n'implique aucun risque d'incohérence dans la base
-	de données&nbsp;: un arrêt brutal du système d'exploitation ou d'une base
-    de données peut résulter en quelques
-	transactions récentes prétendument validées perdues malgré tout. Cependant,
-	l'état de la base de données est identique à celui obtenu si les
-	transactions avaient été correctement annulées. C'est pourquoi la
-	désactivation de <varname>synchronous_commit</varname>  est une alternative utile quand
-	la performance est plus importante que la sûreté de la transaction.
-	Pour plus de discussion, voir <xref linkend="wal-async-commit"/>.
+	      enregistrements WAL avant que la commande ne renvoie une indication de
+	      <quote>réussite</quote> au client. Les valeurs valides sont
+        <literal>on</literal>, <literal>remote_write</literal>,
+        <literal>local</literal> et <literal>off</literal>. La configuration
+	      par défaut, et la plus sûre, est <literal>on</literal>. Quand ce
+	      paramètre est désactivé (<literal>off</literal>), il peut exister un
+	      délai entre le moment où le succès est rapporté et le moment où la
+	      transaction est vraiment protégée d'un arrêt brutal du serveur. (Le
+	      délai maximum est de trois fois <xref linkend="guc-wal-writer-delay"/>.)
+	      Contrairement à <xref linkend="guc-fsync"/>, la configuration de ce
+        paramètre à <literal>off</literal> n'implique aucun risque
+        d'incohérence dans la base de données&nbsp;: un arrêt brutal du système
+        d'exploitation ou d'une base de données peut résulter en quelques
+        transactions récentes prétendument validées perdues malgré tout.
+        Cependant, l'état de la base de données est identique à celui obtenu
+        si les transactions avaient été correctement annulées. C'est pourquoi
+        la désactivation de <varname>synchronous_commit</varname> est une
+        alternative utile quand la performance est plus importante que la
+        sûreté de la transaction. Pour plus de discussion, voir <xref
+        linkend="wal-async-commit"/>.
        </para>
        <para>
         Si <xref linkend="guc-synchronous-standby-names"/> est configuré,
-        ce paramètre contrôle aussi si la validation d'une transaction
+        ce paramètre contrôle aussi si la validation des transactions
         attend que les enregistrements de journaux de transactions pour
-        cette transaction soient bien vidés sur disque et répliqués sur
-        le serveur en standby. Avec <literal>remote_write</literal>,
-        l'attente de la validation va durer jusqu'à la réponse de l'esclave
-        synchrone indiquant que ce dernier a reçu en mémoire l'enregistrement
-        de la validation de la transaction. Normalement, ceci ne cause pas
-        de perte de données lors d'un failover. Néanmoins, si le maître et
-        l'esclave s'arrêtent brutalement en même temps et que l'instance du
-        maître se retrouve corrompue, les transactions récemment validées
-        pourraient être perdues. À <literal>on</literal>, l'attente de la validation durera jusqu'à
-        ce qu'une réponse du serveur en standby synchrone indique qu'il
-        a vidé l'enregistrement sur le disque. Ceci évite toute perte de
-        données sauf si l'instance du maître et l'instance de l'esclave se
-        retrouvent corrompues simultanément. Si la réplication
-        synchrone est activée, il est sensé soit d'attendre le vidage local sur
-        disque et la réplication des enregistrements des journaux de
-        transactions, soit de permettre à la transaction de
-        valider en asynchrone. Néanmoins, la valeur spéciale
-        <literal>local</literal> est disponible pour les transactions qui
-        souhaiente attendre le vidage local sur disque et non pas la
-        réplication synchrone.
-        Si <varname>synchronous_standby_names</varname> n'est pas configuré,
-        <literal>on</literal>, <literal>remote_write</literal> et
-        <literal>local</literal> fournissent le même niveau de synchronisation.
-        La validation de la transaction attend seulement le vidage local.
+        cette transaction soient bien répliqués sur le serveur en standby.
+        Quand ce paramètre est configuré à <literal>on</literal>, les
+        validations attendront une réponse du serveur en standby synchrone,
+        indiquant qu'il a reçu l'enregistrement du commuit de la transaction
+        et qu'il l'a écrite sur disque. Ceci est une assurance que la
+        transaction ne sera pas perdue sauf si le serveur primaire et le serveur
+        en standby souffrent de corruption sur le stockage de la base.
+        Quand ce paramètre est configuré à <literal>remote_write</literal>, les
+        validations attendront une réponse du serveur standby synchrone,
+        indiquant qu'il a reçu l'enregistrement du commuit de la transaction
+        et qu'il l'a écrite sur disque via la système d'exploitation, mais sans
+        avoir demandé le vidage du cache système sur disque. Cette configuration
+        est suffisante pour s'assurer de la préservation des données même si
+        l'instance <productname>PostgreSQL</productname> du standby s'arrêtait
+        brutalement. Par contre, ce paramètrage se révèle insuffisant si le
+        système d'exploitation du serveur standby s'arrêtait brutalement.
+       </para>
+       <para>
+        Quand la réplication synchrone est activée, il est sensé soit attendre
+        le vidage local sur disque et la réplication des enregistrements des
+        journaux de transactions, soit permettre à la transaction de valider en
+        asynchrone. Néanmoins, la configuration <literal>local</literal> est
+        disponible pour les transactions qui souhaitent attendre le vidage
+        local sur disque et non pas la réplication synchrone. Si
+        <varname>synchronous_standby_names</varname> n'est pas configuré, les
+        configurations <literal>on</literal>, <literal>remote_write</literal>
+        et <literal>local</literal> fournissent le même niveau de
+        synchronisation. La validation de la transaction attend seulement le
+        vidage local.
        </para>
        <para>
         Ce paramètre peut être changé à tout moment&nbsp;; le comportement
-	pour toute transaction est déterminé par la configuration en cours
-	lors de la validation. Il est donc possible et utile d'avoir certaines
-	validations validées en synchrone et d'autres en asynchrone.
-	Par exemple, pour réaliser une validation asynchrone de transaction
-	à plusieurs instructions avec une valeur par défaut inverse, on exécute
-	l'instruction <command>SET LOCAL synchronous_commit TO OFF</command>
-	dans la transaction.
+	      pour toute transaction est déterminé par la configuration en cours
+	      lors de la validation. Il est donc possible et utile d'avoir certaines
+	      validations validées en synchrone et d'autres en asynchrone.
+	      Par exemple, pour réaliser une validation asynchrone de transaction
+	      à plusieurs instructions avec une valeur par défaut inverse, on exécute
+	      l'instruction <command>SET LOCAL synchronous_commit TO OFF</command>
+	      dans la transaction.
        </para>
       </listitem>
      </varlistentry>

postgresql/datatype.xml

@@ -4293,7 +4293,10 @@ SET xmloption TO { DOCUMENT | CONTENT };
 
    <para>
     Le type de données <type>json</type> peut être utilisé pour stocker des
-    données au format JSON. Ce type de données peut aussi être stocké dans une
+    données au format JSON (<foreignphrase>JavaScript Object
+    Notation</foreignphrase>), dont la spécification est disponible sur <ulink
+    url="http://www.ietf.org/rfc/rfc4627.txt">RFC 4627</ulink>. Ce type de
+    données peut aussi être stocké dans une
     colonne de type <type>text</type> mais le type de données <type>json</type>
     a l'avantage de vérifier que chaque valeur stockée est une valeur JSON
     valide. Il existe aussi des fonctions de support, voir <xref

postgresql/ddl.xml

@@ -2902,11 +2902,11 @@ ANALYZE mesure;
     <listitem>
      <para>
       l'exclusion de contrainte ne fonctionne que si la clause
-      <literal>WHERE</literal> de la requête contient des constantes. Une requête avec
-      paramètre n'est pas optimisée car le planificateur ne peut avoir
-      connaissance au préalable des partitions sélectionnées par la valeur du
-      paramètre à l'exécution. Pour la même raison, il faut éviter les fonctions
-      <quote>stable</quote>s comme <function>CURRENT_DATE</function>&nbsp;;
+      <literal>WHERE</literal> de la requête contient des constantes (ou des
+      paramètres externes). Par exemple, une comparaison entre une fonction
+      non immutable telle que <function>CURRENT_TIMESTAMP</function> ne peut
+      pas être optimisée car le planificateur ne peut pas savoir dans quelle
+      partition la valeur de la fonction ira lors de l'exécution.
      </para>
     </listitem>
 

postgresql/func.xml

@@ -9890,7 +9890,7 @@ transformation-table2
  <sect1 id="functions-json">
   <title>Fonctions JSON</title>
 
-  <indexterm zone="datatype-json">
+  <indexterm zone="functions-json">
     <primary>JSON</primary>
     <secondary>Fonctions et opérateurs</secondary>
   </indexterm>

postgresql/high-availability.xml

@@ -1060,7 +1060,7 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
 	  modifier. (Voir <xref linkend="runtime-config-wal-settings"/> et
     <xref linkend="runtime-config-replication-master"/>.)
   Cette configuration va entraîner l'attente de la confirmation de l'écriture permanente de chaque validation
-	sur le serveur de standby, même si cette écriture peut s'avérer être longue.
+	sur le serveur de standby.
 	La variable <varname>synchronous_commit</varname> peut être définie soit par des
 	utilisateurs, soit par le fichier de configuration pour des utilisateurs ou des bases de données fixées, soit
 	dynamiquement par des applications, pour contrôler la robustesse des échanges transactionnels.
@@ -1088,12 +1088,16 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
     Configurer <varname>synchronous_commit</varname> à
     <literal>remote_write</literal> fera que chaque COMMIT attendra la
     confirmation de la réception en mémoire de l'enregistrement du COMMIT
-    par le standby. Cela fournit un niveau de durabilité plus bas que si ce
-    paramètre avait été configuré à <literal>on</literal>. Cependant, il
-    s'agit d'une configuration utile en pratique car il diminue le temps
-    de réponse pour la transaction et ne cause aucune perte de données sauf
-    si le serveur primaire et le standby tombent en même temps et que la base
-    de données du primaire est corrompue.
+    par le standby et son écriture via la système d'exploitation, sans que
+    les données du cache du système ne soient vidées sur disque au niveau
+    du serveur en standby.  Cette configuration fournit une garantie moindre
+    de durabilité que la configuration <literal>on</literal>&nbsp;: le standby
+    peut perdre les données dans le cas d'un crash du système d'exploitation,
+    mais pas dans le cas du crash de <productname>PostgreSQL</productname>.
+    Cependant, il s'agit d'une configuration utile en pratique car il diminue
+    le temps de réponse pour la transaction. Des pertes de données ne peuvent
+    survenir que si le serveur primaire et le standby tombent en même temps et
+    que la base de données du primaire est corrompue.
    </para>
 
    <para>

postgresql/rangetypes.xml

@@ -96,7 +96,7 @@ SELECT upper(int8range(15, 25));
 -- Calculer l'intersection
 SELECT int4range(10, 20) * int4range(15, 25);
 
--- Est-ce que l'intervalle est non-vide ?
+-- Est-ce que l'intervalle est vide ?
 SELECT isempty(numrange(1, 5));
 </programlisting>