Mise à jour en version 9.1.2

postgresql/backup.xml

@@ -926,7 +926,13 @@ SELECT pg_start_backup('label', true);
     ajustement permet de réduire le risque d'erreurs lors de la restauration.
     C'est facile à réaliser si <filename>pg_xlog/</filename> est un lien
     symbolique vers quelque endroit extérieur au répertoire du cluster, 
-    ce qui est toutefois une configuration courante, pour des raisons de performance.
+    ce qui est toutefois une configuration courante, pour des raisons de
+    performance. Il peut être intéressant d'exclure <filename>postmaster.pid</filename>
+    et <filename>postmaster.opts</filename>, qui enregistrent des
+    informations sur le <application>postmaster</application> en cours
+    d'exécution, mais pas sur le <application>postmaster</application>
+    qui va utiliser cette sauvegarde. De plus, ces fichiers peuvent poser
+    problème à <application>pg_ctl</application>.
    </para>
 
    <para>
@@ -1361,7 +1367,7 @@ tar -rf /var/lib/pgsql/backup.tar /var/lib/pgsql/archive/
       des scripts pour définir leur <varname>archive_command</varname>, de
       sorte que leur <filename>postgresql.conf</filename> semble très simple&nbsp;:
 <programlisting>
-archive_command = 'local_backup_script.sh'
+archive_command = 'local_backup_script.sh "%p" "%f"'
 </programlisting>
       Utiliser un script séparé est conseillé à chaque fois qu'il est envisagé
       d'utiliser plusieurs commandes pour le processus d'archivage.

postgresql/catalogs.xml

@@ -7251,7 +7251,9 @@ lourd ! -->
    l'OID de la classe et l'OID de l'objet, de la même façon que dans
    <structname>pg_description</structname> ou
    <structname>pg_depend</structname>). De plus, le droit d'étendre une
-   relation est représenté comme un objet verrouillable distinct.
+   relation est représenté comme un objet verrouillable distinct. Et
+   enfin, les verrous informatifs peuvent être pris sur les numéros qui
+   ont la signification définie par l'utilisateur.
   </para>
 
   <table>
@@ -7358,21 +7360,18 @@ lourd ! -->
       <entry>
        L'OID de l'objet dans son catalogue système ou NULL si l'objet n'est
        pas un objet général de la base de données.
-       Pour les verrous informatifs, il est utilisé pour distinguer
-       les deux espaces de clé (1 pour une clé int8, 2 pour deux clés int4).
       </entry>
      </row>
      <row>
       <entry><structfield>objsubid</structfield></entry>
       <entry><type>smallint</type></entry>
       <entry></entry>
       <entry>
-       Pour une colonne de table, c'est le numéro de la colonne
+       Numéro de la colonne ciblée par le verrou
        (<structfield>classid</structfield> et <structfield>objid</structfield>
-       font référence à la
-       table elle-même). Pour tous les autres types d'objets, cette colonne
-       vaut 0. NULL si l'objet n'est pas un objet général de la base de
-       données.
+       font référence à la table elle-même), ou 0 si la cible est un
+       autre objet de la base de données, ou NULL si l'objet n'est pas
+       un objet de la base de données.
       </entry>
      </row>
      <row>
@@ -7459,6 +7458,16 @@ lourd ! -->
    la colonne <structfield>database</structfield> a donc un sens dans ce cas.
   </para>
 
+  <para>
+   <structname>pg_locks</structname> fournit une vue globale de tous les verrous
+   du cluster, pas seulement de ceux de la base en cours d'utilisation. Bien que
+   la colonne <structfield>relation</structfield> puisse être jointe avec
+   <structname>pg_class</structname>.<structfield>oid</structfield> pour identifier
+   les relations verrouillées, ceci ne fonctionne correctement qu'avec les
+   relations de la base accédée (celles pour lesquelles la colonne
+   <structfield>database</structfield> est l'OID de la base actuelle ou 0).
+  </para>
+
   <para>
    La vue <structname>pg_locks</structname> affiche des données provenant
    du gestionnaire de verrous standards et du gestionnaire de verrous de
@@ -7476,16 +7485,6 @@ lourd ! -->
    néanmoins être observé si la vue est utilisée fréquemment.
   </para>
 
-  <para>
-   <structname>pg_locks</structname> fournit une vue globale de tous les verrous
-   du cluster, pas seulement de ceux de la base en cours d'utilisation. Bien que
-   la colonne <structfield>relation</structfield> puisse être jointe avec
-   <structname>pg_class</structname>.<structfield>oid</structfield> pour identifier
-   les relations verrouillées, ceci ne fonctionne correctement qu'avec les
-   relations de la base accédée (celles pour lesquelles la colonne
-   <structfield>database</structfield> est l'OID de la base actuelle ou 0).
-  </para>
-
   <para>
    La colonne
    <structfield>pid</structfield> peut être jointe à la colonne

postgresql/client-auth.xml

@@ -1441,7 +1441,9 @@ omicron       bryanh            guest1
       <term><literal>ldapserver</literal></term>
       <listitem>
        <para>
-        Nom ou adresse IP du serveur LDAP auquel se connecter.
+        Noms ou adresses IP des serveurs LDAP auxquels se connecter.
+        Plusieurs serveurs peuvent être indiqués, en les séparant par
+        des espaces.
        </para>
       </listitem>
      </varlistentry>

postgresql/config.xml

@@ -1631,7 +1631,7 @@ block : bloc vidé,  dirty bloc : bloc à vider ?
      </varlistentry>
 
      <varlistentry id="guc-synchronous-commit" xreflabel="synchronous_commit">
-      <term><varname>synchronous_commit</varname> (<type>boolean</type>)</term>
+      <term><varname>synchronous_commit</varname> (<type>enum</type>)</term>
       <listitem>
        <indexterm> 
         <primary>paramètre de configuration <varname>synchronous_commit</varname></primary> 
@@ -6581,16 +6581,7 @@ LOG:  CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
        <para>
         Si activé, génère des informations à propos de l'utilisation de verrous
         utilisateurs. La sortie est la même que pour <symbol>trace_locks</symbol>,
-        mais restreinte aux verrous utilisateurs.
-       </para>
-       <para>
-        Les verrous utilisateurs ont été supprimés depuis PostgreSQL version 8.2.
-        Cette option n'a aucun effet maintenant.
-       </para>
-       <para>
-        Ce paramètre n'est disponible que si la macro <symbol>LOCK_DEBUG</symbol>
-        a été définie quand <productname>PostgreSQL</productname> a été
-        compilé.
+        mais restreinte aux verrous informatifs.
        </para>
       </listitem>
      </varlistentry>

postgresql/dummy-seclabel.xml

@@ -42,7 +42,7 @@
 
 <programlisting>
 # postgresql.conf
-shared_preload_libraries = 'dummy_label'
+shared_preload_libraries = 'dummy_seclabel'
 </programlisting>
 
 <programlisting>

postgresql/extend.xml

@@ -528,6 +528,17 @@
 	 est liée au fait que les fichiers de script sont implicitement exécutés dans une transaction.
     </para>
 
+    <para>
+     An extension's <acronym>SQL</> script files can also contain lines
+     beginning with <literal>\echo</>, which will be ignored (treated as
+     comments) by the extension mechanism.  This provision is commonly used
+     to throw an error if the script file is fed to <application>psql</>
+     rather than being loaded via <command>CREATE EXTENSION</> (see example
+     script below).  Without that, users might accidentally load the
+     extension's contents as <quote>loose</> objects rather than as an
+     extension, a state of affairs that's a bit tedious to recover from.
+    </para>
+
     <para>
 	 Bien que les fichiers de script puissent contenir n'importe quel caractère autorisé
 	 par l'encodage spécifié, les fichiers de contrôle ne peuvent contenir que des caractères
@@ -803,6 +814,9 @@ SELECT * FROM pg_extension_update_paths('<replaceable>extension_name</replaceabl
 	 Le fichier de script <filename>pair--1.0.sql</filename> ressemble à ceci:
 
 <programlisting><![CDATA[
+-- se plaint si le script est exécuté directement dans psql, plutôt que via CREATE EXTENSION
+\echo Use "CREATE EXTENSION pair" to load this file. \quit
+
 CREATE TYPE pair AS ( k text, v text );
 
 CREATE OR REPLACE FUNCTION pair(anyelement, text)

postgresql/func.xml

@@ -1621,7 +1621,7 @@ both</optional>
       </row>
 
       <row>
-       <entry><literal><function>length</function>(<parameter>chaîne</parameter><type>bytea</type>,
+       <entry><literal><function>length</function>(<parameter>chaîne</parameter> <type>bytea</type>,
         <parameter>encodage</parameter> <type>nom</type> )</literal></entry>
        <entry><type>int</type></entry>
        <entry>

postgresql/libpq.xml

@@ -66,9 +66,9 @@
    <function>PQconnectdbParams</function>, ou <function>PQsetdbLogin</function>. Notez que
    ces fonctions renverront toujours un pointeur d'objet non nul, sauf peut-être
    dans un cas de manque de mémoire pour l'allocation de l'objet
-   <structname>PGconn</structname>. La fonction <function>PQstatus</function> doit être appelée
-   pour vérifier si la connexion s'est bien effectuée avant de lancer des
-   requêtes via l'objet de connexion.
+   <structname>PGconn</structname>. La fonction <function>PQstatus</function>
+   doit être appelée pour vérifier le code retour pour une connexion réussie
+   avant de lancer des requêtes via l'objet de connexion.
 
    <warning>
     <para>
@@ -380,7 +380,7 @@
            avant que la connexion du client au serveur ne soit considérée
            comme perdue. Une valeur de zéro utilise la valeur par défaut du
            système. Ce paramètre est uniquement supporté sur les systèmes où
-           l'option <symbol>TCP_KEEPINTVL</symbol> est disponible et sur
+           l'option <symbol>TCP_KEEPCNT</symbol> est disponible et sur
            Windows&nbsp;; pour les autres systèmes, ce paramètre n'a pas
            d'effet.
           </para>
@@ -440,7 +440,10 @@
          <term><literal>require</literal></term>
          <listitem>
           <para>
-           essaie seulement une connexion <acronym>SSL</acronym>
+           essaie seulement une connexion <acronym>SSL</acronym>.
+           Si un certificat racine d'autorité est présent, vérifie
+           le certificat de la même façon que si
+           <literal>verify-ca</literal> était spécifié
           </para>
          </listitem>
         </varlistentry>
@@ -1694,15 +1697,16 @@ SQL et les commandes.
 </para>
 
 <para>
-          Renvoie un pointeur <structname>PGresult</structname> ou peut-être un
-          pointeur NULL.
-          Un pointeur non NULL sera généralement renvoyé sauf dans des
-          conditions particulières comme un manque de mémoire ou lors d'erreurs
-	  sérieuses telles que l'incapacité à envoyer la commande au serveur.
-	  Si un pointeur NULL est renvoyé, il devrait être traité comme un
-	  résultat <symbol>PGRES_FATAL_ERROR</symbol>. Utilisez
-          <function>PQerrorMessage</function> pour obtenir plus d'informations
-          sur l'erreur.
+  Renvoie un pointeur <structname>PGresult</structname> ou peut-être un
+  pointeur NULL.
+  Un pointeur non NULL sera généralement renvoyé sauf dans des
+  conditions particulières comme un manque de mémoire ou lors d'erreurs
+  sérieuses telles que l'incapacité à envoyer la commande au serveur.
+  La fonction <function>PQresultStatus</> devrait être appelée pour
+  vérifier le code retour  pour toute erreur (incluant la valeur d'un
+  pointeur nul, auquel cas il renverra <symbol>PGRES_FATAL_ERROR</symbol>).
+  Utilisez <function>PQerrorMessage</function> pour obtenir plus
+  d'informations sur l'erreur.
 </para>
 </listitem>
 </varlistentry>
@@ -6268,6 +6272,19 @@ ldap://ldap.masociété.com/dc=masociété,dc=com?uniqueMember?one?(cn=mabase)
    <envar>PGSSLROOTCERT</envar> et <envar>PGSSLCRL</envar>.
   </para>
 
+  <note>
+   <para>
+    Pour une compatibilité ascendantes avec les anciennes versions de
+    PostgreSQL, si un certificat racine d'autorité existe, le comportement
+    de <literal>sslmode</literal>=<literal>require</literal> sera identique
+    à celui de <literal>verify-ca</literal>. Cela signifie que le
+    certificat du serveur est validé par l'autorité de certificat. Il ne
+    faut pas se baser sur ce comportement. Les applications qui ont besoin
+    d'une validation du certificat doivent toujours utiliser
+    <literal>validate-ca</literal> ou <literal>validate-full</literal>.
+   </para>
+  </note>
+
  </sect2>
 
  <sect2 id="libpq-ssl-clientcert">

postgresql/protocol.xml

@@ -1886,6 +1886,11 @@ Les commandes acceptées en mode walsender sont:
          <filename>postmaster.pid</filename>
         </para>
        </listitem>
+       <listitem>
+        <para>
+         <filename>postmaster.opts</filename>
+        </para>
+       </listitem>
        <listitem>
         <para>
          <filename>pg_xlog</filename>, ainsi que les sous-répertoires.

postgresql/ref/psql-ref.xml

@@ -2198,10 +2198,11 @@ lo_import 152801
 
 
       <varlistentry>
-        <term><literal>\q</literal></term>
+        <term><literal>\q</literal> ou <literal>\quit</literal></term>
         <listitem>
         <para>
         Quitte le programme <application>psql</application>.
+        Avec un script, seule l'exécution du script est terminée.
         </para>
         </listitem>
       </varlistentry>

postgresql/ref/select.xml

@@ -1099,18 +1099,19 @@ OFFSET <replaceable class="parameter">début</replaceable>
 OFFSET <replaceable class="parameter">début</replaceable> { ROW | ROWS }
 FETCH { FIRST | NEXT } [ <replaceable class="parameter">compte</replaceable> ] { ROW | ROWS } ONLY
 </synopsis>
-    D'après le standard, la clause <literal>OFFSET</literal> doit être placée
-    avant la clause <literal>FETCH</literal> si les deux sont présentes &nbsp;; mais
-    <productname>PostgreSQL</productname> est plus souple et autorise n'importe quel ordre.
-    <literal>ROW</literal> et <literal>ROWS</literal> ainsi que
-    <literal>FIRST</literal> et <literal>NEXT</literal> sont du bruit et
-    n'ont pas d'influence sur les effets de ces clauses. Dans cette syntaxe, quand
-    on utilise des expressions autres que des simples constantes pour
-    <replaceable class="parameter">début</replaceable>
-    ou <replaceable class="parameter">compte</replaceable>, des parenthèses seront
-    nécessaires dans la plupart des cas. Si <replaceable
-    class="parameter">compte</replaceable> est omis dans <literal>FETCH</literal>,
-    il prend 1 comme valeur par défaut.
+    Avec cette syntaxe, pour écrire tout sauf une simple constant de type
+    entier pour <replaceable class="parameter">début</replaceable> ou
+    <replaceable class="parameter">compte</replaceable>, vous devez
+    l'entourer de parenthèses.
+    Si <replaceable class="parameter">compte</replaceable> est omis dans une clause
+    <literal>FETCH</literal>, il vaut 1 par défaut.
+    <literal>ROW</literal> et <literal>ROWS</literal> ainsi que <literal>FIRST</literal>
+    et <literal>NEXT</literal> sont des mots qui n'influencent pas les
+    effets de ces clauses.
+    D'après le standard, la clause <literal>OFFSET</literal> doit venir
+    avant la clause <literal>FETCH</literal> si les deux sont
+    présentes&nbsp;; <productname>PostgreSQL</> est plus  laxiste et
+    autorise un ordre différent.
    </para>
 
    <para>
@@ -1296,8 +1297,10 @@ ROLLBACK TO s;
 
   <caution>
    <para>
-    Il est possible qu'une commande <command>SELECT</command> utilisant <literal>ORDER
-    BY</literal> et <literal>FOR UPDATE/SHARE</literal> renvoie les lignes dans le
+    Il est possible qu'une commande <command>SELECT</command> exécutée
+    au niveau d'isolation <literal>READ COMMITTED</literal> et utilisant
+    <literal>ORDER BY</literal> et <literal>FOR UPDATE/SHARE</literal>
+    renvoie les lignes dans le
     désordre. C'est possible car l' <literal>ORDER BY</literal> est appliqué en premier.
     La commande trie le résultat, mais peut alors être bloquée le temps d'obtenir un verrou
     sur une ou plusieurs des lignes. Une fois que le <literal>SELECT</literal> est débloqué, des
@@ -1317,6 +1320,14 @@ SELECT * FROM (SELECT * FROM matable FOR UPDATE) ss ORDER BY column1;
     vous vous attendez à des mises à jour concurrentes sur les colonnes servant à l'ordonnancement
     et qu'un résultat strictement ordonné est requis.
    </para>
+
+   <para>
+    Au niveau d'isolation de transactions <literal>REPEATABLE READ</literal>
+    et <literal>SERIALIZABLE</literal>, cela causera une erreur de
+    sérialisation (avec un <literal>SQLSTATE</literal> valant
+    <literal>'40001'</literal>), donc il n'est pas possible de recevoir
+    des lignes non triées avec ces niveaux d'isolation.
+   </para>
   </caution>
 
   </refsect2>