[Trad] [svn:pgfr] r1364 - traduc/trunk/slony

Dim 19 Juil 20:34:53 CEST 2009

Author: daamien
Date: 2009-07-19 20:34:53 +0200 (Sun, 19 Jul 2009)
New Revision: 1364

Modified:
   traduc/trunk/slony/faq.xml
Log:
relecture faq (52%)


Modified: traduc/trunk/slony/faq.xml
===================================================================

--- traduc/trunk/slony/faq.xml	2009-07-19 18:20:41 UTC (rev 1363)
+++ traduc/trunk/slony/faq.xml	2009-07-19 18:34:53 UTC (rev 1364)
@@ -839,16 +839,17 @@
 <answer> <para>(Les commentaires de Jan Wieck:) L'ordre des ID des tables
 a une importance uniquement lors d'une opération de <xref linkend="stmtlockset"/> en préparation de basculement.
 Si l'ordre est différent de celui selon lequel les applications obtiennent des verrous,
-ces derniers peuvent se transformer en verrous mortels et par conséquent faire tomber l'application ou bien
+ces derniers peuvent se transformer en verrous interbloqués ("deadlock") et par conséquent faire tomber l'application ou bien
 <application>slon</application>.
 </para>
-<answer><para> (David Parker) Dans un autre cas, j'ai lancé l'opération où l'ordre des
-tables avait une importance : en présence des tables avec les contraintes d'intégrité référentielles.
-Si une table détail se présente avant celle de maître, alors le serveur abonné, supprime son 
-contenu, avant qu'elle soit à nouveau rafraîchie, car la logique de la commande
-<command>copy_set</command> vaut que <command>delete</command>,
-ne soit pas un <command>delete only</command>, or la suppression des données de la table maître, impose bien la suppression de celle
-de détail.
+<answer><para> (David Parker) J'ai renconté un autre cas où l'ordre des
+tables avait une importance : avec l'héritage.
+Si une table fille se présente avant le table mère, alors l'abonnement initial provoquera la suppression du 
+contenu de la table, alors qu'elle aura probablement reçue des données.
+En effet la logique de la commande
+<command>copy_set</command> effectue un <command>delete</command>,
+et non pas un <command>delete only</command>, ce qui implique que  la suppression des données de la table maître provoquera  la suppression de celle
+de la table fille.
 </para>
 </answer></answer>
 
@@ -856,13 +857,11 @@
 
 <qandaentry>
 
-<question><para> Si votre script  <xref linkend="slonik"/> ressemble à quelque chose comme le suivant,
-il peut tomber en erreur et ne jamais se terminer, car vous n'avez pas
-<command>wait pour ev la mise à jour à nouveau. Bien sûr Of course, as mentioned
-above, it could be faster to drop the node and recreate it than to let
-ent</command> à l'intérieur d'un bloc de 
+<question><para> Si votre script  <xref linkend="slonik"/> ressemble à quelque chose à celui ci-dessous,
+il peut tomber en erreur et ne jamais se terminer, car on ne peut pas utiliser
+<command>wait for event</command> à l'intérieur d'un bloc 
 <command>try</command>. Un bloc de <command>try</command> est exécuté comme une seule et même transaction,
-et l'évènement pour lequel vous êtes en attente, peut jamais avoir lieu
+et l'évènement pour lequel vous êtes en attente, peut ne jamais avoir lieu
 dans le scope de la transaction.</para>
 
 <programlisting>
@@ -884,7 +883,7 @@
 </programlisting></question>
 
 <answer><para> Vous ne devez pas invoquer<xref linkend="stmtwaitevent"/>
-à l'intérieur d'un bloc de<quote>try</quote>.</para></answer>
+à l'intérieur d'un bloc <quote>try</quote>.</para></answer>
 
 </qandaentry>
 
@@ -902,15 +901,15 @@
 </para>
 
 <para>Le contournement est de créer un <emphasis>AUTRE</emphasis>
-jeu de table, d'y rajouter la table souhaitée, brancher les serveurs abonnés au "jeu 1" sur le nouveau qu'on vient de créer,et en suite de
-fusionner les 2 jeux ensemble.</para>
+ensemble de réplication, d'y rajouter les tables souhaitées, brancher les serveurs abonnés l'ensemble de réplication 1 sur le nouveau qu'on vient de créer,et en suite de
+fusionner les 2 ensembles.</para>
 </answer></qandaentry>
 
 <qandaentry>
 <question><para>
 ERROR: duplicate key violates unique constraint "sl_table-pkey"</para>
 
-<para>En essayant de monter un deuxième jeu de réplication, j'ai ce message :I tried setting up a second replication set, and got the following error:
+<para>En essayant de monter un deuxième ensemble de réplication, j'ai ce message :
 
 <screen>
 stdin:9: Could not create subscription set 2 for oxrslive!
@@ -918,13 +917,16 @@
 CONTEXT:  PL/pgSQL function "setaddtable_int" line 71 at SQL statement
 </screen></para></question>
 
-<answer><para> Les identifaiants des tables utilisées dans  <xref linkend="stmtsetaddtable"/>
-demande d'être unique <emphasis>A TRAVERS TOUT LE JEU</emphasis>.  Thus,
-you can't restart numbering at 1 for a second set; if you are
-numbering them consecutively, a subsequent set has to start with IDs
-after where the previous set(s) left off.</para> </answer>
+<answer><para> Les identifiants des tables utilisées dans  <xref linkend="stmtsetaddtable"/>
+doivent être uniques <emphasis>A TRAVERS TOUT LES ENSEMBLES DE REPLICATION</emphasis>.  
+En conséquence, vous en pouvez pas reprendre la numérotation à zéro à l'intérieur
+d'un deuxième ensemble de réplication; Si vous les numérotez de manière
+consécutive, le prochain ensemble de réplication doit commencer 
+avec un identifiant supérieur à ceux de l'ensemble précédent.
+</para> </answer>
 </qandaentry>
 
+<--TODO-->
 <qandaentry>
 <question><para> L'un de mes serveurs tombe en erreur sur (&lslon; / postmaster was
 down) et dont aucune notification depuis plusieurs jours.Maintenant lorsque &lslon; sur ce noeud démarre,

