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

[admin at listes.postgresql.fr]

Author: daamien
Date: 2009-07-25 17:11:31 +0200 (Sat, 25 Jul 2009)
New Revision: 1366

Modified:
   traduc/trunk/slony/faq.xml
Log:
relecture faq xml : l?\195?\169g?\195?\168res corrections



Modified: traduc/trunk/slony/faq.xml
===================================================================
--- traduc/trunk/slony/faq.xml	2009-07-24 07:25:07 UTC (rev 1365)
+++ traduc/trunk/slony/faq.xml	2009-07-25 15:11:31 UTC (rev 1366)
@@ -836,7 +836,7 @@
 </para>
 </answer>
 
-<!--TODO-->
+
 <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,
@@ -927,23 +927,22 @@
 </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,
-ll tourne durant cinq minutes, puis s'arrête,
+<question><para> L'un de mes noeudss est tombé (&lslon; ou le postmaster était arrêté) et personne ne s'en est aperçu pendant plusieurs jours.
+Maintenant lorsque &lslon; démarre sur ce noeud, il tourne durant cinq minutes, puis s'arrête,
 avec l'erreur suivante : <command>ERROR: remoteListenThread_%d: timeout
-for event selection</command> What's wrong, and what do I do? </para> 
+for event selection</command> Quel est le problème ? Que faire ? </para> 
 </question>
 
 <answer><para> Le problème est que le port d'écoute de ce processus (dans
-<filename>src/slon/remote_listener.c</filename>) arrive à une expiration de temps, lors il tente
-de déterminer quels est l'évènement à reprendre sur ce noeud.Par défaut
-le délai d'expiration de cette interrogation est de 5 minutes; si la reprise contient plus d'évènement,
+<filename>src/slon/remote_listener.c</filename>) arrive à une expiration de temps, lorsqu'il tente
+de déterminer quel est l'évènement à reprendre sur ce noeud. Par défaut
+le délai d'expiration de cette interrogation est de 5 minutes; si la reprise contient les évènements pour une durée de plusieurs jours, 
 cela prendra beaucoup plus de temp.
  </para> </answer>
 
-<answer><para> La réponse à cette question pour les versions de &slony1; antérieur à  1.1.7, 1.2.7, et à 1.3, serait de dire
+<answer><para> La réponse à cette question pour les versions de &slony1; antérieures à  1.1.7, 1.2.7, et à 1.3, serait de dire
 d'augmenter le délai d'expiration dans
 <filename>src/slon/remote_listener.c</filename>, de recompiler &lslon;, et enfin de ressayer.  </para> </answer>
 
@@ -953,7 +952,7 @@
 </para> </answer>
   
 <answer><para> Dans les version récentes de &slony1;, il y a une nouveau paramètre appelé :<xref
-linkend="slon-config-remote-listen-timeout"/>;qui permet de modifier le délai d'expiration
+linkend="slon-config-remote-listen-timeout"/>; qui permet de modifier le délai d'expiration
 et de relancer les mises à jour. Bien sûr, comme il a été mentionné ci-dessus, il est plus efficace dans ce cas
 de supprimer et de recréer le noeud, que d'essayer de rattraper les mises à jours. </para> </answer>
 
@@ -961,8 +960,8 @@
 
 </qandadiv>
 
-<START>
 
+
 <qandadiv id="faqperformance"> <title> &slony1; FAQ: Problèmes de Performances </title>
 
 <qandaentry id="longtxnsareevil">
@@ -1333,7 +1332,9 @@
 bonne pratique.</link> </para>
 </answer>
 
-<STOP>
+
+<!-- todo -->
+
 <answer>
 <para> Le problème avec un ensemble d'ordre  seulement si vous avez un cas pour lequel les seuls abonnements qui sont en activité pour un abonné particulier vis à vis d'un fournisseur particulier, sont pour les jeux <quote>sequence-only</quote>. Si un noeud entre dans cet état,
 la réplique échouera, étant donnée la requête qui collectera les données depuis <xref