Mise à jour en version 2.0.3.

Reste encore le fichier faq.xml qui n'est pas entièrement traduit.

Author: gleu

slony/adminscripts.xml

@@ -250,6 +250,18 @@ pour les outils Perl</primary></indexterm>
 
 </sect3>
 
+<sect3 id="slonik-drop-sequence">
+<title>slonik_drop_sequence</title>
+
+<para>
+  Cette commande produit un script Slonik pour supprimer une séquence de la
+  réplication. Est requis en entrée l'identifiant de la séquence (disponible à
+  partir de la table <envar>sl_table</envar>) qui est à supprimer et
+  l'identifiant de l'ensemble auquel elle est attachée.
+</para>
+
+</sect3>
+
 <sect3>
 <title>slonik_execute_script</title>
 
@@ -1396,4 +1408,5 @@ abonnements doivent être appliqués.
 </para>
 
 </sect2>
+
 </sect1>

slony/dropthings.xml

@@ -113,20 +113,23 @@
 </sect2>
 
 <sect2>
-<title> Retirer une table de la réplication</title>
+<title>Retirer une table de la réplication</title>
 <indexterm><primary>retirer une table de la réplication</primary></indexterm>
 
 <sect3>
 <title>En utilisant les outils altperl</title>
 
 <para>
   Si les outils <link linkend="altperl">altperl</link> sont installés, vous
-  pouvez utiliser le script d'aide <link
-  linkend="slonik-drop-table">slonik_drop_table</link> pour supprimer une table
-  dans un ensemble de réplication. Lancez simplement
-  <command>slonik_drop_table</command> sans arguments pour afficher la méthode
-  d'utilisation du script. Après avoir retiré la table, vous devez également la
-  retirer du fichier <filename>slon_tools.conf</filename>.
+  pouvez utiliser les scripts d'aide <link
+  linkend="slonik-drop-table">slonik_drop_table</link> et <link
+  linkend="slonik-drop-sequence">slonik_drop_sequence</link> pour supprimer
+  une table ou une séquence de la réplication. Exécutez simplement
+  <command>slonik_drop_table</command> (ou
+  <command>slonik_drop_sequence</command>) sans arguments pour afficher
+  la syntaxe d'exécution du script. Après avoir supprimé la table, vous devez
+  aussi la supprimer du fichier de configuration
+  <filename>slon_tools.conf</filename>.
 </para>
 
 </sect3>

slony/faq.xml

@@ -421,6 +421,28 @@ server: Error 0</screen>
       </para>
     </answer>
   </qandaentry>
+
+<qandaentry>
+
+<question> <para> I found conflicting types for <envar>yyleng</envar>
+between <filename>parser.c</filename> and <filename>scan.c</filename>.
+In one case, it used type <type>int</type>, conflicting with
+<type>yy_size_t</type>.  What shall I do?</para> </question>
+
+<answer><para> This has been observed on <application>MacOS</application>,
+where <application>flex</application> (which generates
+<filename>scan.c</filename>) and <application>bison</application>
+(which generates <filename>parser.c</filename>) diverged in their
+handling of this variable. </para> 
+<itemizedlist>
+<listitem><para> You might might <quote>hack</quote> <filename>scan.c</filename> by hand to use the matching type. </para> </listitem>
+<listitem><para> You might select different versions of <application>bison</application> or <application>flex</application> so as to get versions whose data types match. </para> </listitem>
+<listitem><para> Note that you may have multiple versions of <application>bison</application> or <application>flex</application> around, and might need to modify <envar>PATH</envar> in order to select the appropriate one.</para></listitem>
+</answer>
+
+
+
+</qandaentry>
 </qandadiv>
 
 <qandadiv id="faqhowto"> <title> &slony1; FAQ: How Do I? </title>
@@ -1933,6 +1955,78 @@ CONTEXT:  PL/pgSQL function "setaddtable_int" line 71 at SQL statement</screen>
       </para>
     </answer>
   </qandaentry>
+
+<qandaentry>
+
+<question> <para>As of version 8.3, &postgres; offers a
+<envar>synchronous_commit</envar> parameter which may be set either
+via GUC or <filename>postgresql.conf</filename> which can provide some
+performance gains by not logging results in WAL.  Would it be sensible
+to turn off synchronous commit on a subscriber node?  </para>
+</question>
+
+<answer><para> Unfortunately, there is an unpleasant failure case
+which this would introduce. </para>
+
+<para>Consider...</para>
+
+<itemizedlist>
+
+<listitem><para> Node #2 claims to have committed up to transaction
+T5, but the WAL only really has records up to T3.</para></listitem>
+
+<listitem><para> Node #1, the "master", got the report back that #2 is
+up to date to T5.</para></listitem>
+
+<listitem><para> Node #2 experiences a failure (e.g. - power
+outage).</para></listitem>
+
+</itemizedlist>
+
+<para>There are two possible outcomes, now, one OK, and one not so OK...</para>
+
+<itemizedlist>
+
+<listitem><para> OK </para>
+
+<para> Node #2 gets restarted, replays WAL, knows it's only got data
+up to T3, and heads back to node #1, asking for transaction T4 and
+others.</para>
+
+<para> No problem.</para></listitem>
+
+<listitem><para> Not so OK.</para>
+
+<para> Before node #2 gets back up, node #1 has run an iteration of
+the cleanup thread, which trims out all the data up to T5, because the
+other nodes confirmed up to that point.</para>
+
+<para> Node #2 gets restarted, replays WAL, knows it's only got data
+up to T3, and heads back to node #1, asking for transaction T4 and
+T5.</para>
+
+<para> Oops.  Node #1 just trimmed those log entries
+out.</para></listitem>
+</itemizedlist>
+
+<para>The race condition here is quite easy to exercise - you just
+need to suppress the restart of node 2 for a while, long enough for
+node 1 to run the cleanup thread.</para>
+
+<para>You might evade the problem somewhat by setting the &lslon; parameter
+<xref linkend="slon-config-cleanup-interval"/> to a larger value.</para>
+
+<para>Unfortunately, any time the outage of node 2 could exceed that
+interval, the risk of losing log data inexorably emerges.</para>
+
+</answer>
+
+<answer><para> As a result, it cannot be recommended that users run
+&slony1; in a fashion where it suppresses WAL writing via
+<envar>synchronous_commit</envar>. </para> </answer>
+
+</qandaentry>
+
 </qandadiv>
 
 <qandadiv id="faqperformance">

slony/intro.xml

@@ -231,12 +231,15 @@
   jour sur les tables répliquées à l'exception de celles effectuées par le
   processus <xref linkend="slon"/>. De plus, tous les
   <emphasis>autres</emphasis> triggers et règles sur les tables répliquées sont
-  <emphasis>supprimés</emphasis> sur les n&oelig;uds abonnés&nbsp;; ceci est
-  réalisé en faisant pointer ces tables, dans le catalogue système, vers les
-  index des clefs primaires plutôt que sur la table elle-même. Cela s'apparente
-  à une <quote>corruption</quote> du dictionnaire de données, et cela explique
-  pourquoi on ne peut pas utiliser directement <application>pg_dump</application>
-  pour exporter le schéma sur les n&oelig;uds abonnés.
+  <emphasis>supprimés</emphasis> sur les n&oelig;uds abonnés. Sur les versions
+  de &slony1; antérieures à la 2.0, cela se fait en les pointant, dans la table
+  système, vers l'index de la clé primaire au lieu de la table elle-même, ce
+  qui représente une <quote>corruption</quote> du dictionnaire des données et
+  qui explique pourquoi vous ne devez pas utiliser directement
+  <application>pg_dump</application> pour sauvegarder les schémas sur les
+  abonnés. En version 2.0, cette fonctionnalité est gérée via une fonctionnalité
+  native de &postgres;. Du coup, avec &slony1; 2.0+,
+  <application>pg_dump</application> doit fonctionner correctement.
 </para>
 
 <para>
@@ -278,6 +281,12 @@
   </itemizedlist>
 </para>
 
+<para>
+  &slony1; ne détermine pas automatiquement les séquences devant être
+  répliquées&nbsp;; vous devez les ajouter explicitement en utilisant <xref
+  linkend="stmtsetaddsequence"/>.
+</para>
+
 </sect2>
 
 <sect2>

slony/legal.xml

@@ -5,15 +5,15 @@
      révision $Revision$ -->
 
 <copyright>
- <year>2004-2007</year>
+ <year>2004-2009</year>
  <holder>The PostgreSQL Global Development Group</holder>
 </copyright>
 
 <legalnotice id="legalnotice">
  <title>Notice légale</title>
 
  <para>
-  <productname>PostgreSQL</productname> est sous le Copyright &amp;copy; 2004-2007
+  <productname>PostgreSQL</productname> est sous le Copyright &amp;copy; 2004-2009
   du PostgreSQL Global Development Group et est distribué sous les termes
   de la licence de l'Université de Californie ci-dessous.
  </para>

slony/prerequisites.xml

@@ -61,49 +61,9 @@
       <para>
         Vous avez également besoin d'une version <emphasis>source</emphasis>
         récente de &postgres;. &slony1; dépend du support des schémas, ce qui
-	nécessite au minimum une version 7.3.3 de &postgres; pour pouvoir
-	compiler et utiliser &slony1;.
+        nécessite au minimum une version 8.3 de &postgres; pour pouvoir
+        compiler et utiliser &slony1;.
       </para>
-
-      <para>
-        Les versions antérieures de &postgres; <emphasis>ne sont pas</emphasis>
-        supportées, mais notez qu'un utilisateur a réussi à <quote>forcer</quote>
-        l'utilisation de &slony1; dans le cadre d'une migration d'une version
-	7.2 vers une version 7.4&nbsp;; voir les <link linkend="v72upgrade">notes
-	sur &postgres; 7.2</link>.
-      </para>
-
-      <para>
-        Les versions de &postgres; antérieures à la 7.4.8 peuvent rencontrer
-	une requête sans fin conduisant à un problème de <link
-	linkend="dupkey"><quote>duplicate keys</quote></link> (clés dupliquées),
-	vous devrez alors envisager une mise à jour pour éviter ce type d'erreur.
-      </para>
-
-      <para>
-        Si vous utiliser une version de &postgres; antérieure à la version 8.0,
-	vous devez vous assurer que les fichiers d'en-tête de serveur sont
-	installés. Si vous installez depuis les sources, cela se fait par la
-	commande <command>make install-all-headers</command>. Sinon, vous
-	rencontrerez le problème <link linkend="missingheaders">missing headers
-	for libpqserver</link> (en-têtes manquants pour libpqserver), comme
-	décrit dans la FAQ.
-      </para>
-
-      <para>
-        Si vous utilisez les versions 8.1.0 à 8.1.3, un bogue (corrigé en
-	8.1.4) empêche la fonction <xref linkend="stmtupdatefunctions"/>
-	de s'exécuter correctement. Pour plus de détails, voir
-	<xref linkend="faq" />, <link linkend="pg81funs">&postgres;
-	8.1.[0-3]</link>.
-      </para>
-
-      <para>
-        Certaines versions de &postgres; ne sont pas compatibles avec certaines
-	versions de &slony1;. Voir <xref linkend="installation"/> pour plus de
-	détails.
-      </para>
-
     </listitem>
 
     <listitem>
@@ -140,9 +100,9 @@
       <para>
         Sous &windows;, vous aurez aussi besoin de la boîte à outils <ulink
         url="http://www.postgresql.org/docs/faqs.FAQ_MINGW.html">MinGW/
-	Msys</ulink> pour compiler les versions 8.0 et supérieures de
-	&postgres;. De plus, vous devez installer <ulink
-	url="http://sourceware.org/pthreads-win32/">pthreads-win32 2.x</ulink>.
+        Msys</ulink> pour compiler les versions 8.3 et supérieures de
+        &postgres;. De plus, vous devez installer <ulink
+        url="http://sourceware.org/pthreads-win32/">pthreads-win32 2.x</ulink>.
       </para>
     </listitem>
   </itemizedlist>
@@ -156,9 +116,8 @@
 
 <note>
   <para>
-    À partir de la version 1.1 de &slony1;, il est possible de compiler &slony1;
-    séparemment de &postgres;, rendant libres les distributions
-    <productname>Linux</productname> et
+    Il est possible de compiler &slony1; séparemment de &postgres;, rendant
+    libres les distributions <productname>Linux</productname> et
     <productname>FreeBSD</productname> d'inclure des packages binaires
     précompilés pour &slony1;. Si de tels packages ne sont pas disponibles,
     vous devez vous préparer à compiler &slony1; par vous-même.
@@ -197,13 +156,6 @@
   entre ces différents encodages, vous pouvez ne jamais rencontrer de problème.
 </para>
 
-<para>
-  Dans la version 8.1 de &postgres;, des modifications ont été apportées à
-  l'encodage <envar>UNICODE</envar> car les versions précédentes acceptaient
-  des encodages invalides. Cela pouvait conduire à des <link
-  linkend="faqunicode">problèmes de replication</link>.
-</para>
-
 <para>
   Notez que si l'encodage client (configuré soit dans
   <filename>postgresql.conf</filename>, soit par le paramètre

slony/slonik_ref.xml

@@ -505,8 +505,11 @@ INIT CLUSTER (
       </varlistentry>
       <varlistentry><term><literal>EVENT NODE = ival</literal></term>
 
-       <listitem><para>L'identifiant du n&oelig;ud utilisé pour créer l'événement de configuration,
-	   qui prévient tous les n&oelig;uds existants de l'arrivée du nouveau n&oelig;ud.
+       <listitem>
+         <para>L'identifiant du n&oelig;ud utilisé pour créer l'événement de configuration,
+	   qui prévient tous les n&oelig;uds existants de l'arrivée du nouveau
+	   n&oelig;ud. Ça doit être l'identifiant d'un n&oelig;ud pré-existant dans
+	   le cluster, pas l'identifiant du nouveau n&oelig;ud.
 	   </para></listitem>
       </varlistentry>
      </variablelist>
@@ -517,7 +520,7 @@ INIT CLUSTER (
    </refsect1>
    <refsect1><title>Exemple</title>
     <programlisting>
-     STORE NODE ( ID = 2, COMMENT = 'N&oelig;ud 2');
+     STORE NODE ( ID = 2, COMMENT = 'Node 2', EVENT NODE = 1 );
     </programlisting>
    </refsect1>
    <refsect1> <title>Utilisation de verrous</title>
@@ -2058,6 +2061,27 @@ n&oelig;uds. Tout n&oelig;ud qui a pour but d'être un candidat pour le
 FAILOVER <emphasis>doit</emphasis> avoir <command>FORWARD = yes</command>.</para></listitem>
 
       </varlistentry>
+      <varlistentry><term><literal> OMIT COPY = boolean </literal></term>
+       
+       <listitem><para>Indique si le processus d'abonnement doit omettre la
+       commande <command>COPY</command> pour les données pré-existante dans
+       l'ensemble. En effet, utiliser cette option indique clairement
+       <quote>Faites-moi confiance, les données sont déjà synchronisées&nbsp;!</quote>
+       </para>
+
+       <para>Ceci est particulièrement utile dans les cas suivants&nbsp;:
+       </para>
+
+       <itemizedlist>
+	<listitem><para>Une mise à jour de version majeure (par exemple de &slony1;
+	1.2 à 2.0) pourra être beaucoup plus rapide. </para> </listitem>
+	<listitem><para>Cloner un <quote>n&oelig;ud maître</quote>. 
+	<xref linkend="stmtcloneprepare"/>/<xref linkend="stmtclonefinish"/>   </para> </listitem>
+	<listitem><para> </para> </listitem>
+       </itemizedlist>
+       </listitem>
+
+      </varlistentry>
      </variablelist>
     <para>Cette commande utilise &funsubscribeset;.</para>
    </refsect1>
@@ -2143,6 +2167,10 @@ recopiant les données à partir d'un n&oelig;ud existant, il peut <quote>paraî
 l'ancien contenu est détruit et le n&oelig;ud est re-peupler <emphasis>à partir
 de zéro</emphasis>.</para> </listitem>
 
+     <listitem><para> L'option <command>OMIT COPY</command> est un très gros
+     risque car il permet à l'administrateur d'avoir des ensembles de réplication
+     non synchronisés. </para>
+     </listitem>
    </itemizedlist>
 
    </refsect1>
@@ -2161,6 +2189,8 @@ qu'une activité le demande, ce qui laisse une possibilité d'inter-blocage
    </refsect1>
    <refsect1> <title>Note de version</title>
     <para>Cette commande fut introduite dans &slony1; 1.0.</para>
+    <para>L'option <command>OMIT COPY</command> a été introduit dans &slony1;
+    2.0.3.</para>
    </refsect1>
   </refentry>
 
@@ -3025,7 +3055,7 @@ REPAIR CONFIG (
    <refsect1>
     <title>Description</title>
     <para>
-     Cette commande prépare le clonage d'un n&oelig;ud donné.
+     Cette commande prépare le clonage d'un n&oelig;ud abonné donné.
     </para>
 
     <para>