Mise à jour en version 13.1

postgresql/bloom.xml

@@ -1,6 +1,4 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- doc/src/sgml/bloom.sgml -->
-
 <sect1 id="bloom" xreflabel="bloom">
  <title>bloom</title>
 
@@ -118,76 +116,69 @@ CREATE INDEX bloomidx ON tbloom USING bloom (i1,i2,i3)
    FROM
   generate_series(1,10000000);
 SELECT 10000000
-=# CREATE INDEX bloomidx ON tbloom USING bloom (i1, i2, i3, i4, i5, i6);
-CREATE INDEX
-=# SELECT pg_size_pretty(pg_relation_size('bloomidx'));
- pg_size_pretty
-----------------
- 153 MB
-(1 row)
-=# CREATE index btreeidx ON tbloom (i1, i2, i3, i4, i5, i6);
-CREATE INDEX
-=# SELECT pg_size_pretty(pg_relation_size('btreeidx'));
- pg_size_pretty
-----------------
- 387 MB
-(1 row)
 </programlisting>
 
   <para>
    Un parcours séquentiel sur cette grande table prend beaucoup de temps&nbsp;:
 <programlisting>
 =# EXPLAIN ANALYZE SELECT * FROM tbloom WHERE i2 = 898732 AND i5 = 123451;
-                                                 QUERY PLAN
-------------------------------------------------------------------------------------------------------------
- Seq Scan on tbloom  (cost=0.00..213694.08 rows=1 width=24) (actual time=1445.438..1445.438 rows=0 loops=1)
+                                              QUERY PLAN
+------------------------------------------------------------------------------------------------------
+ Seq Scan on tbloom  (cost=0.00..2137.14 rows=3 width=24) (actual time=19.059..19.060 rows=0 loops=1)
    Filter: ((i2 = 898732) AND (i5 = 123451))
-   Rows Removed by Filter: 10000000
- Planning time: 0.177 ms
- Execution time: 1445.473 ms
+   Rows Removed by Filter: 100000
+ Planning time: 0.269 ms
+ Execution time: 19.077 ms
 (5 rows)
 </programlisting>
   </para>
 
   <para>
-   En général, l'optimiseur sélectionnera un parcours d'index si c'est
-   possible. Avec un index btree, nous obtenons ceci&nbsp;:
+   Même avec l'index btree défini, le résultat sera toujours un parcours
+   séquentiel&nbsp;:
 <programlisting>
+=# CREATE INDEX btreeidx ON tbloom (i1, i2, i3, i4, i5, i6);
+CREATE INDEX
+=# SELECT pg_size_pretty(pg_relation_size('btreeidx'));
+ pg_size_pretty
+----------------
+ 3992 kB
+(1 row)
 =# EXPLAIN ANALYZE SELECT * FROM tbloom WHERE i2 = 898732 AND i5 = 123451;
-                                                           QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------
- Index Only Scan using btreeidx on tbloom  (cost=0.56..298311.96 rows=1 width=24) (actual time=445.709..445.709 rows=0 loops=1)
-   Index Cond: ((i2 = 898732) AND (i5 = 123451))
-   Heap Fetches: 0
- Planning time: 0.193 ms
- Execution time: 445.770 ms
-(5 rows)
+                                              QUERY PLAN
+------------------------------------------------------------------------------------------------------
+ Seq Scan on tbloom  (cost=0.00..2137.00 rows=2 width=24) (actual time=15.070..15.070 rows=0 loops=1)
+   Filter: ((i2 = 898732) AND (i5 = 123451))
+   Rows Removed by Filter: 100000
+ Planning time: 0.130 ms
+ Execution time: 15.083 ms
 </programlisting>
   </para>
 
   <para>
-   Bloom est meilleur que btree pour gérer ce type de recherche&nbsp;:
+   Avoir un index bloom défini sur la table est préférable à un btree pour
+   gérer ce type de recherche&nbsp;:
 <programlisting>
+=# CREATE INDEX bloomidx ON tbloom USING bloom (i1, i2, i3, i4, i5, i6);
+CREATE INDEX
+=# SELECT pg_size_pretty(pg_relation_size('bloomidx'));
+ pg_size_pretty
+----------------
+ 1584 kB
+(1 row)
 =# EXPLAIN ANALYZE SELECT * FROM tbloom WHERE i2 = 898732 AND i5 = 123451;
-                                                        QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------
- Bitmap Heap Scan on tbloom  (cost=178435.39..178439.41 rows=1 width=24) (actual time=76.698..76.698 rows=0 loops=1)
+                                                     QUERY PLAN
+---------------------------------------------------------------------------------------------------------------------
+ Bitmap Heap Scan on tbloom  (cost=1792.00..1799.69 rows=2 width=24) (actual time=0.456..0.456 rows=0 loops=1)
    Recheck Cond: ((i2 = 898732) AND (i5 = 123451))
-   Rows Removed by Index Recheck: 2439
-   Heap Blocks: exact=2408
-   -&gt;  Bitmap Index Scan on bloomidx  (cost=0.00..178435.39 rows=1 width=0) (actual time=72.455..72.455 rows=2439 loops=1)
+   Rows Removed by Index Recheck: 29
+   Heap Blocks: exact=27
+   -&gt;  Bitmap Index Scan on bloomidx  (cost=0.00..1792.00 rows=2 width=0) (actual time=0.422..0.423 rows=29 loops=1)
          Index Cond: ((i2 = 898732) AND (i5 = 123451))
- Planning time: 0.475 ms
- Execution time: 76.778 ms
+ Planning time: 0.105 ms
+ Execution time: 0.477 ms
 (8 rows)
  </programlisting>
-   Noter le nombre relativement important de faux positifs&nbsp;: 2349 lignes
-   ont été sélectionnées pour vérification dans la table, mais aucune ne correspondait 
-   au filtre de la requête. Nous pouvons réduire cela en
-   spécifiant une longueur de signature plus importante. Dans cet exemple,
-   créer l'index avec <literal>length=200</literal> a réduit le nombre de faux
-   positifs à 55 mais doublé la taille de l'index (306 Mo) et
-   s'est révélé plus lent pour cette requête (125 ms en tout).
   </para>
 
   <para>
@@ -197,24 +188,37 @@ CREATE INDEX
    est de créer un index séparé pour chaque colonne. À ce moment-là,
    l'optimiseur pourra choisir quelque chose comme&nbsp;:
 <programlisting>
+=# CREATE INDEX btreeidx1 ON tbloom (i1);
+CREATE INDEX
+=# CREATE INDEX btreeidx2 ON tbloom (i2);
+CREATE INDEX
+=# CREATE INDEX btreeidx3 ON tbloom (i3);
+CREATE INDEX
+=# CREATE INDEX btreeidx4 ON tbloom (i4);
+CREATE INDEX
+=# CREATE INDEX btreeidx5 ON tbloom (i5);
+CREATE INDEX
+=# CREATE INDEX btreeidx6 ON tbloom (i6);
+CREATE INDEX
 =# EXPLAIN ANALYZE SELECT * FROM tbloom WHERE i2 = 898732 AND i5 = 123451;
-                                                          QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------
- Bitmap Heap Scan on tbloom  (cost=9.29..13.30 rows=1 width=24) (actual time=0.148..0.148 rows=0 loops=1)
+                                                        QUERY PLAN
+---------------------------------------------------------------------------------------------------------------------------
+ Bitmap Heap Scan on tbloom  (cost=24.34..32.03 rows=2 width=24) (actual time=0.029..0.029 rows=0 loops=1)
    Recheck Cond: ((i5 = 123451) AND (i2 = 898732))
-   -&gt;  BitmapAnd  (cost=9.29..9.29 rows=1 width=0) (actual time=0.145..0.145 rows=0 loops=1)
-         -&gt;  Bitmap Index Scan on tbloom_i5_idx  (cost=0.00..4.52 rows=11 width=0) (actual time=0.089..0.089 rows=10 loops=1)
+   -&gt;  BitmapAnd  (cost=24.34..24.34 rows=2 width=0) (actual time=0.028..0.028 rows=0 loops=1)
+         -&gt;  Bitmap Index Scan on btreeidx5  (cost=0.00..12.04 rows=500 width=0) (actual time=0.027..0.027 rows=0 loops=1)
                Index Cond: (i5 = 123451)
-         -&gt;  Bitmap Index Scan on tbloom_i2_idx  (cost=0.00..4.52 rows=11 width=0) (actual time=0.048..0.048 rows=8 loops=1)
+         -&gt;  Bitmap Index Scan on btreeidx2  (cost=0.00..12.04 rows=500 width=0) (never executed)
                Index Cond: (i2 = 898732)
- Planning time: 2.049 ms
- Execution time: 0.280 ms
+ Planning time: 0.389 ms
+ Execution time: 0.054 ms
 (9 rows)
  </programlisting>
-   Bien que cette requête soit bien plus rapide qu'avec n’importe lequel des index à une colonne,
-   nous payons une large pénalité en taille d'index. Chacun des
-   index btree mono-colonne occupe 214 Mo, soit un espace total de plus de
-   1,2 Go, autrement dit huit fois la place utilisée par l'index bloom.
+   Bien que cette requête soit bien plus rapide qu'avec n’importe lequel des
+   index à une colonne,
+   nous payons une pénalité en taille d'index. Chacun des
+   index btree mono-colonne occupe 2 Mo, soit un espace total de plus de
+   12 Mo, autrement dit huit fois la place utilisée par l'index bloom.
   </para>
  </sect2>
 

postgresql/client-auth.xml

@@ -2144,15 +2144,10 @@ host ... radius radiusservers="server1,server2" radiussecrets="""secret one"",""
    </para>
 
    <para>
-    Dans un enregistrement de <filename>pg_hba.conf</filename> indiquant une
-    authentification par certificat, l'option d'authentification
-    <literal>clientcert</literal> est supposée valoir
-    <literal>verify-ca</literal> ou <literal>verify-full</literal>, et
-    elle ne peut pas être désactivée car un certificat client est nécessaire
-    pour cette méthode. Ce que la méthode <literal>cert</literal> ajoute au
-    test basique de validité du certificat <literal>clientcert</literal> est
-    une vérification que l'attribut <literal>cn</literal> correspond à un nom
-    d'utilisateur de la base.
+    Il est redondant d'utiliser l'option <literal>clientcert</literal> avec
+    l'authentification <literal>cert</literal> parce que l'authentification
+    <literal>cert</literal> est réellement l'authentification
+    <literal>trust</literal> avec <literal>clientcert=verify-full</literal>.
    </para>
   </sect1>
 

postgresql/config.xml

@@ -2778,16 +2778,26 @@ block : bloc vidé,  dirty bloc : bloc à vider ?
      <primary>paramètre de configuration <varname>synchronous_commit</varname></primary>
     </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_apply</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"/>.)
+     Indique quel traitement des WAL doit se faire avant que le serveur de
+     bases de données ne renvoie une indication de <quote>succès</quote> au
+     client. Les valeurs valides sont <literal>remote_apply</literal>,
+     <literal>on</literal> (par défaut), <literal>remote_write</literal>,
+     <literal>local</literal> et <literal>off</literal>.
+    </para>
+
+    <para>
+     Si <varname>synchronous_standby_names</varname> est vide, les seules
+     valeurs sensées sont <literal>on</literal> et
+     <literal>off</literal>&nbsp;;  <literal>remote_apply</literal>,
+     <literal>remote_write</literal> et <literal>local</literal> fournissent
+     toutes le même niveau de synchronisation locale que
+     <literal>on</literal>. Le comportement local de tous les modes différents
+     de <literal>off</literal> est d'attendre le vidage local sur disque des
+     WAL. Dans le mode <literal>off</literal>, il n'y a pas d'attente, donc il
+     peut y avoir un délai entre le retour du succès au client et le fait que
+     la transaction est garantie d'être sécurisée contre un crash 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
@@ -2800,43 +2810,43 @@ block : bloc vidé,  dirty bloc : bloc à vider ?
      sûreté de la transaction. Pour plus de discussion, voir <xref
      linkend="wal-async-commit"/>.
     </para>
+
     <para>
-     Si <xref linkend="guc-synchronous-standby-names"/> n'est pas vide, ce
-     paramètre contrôle aussi si les validations de transaction attendent que
-     les enregistrements de transaction associés soient répliqués sur les
-     serveurs standbys. Configuré à <literal>on</literal>, les validations
-     attendront les réponses des standbys synchrones courants indiquant qu'ils
-     ont reçu l'enregistrement de validation de la transaction et qu'ils l'ont
-     enregistré sur disque. Ceci assure que la transaction ne sera pas perdu,
-     sauf si le serveur primaire et tous les serveurs secondaires synchrones
-     souffrent de corruption sur le stockage de la base de données. Si
-     configuré à <literal>remote_apply</literal>, les validations attendent
-     les réponses des différents serveurs standbys synchrones indiquant
-     qu'elles ont reçus l'enregistrement de validation de la transaction et
-     qu'elles l'ont appliqué, de façon à ce que le résultat soit visibles par
-     les requêtes exécutées sur les standbys. Si configuré à
-     <literal>remote_write</literal>, les validations attendent les réponses
-     des standbys synchrones courants indiquant qu'elles ont reçu
-     l'enregistrement de validation de la transaction et qu'elles l'ont donné
-     au système d'exploitation pour écriture sur le disque. Cette
-     configuration est suffisante pour s'assurer de la préservation des
-     données même si l'instance standby de
-     <productname>PostgreSQL</productname> devait s'arrêter brutalement, mais
-     pas si le standby souffre d'un crash au niveau du système d'exploitation
-     car les données n'ont pas forcément encore atteint un stockage stable sur
-     le standby. Enfin, la configuration <literal>local</literal> force les
-     validations à attendre que les données soient enregistrées sur disque,
-     localement, mais pas répliquées. Ceci n'est généralement pas souhaitable
-     lors de l'utilisation d'une réplication synchrone mais est proposé pour
-     offrir une solution complète.
-    </para>
-    <para>
-     Si <varname>synchronous_standby_names</varname> est vide, les
-     configurations <literal>on</literal>, <literal>remote_apply</literal>,
-     <literal>remote_write</literal> et <literal>local</literal> fournissent
-     toutes le même niveau de synchronisation&nbsp;: les validations de
-     transactions attendent seulement l'enregistrement local sur disque.
+     Si <xref linkend="guc-synchronous-standby-names"/> n'est pas vide,
+     <varname>synchronous_commit</varname> contrôle aussi si les validations
+     de transactions attendront que leurs enregistrements WAL soient traités
+     sur le serveur secondaire.
     </para>
+
+    <para>
+     Quand il est configuré à <literal>remote_apply</literal>, les validations
+     attendront la réponse des serveurs secondaires synchrones indiquant
+     qu'ils ont bien reçu l'enregistrement de validation de la transaction et
+     qu'ils l'ont bien appliqués, pour qu'elle devienne visible aux requêtes
+     sur les serveurs secondaires, et aussi écrites sur un stockage durable.
+     Ceci causera les plus gros délais de validation par rapport aux
+     configurations précédentes car il faut attendre le rejeu des WAL. Quand
+     il est configuré à <literal>on</literal>, les validations attendent que
+     les réponses des serveurs secondaires synchrones indiquent qu'ils ont
+     reçu l'enregistrement de validation de la transaction et qu'ils l'ont
+     écrit sur un stockage durable. Ceci assure que la transaction ne sera pas
+     perdu sauf si le primaire et les secondaires synchrones souffrent de
+     corruption au niveau disque. Quand il est configuré à
+     <literal>remote_write</literal>, les validations attendront que les
+     réponses des serveurs secondaires synchrones indiquent avoir reçu
+     l'enregistrement de validation de la transaction et l'avoir écrit sur
+     disque. Ce paramétrage assure de la préservation des données si une
+     instance secondaire de <productname>PostgreSQL</productname> s'arrête
+     brutalement, mais pas si le serveur secondaire souffre d'un crash au
+     niveau du système d'exploitation parce que les données n'ont pas
+     nécessairement atteint un stockage durable sur le secondaire. Le
+     paramétrage <literal>local</literal> fait que les validations attendent
+     uniquement le vidage local sur disque, mais n'attendent pas le retour des
+     serveurs secondaires synchrones. Ceci n'est généralement pas souhaité
+     quand la réplication synchrone est utilisée mais est fourni pour être
+     complet.
+    </para>
+
     <para>
      Ce paramètre peut être changé à tout moment&nbsp;; le comportement
      pour toute transaction est déterminé par la configuration en cours
@@ -2847,6 +2857,70 @@ block : bloc vidé,  dirty bloc : bloc à vider ?
      l'instruction <command>SET LOCAL synchronous_commit TO OFF</command>
      dans la transaction.
     </para>
+
+    <para>
+     <xref linkend="synchronous-commit-matrix"/> résume les possibilités
+     de configuration de <varname>synchronous_commit</varname>.
+    </para>
+
+    <table id="synchronous-commit-matrix">
+     <title>Modes pour synchronous_commit</title>
+     <tgroup cols="5">
+      <colspec colname="col1" colwidth="1.5*"/>
+      <colspec colname="col2" colwidth="1*"/>
+      <colspec colname="col3" colwidth="1*"/>
+      <colspec colname="col4" colwidth="1*"/>
+      <colspec colname="col5" colwidth="1*"/>
+      <thead>
+       <row>
+        <entry>synchronous_commit</entry>
+        <entry>validation locale durable</entry>
+        <entry>valide durable du standby après un crash de PG</entry>
+        <entry>valide durable du standby après un crash de l'OS</entry>
+        <entry>cohérence des requêtes sur le standby</entry>
+       </row>
+      </thead>
+
+      <tbody>
+       <row>
+        <entry>remote_apply</entry>
+        <entry align="center">&bull;</entry>
+        <entry align="center">&bull;</entry>
+        <entry align="center">&bull;</entry>
+        <entry align="center">&bull;</entry>
+       </row>
+       <row>
+        <entry>on</entry>
+        <entry align="center">&bull;</entry>
+        <entry align="center">&bull;</entry>
+        <entry align="center">&bull;</entry>
+        <entry align="center"></entry>
+       </row>
+       <row>
+        <entry>remote_write</entry>
+        <entry align="center">&bull;</entry>
+        <entry align="center">&bull;</entry>
+        <entry align="center"></entry>
+        <entry align="center"></entry>
+       </row>
+       <row>
+        <entry>local</entry>
+        <entry align="center">&bull;</entry>
+        <entry align="center"></entry>
+        <entry align="center"></entry>
+        <entry align="center"></entry>
+       </row>
+       <row>
+        <entry>off</entry>
+        <entry align="center"></entry>
+        <entry align="center"></entry>
+        <entry align="center"></entry>
+        <entry align="center"></entry>
+       </row>
+      </tbody>
+     </tgroup>
+    </table>
+
    </listitem>
   </varlistentry>