[Trad] [svn:pgfr] r1377 - traduc/branches/slony_1_2
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Dim 23 Aou 17:43:44 CEST 2009
Author: gleu
Date: 2009-08-23 17:43:43 +0200 (Sun, 23 Aug 2009)
New Revision: 1377
Modified:
traduc/branches/slony_1_2/faq.xml
Log:
D?\195?\169but de la relecture de faq.xml.
Modified: traduc/branches/slony_1_2/faq.xml
===================================================================
--- traduc/branches/slony_1_2/faq.xml 2009-08-22 16:55:56 UTC (rev 1376)
+++ traduc/branches/slony_1_2/faq.xml 2009-08-23 15:43:43 UTC (rev 1377)
@@ -1,98 +1,153 @@
<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modifications
+<!-- Dernière modifications
le $Date$
par $Author$
- révision $Revision$ -->
+ révision $Revision$ -->
<qandaset>
-<indexterm><primary>Foire Aux Questions de &slony1;</primary></indexterm>
+<indexterm><primary>Foire aux questions de &slony1;</primary></indexterm>
-<qandadiv id="faqcompiling"><title> &slony1; FAQ: Compiler et Installer &slony1; </title>
+<qandadiv id="faqcompiling">
+<title>FAQ de &slony1; : compiler et installer &slony1;</title>
<qandaentry>
+ <question>
+ <para>
+ J'utilise <productname>Frotznik Freenix 4.5</productname> avec son
+ système de gestion de paquetages <acronym>FFPM</acronym> (Frotznik
+ Freenix Package Manager). Il existe des paquets <acronym>FFPM</acronym>
+ pour &postgres; 7.4.7, que j'utilise actuellement comme base de données,
+ mais il n'y a pas encore de paquetages &slony1;. Comment puis-je rajouter
+ &slony1; à cette distribution ?
+ </para>
+ </question>
+
+ <answer>
+ <para>
+ <productname>Frotznik Freenix</productname> est nouveau pour moi, alors
+ il est un peu dangereux de donner une réponse définitive, concise et
+ rapide.
+ </para>
-<question><para> J'utilise <productname> Frotznik Freenix
-4.5</productname>, avec son système de gestion de paquetages <acronym>FFPM</acronym> (Frotznik Freenix Package Manager). Il existe des paquets
-<acronym>FFPM</acronym> pour &postgres; 7.4.7, que j'utilise actuellement
-comme base de données, mais il n'y a pas encore de paquetages &slony1;.
-Comment puis-je rajouter &slony1; Ã cette distribution ? </para>
-</question>
+ <para>
+ Les réponses différent légèrement selon les diverses combinaisons de
+ versions entre &postgres; et &slony1; Il est légèrement plus facile,
+ avec les versions récentes, de faire face à ce genre de questions
+ qu'avec des versions plus anciennes. En général, vous devez presque
+ certainement recompiler &slony1; depuis les sources. Selon les versions
+ des deux composants &slony1; et &postgres;, vous
+ <emphasis>devez</emphasis> également recompiler &postgres; à partir de
+ zéro. (Savoir si vous devez <emphasis>utiliser</emphasis> la version
+ compilée de &postgres; est un autre problème mais en général ce n'est
+ pas le cas...)
+ </para>
+ <itemizedlist>
-<answer><para> <productname>Frotznik Freenix</productname> c'est nouveau pour moi,
-alors il est un peu dangereux, de donner une réponse définitive, concise et rapide. </para>
+ <listitem>
+ <para>
+ Les versions 1.0.5 et ultérieures de &slony1; nécessitent d'avoir
+ une version complètement configurée des sources de &postgres; afin de
+ recompiler &slony1;.
+ </para>
-<para> Les réponses différent légèrement selon les diverses combinaisons de versions entre
-&postgres; et &slony1; Il est légérement plus facile, avec les versions récentes, de faire face à ce genre de questions qu'avec les versions plus anciennes. En général, vous devez presque certainement recompiler &slony1; depuis les sources; selon les versions
-des deux composants &slony1; et &postgres;, vous
-<emphasis>devez</emphasis> également recompiler &postgres; à partir de zéro.
-(Savoir si vous devez <emphasis> utilisez </emphasis> la version compilée de &postgres;
-est un autre problème; en général ce n'est pas le cas...) </para>
+ <para>
+ <emphasis>Heureusement</emphasis>, vous pouvez adapter la configuration
+ pour qu'elle corresponde à la configuration utilisée nativement par le
+ paquet d'origine, en vérifiant la version de &postgres; avec la
+ commande <command>pg_config --configure</command>.
+ </para>
+ </listitem>
-<itemizedlist>
+ <listitem>
+ <para>
+ La version 1.1 de &slony1; simplifie considérablement les choses ;
+ dans la mesure où vous êtes dispensé d'avoir la version complète des
+ sources de &postgres;, au lieu de cela, elle se réfère aux emplacements
+ des bibliothèques, des binaires, de la configuration et des
+ <command>fichiers #include</command>.
+ </para>
+ </listitem>
-<listitem><para> &slony1; la version 1.0.5 et ultérieur nécessite d'avoir une version complètement configurées des sources de &postgres;, afin de recompiler
-&slony1;.</para>
+ <listitem>
+ <para>
+ &postgres; 8.0 et supérieur est généralement plus facile car
+ l'<quote>installation par défaut</quote> contient la totalité des
+ fichiers d'inclusion <command>#include</command>.
+ </para>
-<para> <emphasis>Heureusement </emphasis> vous pouvez adapter la configuration pour qu'elle corresponde à la configuration utilisée nativement par la paquet d'origine, en vérifiant la
-version de &postgres; avec la commande
-<command> pg_config --configure</command>. </para> </listitem>
+ <para>
+ Si vous utilisez une version antérieure de &postgres;, il est
+ préférable d'utiliser une version installée à partir des sources, en
+ particulier si la version packagée ne contient pas les <quote>fichiers
+ d'inclusions <command>#include</command></quote> du serveur. Ces
+ fichiers peuvent être installés par la commande <command>make
+ install-all-headers</command>.
+ </para>
+ </listitem>
-<listitem> <para> &slony1; La version 1.1 simplifie considérablement les choses;
-dans la mesure où vous êtes dispensé d'avoir la version complète de de sources de &postgres;, au lieu de cela, elle se réfère aux emplacements des librairies,
-des binaires, de la configuration, et <command> des fichiers #include </command>.
-</para> </listitem>
+ </itemizedlist>
-<listitem><para> &postgres; 8.0 et supérieur est généralement plus facile car l'<quote>installation par défaut</quote> contient la totalité des fichiers d'inclusion <command> #include </command>. </para>
+ <para>
+ En pratique, la <quote>pire situation</quote> est un scénario où vous
+ utilisez une version de &slony1; antérieure à 1.1 avec une
+ <quote>vieille</quote> version de &postgres;. Dans ce cas, vous devez
+ compiler &postgres; à partir de zéro afin d'avoir tous les pré-requis
+ de compilation de &slony1; même si vous utilisez une version
+ <quote>packagée</quote> de &postgres;.
+ </para>
-<para> Si vous utilisez une version antérieure de &postgres;, il est préférable d'utiliser une version installée à partir des sources,
-en particulier si la version packagée ne contient <quote> les fichiers d'inclusions<command>#include</command></quote> du serveur. Ces fichiers peuvent être installés par la commande <command> make install-all-headers </command>.</para>
-</listitem>
+ <para>
+ Si vous utilisez une version récente de &postgres; et une version récente
+ de &slony1;, alors les dépendences peuvent être assez faibles, et vous
+ n'avez pas besoin de fichiers sources complémentaires.Ces améliorations
+ devraient soulager la mise en production des paquets de &slony1; de sorte
+ que vous pourriez même pouvoir espérer éviter la compilation de &slony1;.
+ </para>
+ </answer>
-</itemizedlist>
-
-<para> En pratique, la <quote>pire situation</quote> est un scénario où
-vous utilisez une version de &slony1; antérieure à 1.1 avec une
-<quote>vieille</quote> version de &postgres;, dans ce cas vous devez compiler &postgres;
-à partir de zéro afin d'avoir tout les pré-requis de compilation de &slony1; même si
-vous utilisez une version<quote>packagée</quote> de &postgres;.</para>
-
-<para> Si vous utilisez une version récente de &postgres; et une version récente de &slony1;,
-alors les dependences peuvent être assez faibles, et vous n'avez pas besoin de fichiers sources complémentaires. Ces améliorations devraient soulager la mise en production des
-paquets de &slony1; de sorte que vous pourriez même pouvoir espérer éviter la compilation
-de &slony1;.</para>
-
-</answer>
-
-<answer><para> </para> </answer>
-
+ <answer>
+ <para></para>
+ </answer>
</qandaentry>
<qandaentry id="missingheaders">
-<question><para> J'essaie d'installer &slony1; 1.1 et j'obtiens le message d'erreur suivant:
-<screen>
-configure: error: Headers for libpqserver are not found in the includeserverdir.
+ <question>
+ <para>
+ J'essaie d'installer &slony1; 1.1 et j'obtiens le message d'erreur suivant :
+ <screen>configure: error: Headers for libpqserver are not found in the includeserverdir.
This is the path to postgres.h. Please specify the includeserverdir with
- --with-pgincludeserverdir=<dir>
-</screen>
-</para></question>
+ --with-pgincludeserverdir=<dir></screen>
+ </para>
+ </question>
-<answer><para> Vous exécutez certainement une version &postgres; 7.4
-ou antérieure, où les en-têtes de serveur ne sont pas installés par défaut, il vous suffit dans ce cas de lancer la commande <command>make install</command> de &postgres;.</para>
+ <answer>
+ <para>
+ Vous exécutez certainement une version 7.4 de &postgres; ou une version
+ antérieure. Une version où les en-têtes de serveur ne sont pas installés
+ par défaut. Dans ce cas, il vous suffit de lancer la commande
+ <command>make install</command> de &postgres;.
+ </para>
-<para> Vous devez installer les en-têtes du serveur lors d'installation de &postgres; via la commande <command>make install-all-headers</command>.
+ <para>
+ Vous devez installer les en-têtes du serveur lors d'installation de
+ &postgres; via la commande <command>make install-all-headers</command>.
+ </para>
+ </answer>
+</qandaentry>
-</para> </answer> </qandaentry>
-
<qandaentry id="threadsafety">
+ <question>
+ <para>
+ &slony1; semble se compiler correctement ; maintenant, lorsque
+ j'exécute un &lslon;, certains évènements se déclenchent, mais la
+ réplication ne se met pas route.
+ </para>
-<question><para> &slony1; semble se compiler correctement; maintenant, lorsque j'exécute un &lslon;, certain évènements se déclenchent, mais la réplication ne se met pas
-route.</para>
+ <para>
+ Les journaux applicatifs de Slony ressemblent à ça :
-<para> Les logs de Slony ressemble à ça :
-
-<screen>
-DEBUG1 remoteListenThread_1: connected to 'host=host004 dbname=pgbenchrep user=postgres port=5432'
+ <screen>DEBUG1 remoteListenThread_1: connected to 'host=host004 dbname=pgbenchrep user=postgres port=5432'
ERROR remoteListenThread_1: "select ev_origin, ev_seqno, ev_timestamp,
ev_minxid, ev_maxxid, ev_xip,
ev_type,
@@ -100,346 +155,913 @@
ev_data3, ev_data4,
ev_data5, ev_data6,
ev_data7, ev_data8 from "_pgbenchtest".sl_event e
-where (e.ev_origin = '1' and e.ev_seqno > '1') order by e.ev_origin, e.ev_seqno" - could not receive data from server: Operation now in progress
-</screen>
-</para>
+where (e.ev_origin = '1' and e.ev_seqno > '1') order by e.ev_origin, e.ev_seqno" - could not receive data from server: Operation now in progress</screen>
+ </para>
-<para> Parfois ils contiennent les lignes suivantes ...
+ <para>
+ Parfois, ils contiennent les lignes suivantes...
-<screen>
-ERROR remoteListenThread_2: "select ev_origin, ev_seqno, ev_timestamp,
+ <screen>ERROR remoteListenThread_2: "select ev_origin, ev_seqno, ev_timestamp,
ev_minxid, ev_maxxid, ev_xip, ev_type, ev_data1, ev_data2,
ev_data3, ev_data4, ev_data5, ev_data6, ev_data7, ev_data8
from "_sl_p2t2".sl_event e where (e.ev_origin = '2' and e.ev_seqno >
'0') order by e.ev_origin, e.ev_seqno" - could not receive data from
-server: Error 0
-</screen>
-</para>
-</question>
+server: Error 0</screen>
+ </para>
+ </question>
-<answer><para>Sur AIX et Solaris (et probablement sur d'autre OS),
-&slony1; <emphasis>et &postgres;</emphasis> doivent être compilés avec l'option <option>--enable-thread-safety</option> . Le message ci-dessus arrive lorsque la compilation
-de &postgres; n'a pas fait appel à cette option.</para>
+ <answer>
+ <para>
+ Sur AIX et Solaris (et probablement sur d'autres OS), &slony1;
+ <emphasis>et &postgres;</emphasis> doivent être compilés avec l'option
+ <option>--enable-thread-safety</option>. Le message ci-dessus arrive
+ lorsque la compilation de &postgres; n'a pas fait appel à cette option.
+ </para>
-<para>Le disfonctionnement ici vient du fait que le libc (indépendant des threads) et libpq
-(basés sur les threads) utilisent des emplacements de mémoire différente pour les codes d'erreur, c'est qui fait échouer les requêtes.</para>
+ <para>
+ Le disfonctionnement ici vient du fait que la bibliothèque C (indépendante
+ des threads) et la bibliothèque de &postgres;, libpq, (basée sur les
+ threads) utilisent des emplacements de mémoire différents pour les codes
+ d'erreur. Cela fait échouer les requêtes.
+ </para>
-<para>Des problèmes de ce genre surviennent avec des régularités surprenantes sur AIX et sur Solaris. Il sera probablement nécessaire
-de réaliser un <quote>audit du code objet</quote> pour s'assurer que <emphasis>tous</emphasis> les composants nécessaire ont été compilés et linkés avec l'option <option>--enable-thread-safety</option>.</para>
+ <para>
+ Des problèmes de ce genre surviennent avec des régularités surprenantes
+ sur AIX et sur Solaris. Il sera probablement nécessaire de réaliser un
+ <quote>audit du code objet</quote> pour s'assurer que
+ <emphasis>tous</emphasis> les composants nécessaires ont été compilés
+ et liés avec l'option <option>--enable-thread-safety</option>.
+ </para>
-<para>Par exemple, on peut rencontrer un problème sur Solaris lorsque
-<envar>LD_LIBRARY_PATH</envar> est défini et pointe sur les
-librairies depuis d'une ancienne version compilée de &postgres;. Cela signifie que même si
-la base de donnée <emphasis>avait été</emphasis> compilée avec l'option
-<option>--enable-thread-safety</option>, et même si
-<application>slon</application> a été recompilé pour cette version, lors de l'édition de lien dynamique de
-<application>slon</application> pointait sur un
-<quote>ancienne mauvaise version compilée sans l'option thread-safe,</quote>, et donc slon ne fonctionne pas. On ne peut s'apercevoir de cela qu'en exécutant <command>ldd</command>
-sur <application>slon</application>.</para> </answer>
+ <para>
+ Par exemple, on peut rencontrer un problème sur Solaris lorsque
+ <envar>LD_LIBRARY_PATH</envar> est défini et pointe sur les bibliothèques
+ depuis une ancienne version compilée de &postgres;. Cela signifie que
+ même si la base de donnée <emphasis>avait été</emphasis> compilée avec
+ l'option <option>--enable-thread-safety</option>, et même si
+ <application>slon</application> a été recompilé pour cette version,
+ lors de l'édition de liens dynamique, <application>slon</application>
+ pointait sur une <quote>ancienne et mauvaise version compilée sans l'option
+ thread-safe,</quote>, slon ne fonctionne pas. On ne peut s'apercevoir de
+ cela qu'en exécutant <command>ldd</command> sur
+ <application>slon</application>.
+ </para>
+ </answer>
-<answer><para> A noter que la version 7.4.2 de libpq sur Solaris nécessite <link linkend="threadpatch"> un patch supplémentaire pour les threads </link> ; Ce pré-requis est également demandé pour &postgres; version 8.0.
-</para>
-</answer>
+ <answer>
+ <para>
+ À noter que la version 7.4.2 de libpq sur Solaris nécessite <link
+ linkend="threadpatch">un patch supplémentaire pour les threads</link>.
+ Ce pré-requis est également demandé pour &postgres; version 8.0.
+ </para>
+ </answer>
</qandaentry>
<qandaentry id="pg81funs">
-<question> <para> Je suis en train de migrer sur une nouvelle version de &slony1;
-et je me débat avec un problème avec <xref
-linkend="stmtupdatefunctions"/>. Lors d'exécution de <xref
-linkend="stmtupdatefunctions"/>, mon
-<application>postmaster</application> plante avec le signal 11.
-Le fichier log ne contient aucune erreur, exceptées celles relatives Ã
-&postgres; les logs indiquent simplement que le postmaster est bel bien tombé.</para>
+ <question>
+ <para>
+ Je suis en train de migrer sur une nouvelle version de &slony1; et je me
+ débat avec un problème sur <xref linkend="stmtupdatefunctions"/>. Lors
+ de l'exécution de <xref linkend="stmtupdatefunctions"/>, mon
+ <application>postmaster</application> s'arrête brutalement avec le signal
+ 11. Le journal applicatif ne contient aucune erreur, exceptées celles
+ relatives à &postgres;. Les journaux applicatifs indiquent simplement que
+ le postmaster est bel bien arrêté.
+ </para>
-<para> En scrutant le fichier core avec un déboggueur, on constate que
-l'incident survient lors de la validation d'une transaction. </para>
+ <para>
+ En scrutant le fichier core avec un déboggueur, on constate que l'incident
+ survient lors de la validation d'une transaction.
+ </para>
-<para> Pour infos je suis sur &postgres; 8.1.[0-3]. </para>
-</question>
+ <para>
+ Pour infos je suis sur &postgres; 8.1.[0-3].
+ </para>
+ </question>
-<answer> <para> Malheureusement les anciennes versions de &postgres; 8.1 avait un problème lors de la re-définition d'une fonction ( par exemple <function>upgradeSchema(text)</function>), lorsque la fonction est appellée juste après, au sein de la même transaction,
-, le
-<application>postmaster</application> plante et la
-transaction est annulée. </para>
+ <answer>
+ <para>
+ Malheureusement, les anciennes versions de &postgres; 8.1 avaient un
+ problème lors de la re-définition d'une fonction (par exemple
+ <function>upgradeSchema(text)</function>), lorsque la fonction est
+ appellée juste après, au sein de la même transaction, le
+ <application>postmaster</application> plante et la transaction est
+ annulée.
+ </para>
-<para> La commande &lslonik; <xref linkend="stmtupdatefunctions"/>
-fonctionne de cette manière; dans une même transaction elle effectue ceci :
+ <para>
+ La commande &lslonik; <xref linkend="stmtupdatefunctions"/> fonctionne de
+ cette manière ; dans une même transaction, elle effectue ceci :
-<itemizedlist>
-<listitem><para> Charger les nouvelles fonctions (depuis <filename>slony1_funcs.sql</filename>), notamment comprenant <function>upgradeSchema(text)</function>.
-</para> </listitem>
-<listitem><para> Lancer <function>upgradeSchema(text)</function> pour effectuer la migration nécessaire des schémas de la base. </para> </listitem>
-<listitem><para> Avertir les processus &lslon; du changement de configuration.</para> </listitem>
-</itemizedlist>
-</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Charger les nouvelles fonctions (depuis
+ <filename>slony1_funcs.sql</filename>), notamment comprenant
+ <function>upgradeSchema(text)</function>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Lancer <function>upgradeSchema(text)</function> pour effectuer la
+ migration nécessaire des schémas de la base.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Avertir les processus &lslon; du changement de configuration.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
-<para> Malheureusement, en &postgres; 8.1.0, 8.1.1, 8.1.2, et 8.1.3,
-ceci est conflictuel avec un bug où l'utilisation et la modification d'une fonction plpgsql au sein de la même transaction
-provoque un plantage. </para>
+ <para>
+ Malheureusement, avec &postgres; 8.1.0, 8.1.1, 8.1.2, et 8.1.3, ceci est
+ conflictuel avec un bogue où l'utilisation et la modification d'une
+ fonction plpgsql au sein de la même transaction provoque un arrêt brutal.
+ </para>
-<para> Plusieurs contournements sont envisageables. </para>
+ <para>
+ Plusieurs contournements sont envisageables.
+ </para>
+ </answer>
-</answer>
+ <answer>
+ <para>
+ La meilleure solution consiste à migrer &postgres; vers une version 8.1.4
+ ou supérieure. Les changements entre deux versions mineures ne nécessitent
+ pas la reconstruction de la base, il suffit simplement d'installer la
+ nouvelle version, puis de redémarrer le <application>postmaster</application>
+ avec cette nouvelle version.
+ </para>
+ </answer>
-<answer> <para> La meilleur solution consiste à migrer &postgres; vers une version 8.1.4 ou supérieure. Les changements entre deux versions mineures ne nécessite pas la reconstruction de la base, il suffit simplement d'installer la nouvelle version puis de redémarrer le <application>postmaster</application> avec cette nouvelle version. </para>
-</answer>
+ <answer>
+ <para>
+ Si cette solution ne convient pas, il est possible d'effectuer la mise à
+ jour via une série de transactions <quote>à la main</quote>, qui
+ correspondent à ce que &lslonik; aurait fait pour cette migration.
+ </para>
-<answer><para> Si cette solution ne convient pas, il est possible d'effectuer la mise à jour via une série de transaction <quote>à la main</quote>, qui correspondent à ce que &lslonik; aurait fait pour cette migration. </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Prendre <filename>slony1_funcs.sql</filename> et faire trois
+ remplacements dans ce fichier :
+ </para>
-<itemizedlist>
-<listitem><para> Prendre <filename>slony1_funcs.sql</filename> et faire trois remplacements dans ce fichier: </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Remplacer <quote>@CLUSTERNAME@</quote> avec le nom du cluster.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Remplacer <quote>@MODULEVERSION@</quote> avec la version de
+ &slony1; ; par exemple <quote>1.2.10</quote>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Remplacer <quote>@NAMESPACE@</quote> avec le nom du namespace
+ du cluster <quote>entre guillemets doubles</quote>, par exemple
+ "_monCluster"
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ <listitem>
+ <para>
+ Recharger dans la base cet ensemble de fonctions <quote>mises à
+ jour</quote>.
+ </para>
+ </listitem>
-<itemizedlist>
-<listitem><para> Remplacer <quote>@CLUSTERNAME@</quote>avec le nom du cluster</para> </listitem>
-<listitem><para> Remplacer <quote>@MODULEVERSION@</quote> avec la version de &slony1; par exemple <quote>1.2.10</quote> </para> </listitem>
-<listitem><para> Remplacer <quote>@NAMESPACE@</quote> avec le nom du namespace du cluster <quote>entre doubles quotes</quote> , par exemple "_monCluster" </para> </listitem>
-</itemizedlist>
-</listitem>
-<listitem><para> Recharger dans la base cet ensemble de fonctions <quote>mise à jour</quote>.</para> </listitem>
-<listitem><para> Exécuter la fonction stockée via <command>select <function>upgradeSchema('1.2.7')</function>; </command>,
-en supposant que la précédente version de &slony1; en cours était la 1.2.7. </para> </listitem>
-<listitem><para> Le redémarrage de tous les processus &lslon; est probablement une sage décision après ce genre de <quote>chirurgie.</quote> </para> </listitem>
-</itemizedlist>
-</answer>
+ <listitem>
+ <para>
+ Exécuter la procédure stockée via <command>select
+ <function>upgradeSchema('1.2.7')</function>;</command>, en supposant
+ que la précédente version de &slony1; en cours était la 1.2.7.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Le redémarrage de tous les processus &lslon; est probablement une
+ sage décision après ce genre de <quote>chirurgie.</quote>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </answer>
</qandaentry>
<qandaentry>
-<question> <para> Problème d'installation sur Fedora/x86-64 </para>
+ <question>
+ <para>Problème d'installation sur Fedora/x86-64</para>
-<para> Lorsqu'on essaie de configurer &slony1; sur système Fedora x86-64,
-où <application>yum</application> a été utilisé pour une installation du paquetage
-<filename>postgresql-libs.x86_64</filename>, le message suivant se manifeste :
+ <para>
+ Lorsqu'on essaie de configurer &slony1; sur un système Fedora x86-64,
+ où <application>yum</application> a été utilisé pour une installation
+ du paquetage <filename>postgresql-libs.x86_64</filename>, le message
+ suivant se manifeste :
-<screen>
-configure: error: Your version of libpq doesn't have PQunescapeBytea
+ <screen>configure: error: Your version of libpq doesn't have PQunescapeBytea
this means that your version of PostgreSQL is lower than 7.3
- and thus not supported by Slony-I.
-</screen></para>
+ and thus not supported by Slony-I.</screen></para>
-<para> Ceci arrive avec &postgres; 8.2.5, ce qui est nettement plus récent que la version 7.3. </para>
-</question>
+ <para>
+ Ceci arrive avec &postgres; 8.2.5, qui est nettement plus récent que la
+ version 7.3.
+ </para>
+ </question>
-<answer> <para> La fonction <application>configure</application> est à la recherche du symbole PQunescapeBytea, elle compile un petit programme qu'il l'appele et vérifie la compilation se passe bien. Dans la ligne de commande <command>gcc</command>, elle utilise <command>-lpq</command> pour chercher la librairie. </para>
+ <answer>
+ <para>
+ La fonction <application>configure</application> est à la recherche du
+ symbole PQunescapeBytea. Elle compile un petit programme qu'il exécute
+ et vérifie que la compilation se passe bien. Dans la ligne de commande
+ <command>gcc</command>, elle utilise <command>-lpq</command> pour
+ ajouter la bibliothèque.
+ </para>
+ <para>
+ Malheureusement, ce paquetage n'a pas de lien symbolique, reliant
+ <filename>/usr/lib64/libpq.so</filename> à
+ <filename>libpq.so.5.0</filename> ; c'est pourquoi la fonction
+ configure n'arrive pas à trouver libpq. Le <emphasis>vrai</emphasis>
+ problème, c'est que le compilateur n'arrive pas à trouver une
+ bibliothèque pour l'édition des liens, et non pas que libpq ait manqué
+ à l'appel.
+ </para>
-<para> Malheureusement, ce paquetage n'a pas de lien symbolique, reliant <filename>/usr/lib64/libpq.so</filename> Ã
-<filename>libpq.so.5.0</filename>; c'est pourquoi la fonction configure n'arrive pas à trouber libpq.
-Le <emphasis>vrai</emphasis> problème c'est que le compilateur n'arrive pas à trouver une librairie pour l'édition de lien, et non pas que libpq ait manqué à l'appel.
-</para>
+ <para>
+ Au final, ces informations doivent être envoyée vers ceux qui gèrent
+ le paquet <filename>postgresql-libs.x86_64</filename>.
+ </para>
+ </answer>
-<para> Au final, ces informations doivent être envoyée vers ceux qui gèrent le paquet <filename>postgresql-libs.x86_64</filename>. </para>
-</answer>
+ <answer>
+ <para>
+ Notez que ce même symptôme peut être révélateur d'autres problèmes de
+ ce genre au niveau de la configuration système. Les mauvais liens
+ symboliques, les mauvais droits, le mauvais comportement de la part de
+ votre compilateur C, tous peuvent potentiellement mener à ce même
+ message d'erreur.
+ </para>
-<answer> <para> Notez que ce même symptôme peut être révélateur d'autres problèmes de ce genre au niveau de la configuration système. Les mauvais liens symboliques, les mauvaises permissions, le mauvais comportement de la part de votre compilateur C, tout peuvent potentiellement mener à ce même message d'erreur. </para>
+ <para>
+ Ainsi, si vous rencontrez cette erreur, vous aurez besoin de regarder
+ le fichier de traces nommé <filename>config.log</filename>. Cherchez à
+ partir du bas, et regardez quel souci est <emphasis>réellement</emphasis>
+ rencontré. Ceci sera utile pour trouver la vraie racine de cet épineux
+ problème.
+ </para>
+ </answer>
+ </qandaentry>
+</qandadiv>
-<para> Ainsi si vous rencontrez cette erreur, vous aurez besoin de regarder le fichier log
-<filename>config.log</filename>. Cherchez à partir du bas, et regardez quel est le souci <emphasis>réellement</emphasis> rencontré.
-Ceci sera utile pour trouver la vrai racine de cet épineux problème.</para>
-</answer>
+<qandadiv id="faqhowto"> <title> &slony1; FAQ: How Do I? </title>
-</qandaentry>
+ <qandaentry>
+ <question>
+ <para>
+ I need to dump a database <emphasis>without</emphasis> getting
+ &slony1; configuration (<emphasis>e.g.</emphasis> - triggers, functions,
+ and such).
+ </para>
+ </question>
+ <answer>
+ <para>
+ Up to version 1.2, this is fairly nontrivial, requiring careful choice
+ of nodes, and some moderately heavy <quote>procedure</quote>. One
+ methodology is as follows:
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ First, dump the schema from the node that has the
+ <quote>master</quote> role. That is the only place, pre-2.0, where
+ you can readily dump the schema using
+ <application>pg_dump</application> and have a consistent schema.
+ You may use the &slony1; tool <xref linkend="extractschema"/> to do
+ this.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Take the resulting schema, which will <emphasis>not</emphasis>
+ include the &slony1;-specific bits, and split it into two pieces:
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Firstly, the portion comprising all of the creations of tables
+ in the schema.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Secondly, the portion consisting of creations of indices, constraints, and triggers.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ <listitem>
+ <para>
+ Pull a data dump, using <command>pg_dump --data-only</command>, of
+ some node of your choice. It doesn't need to be for the
+ <quote>master</quote> node. This dump will include the contents of
+ the &slony1;-specific tables; you can discard that, or ignore it.
+ Since the schema dump didn't contain table definitions for the
+ &slony1; tables, they won't be loaded.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Finally, load the three components in proper order:
+ </para>
+
+ <itemizedlist>
+ <listitem><para>Schema (tables)</para></listitem>
+ <listitem><para>Data dump</para></listitem>
+ <listitem><para>Remainder of the schema</para></listitem>
+ </itemizedlist>
+ </listitem>
+ </itemizedlist>
+ </answer>
+
+ <answer>
+ <para>
+ In &slony1; 2.0, the answer becomes simpler: Just take a
+ <command>pg_dump --exclude-schema=_Cluster</command> against
+ <emphasis>any</emphasis> node. In 2.0, the schemas are no longer
+ <quote>clobbered</quote> on subscribers, so a straight
+ <application>pg_dump</application> will do what you want.
+ </para>
+ </answer>
+ </qandaentry>
+
+ <qandaentry id="cannotrenumbernodes">
+ <question>
+ <para>
+ I'd like to renumber the node numbers in my cluster. How can I renumber
+ nodes?
+ </para>
+ </question>
+
+ <answer>
+ <para>
+ The first answer is <quote>you can't do that</quote> - &slony1; node
+ numbers are quite <quote>immutable.</quote> Node numbers are deeply
+ woven into the fibres of the schema, by virtue of being written into
+ virtually every table in the system, but much more importantly by
+ virtue of being used as the basis for event propagation. The only time
+ that it might be <quote>OK</quote> to modify a node number is at some
+ time where we know that it is not in use, and we would need to do
+ updates against each node in the cluster in an organized fashion.
+ </para>
+
+ <para>
+ To do this in an automated fashion seems like a
+ <emphasis>huge</emphasis> challenge, as it changes the structure of the
+ very event propagation system that already needs to be working in order
+ for such a change to propagate.
+ </para>
+ </answer>
+
+ <answer>
+ <para>
+ If it is <emphasis>enormously necessary</emphasis> to renumber nodes,
+ this might be accomplished by dropping and re-adding nodes to get rid
+ of the node formerly using the node ID that needs to be held by another
+ node.
+ </para>
+ </answer>
+ </qandaentry>
</qandadiv>
-<qandadiv id="faqconnections"> <title> &slony1; FAQ: Problèmes relatifs aux connections</title>
-<qandaentry>
+<qandadiv id="faqimpossibilities">
+ <title>&slony1; FAQ: Impossible Things People Try</title>
-<question><para>Je cherche le namespace<envar>_clustername</envar>, et
-il est introuvable.</para></question>
+ <qandaentry>
+ <question>
+ <para>
+ Can I use &slony1; to replicate changes back and forth on my database
+ between my two offices?
+ </para>
+ </question>
-<answer><para> Si le DNS sont erronés, alors l'instance &lslon;
-ne pourra pas se connecter aux noeuds.</para>
+ <answer>
+ <para>
+ At one level, it is <emphasis>theoretically possible</emphasis> to do
+ something like that, if you design your application so that each office
+ has its own distinct set of tables, and you then have some system for
+ consolidating the data to give them some common view. However, this
+ requires a great deal of design work to create an application that
+ performs this consolidation.
+ </para>
+ </answer>
-<para>Ceci mène au fait que les noeuds seront introuvables.</para>
+ <answer>
+ <para>
+ In practice, the term for that is <quote>multimaster replication,</quote>
+ and &slony1; does not support <quote>multimaster replication.</quote>.
+ </para>
+ </answer>
+ </qandaentry>
-<para>Revérifier la configuration des connexions. D'ailleurs, puisque <xref linkend="slon"/> est lié à libpq, vous pouvez stocker le mot de passe dans <filename> $HOME/.pgpass</filename>, le problème vient peut-être d'une erreur dans ce fichier.</para>
-</answer>
-</qandaentry>
+ <qandaentry>
+ <question>
+ <para>
+ I want to replicate all of the databases for a shared-database system
+ I am managing. There are multiple databases, being used by my
+ customers.
+ </para>
+ </question>
-<qandaentry id="morethansuper">
-<question> <para> J'ai créé un compte <quote>super-utilisateur</quote>,
-<command>slony</command>, pour exécuter les activités de réplications. Comme suggéré,
-je l'ai configuré comme super-user, avec la requête suivante :
-<command>
-update pg_shadow set usesuper = 't' where usename in ('slony',
-'molly', 'dumpy');
-</command>
-(Cette même commande permet d'autoriser autres utilisateurs d'exécuter vacuums et
-sauvegarde).</para>
+ <answer>
+ <para>
+ For this purpose, something like &postgres; PITR (Point In Time
+ Recovery) is likely to be much more suitable. &slony1; requires a slon
+ process (and multiple connections) for each identifiable database, and
+ if you have a &postgres; cluster hosting 50 or 100 databases, this will
+ require hundreds of database connections. Typically, in <quote>shared
+ hosting</quote> situations, DML is being managed by customers, who can
+ change anything they like whenever <emphasis>they</emphasis> want.
+ &slony1; does not work out well when not used in a disciplined manner.
+ </para>
+ </answer>
+ </qandaentry>
-<para> Malheureusement, je suis tombé en erreur, à chaque fois où je voulais souscrire à un nouveau ensemble.</para>
+ <qandaentry>
+ <question>
+ <para>
+ I want to be able to make DDL changes, and have them replicated
+ automatically.
+ </para>
+ </question>
-<programlisting>
-DEBUG1 copy_set 28661
+ <answer>
+ <para>
+ &slony1; requires that <xref linkend="ddlchanges"/> be planned for
+ explicitly and carefully. &slony1; captures changes using triggers,
+ and &postgres; does not provide a way to use triggers to capture DDL
+ changes.
+ </para>
+
+ <note>
+ <para>
+ There has been quite a bit of discussion, off and on, about how
+ &postgres; might capture DDL changes in a way that would make triggers
+ useful; nothing concrete has emerged after several years of
+ discussion.
+ </para>
+ </note>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>
+ I want to split my cluster into disjoint partitions that are not aware
+ of one another. &slony1; keeps generating <xref
+ linkend="listenpaths"/> that link those partitions together.
+ </para>
+ </question>
+
+ <answer>
+ <para>
+ The notion that all nodes are aware of one another is deeply imbedded
+ in the design of &slony1;. For instance, its handling of cleanup of
+ obsolete data depends on being aware of whether any of the nodes are
+ behind, and thus might still depend on older data.
+ </para>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>
+ I want to change some of my node numbers. How do I
+ <quote>rename</quote> a node to have a different node number?
+ </para>
+ </question>
+
+ <answer>
+ <para>
+ You don't. The node number is used to coordinate inter-node
+ communications, and changing the node ID number <quote>on the fly</quote>
+ would make it essentially impossible to keep node configuration
+ coordinated.
+ </para>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>
+ My application uses OID attributes; is it possible to replicate tables
+ like this?
+ </para>
+ </question>
+
+ <answer>
+ <para>
+ It is worth noting that oids, as a regular table attribute, have been
+ deprecated since &postgres; version 8.1, back in 2005. &slony1; has
+ <emphasis>never</emphasis> collected oids to replicate them, and, with
+ that functionality being deprecated, the developers do not intend to
+ add this functionality.
+ </para>
+
+ <para>
+ &postgres; implemented oids as a way to link its internal system tables
+ together; to use them with application tables is considered
+ <emphasis>poor practice</emphasis>, and it is recommended that you use
+ sequences to populate your own ID column on application tables.
+ </para>
+ </answer>
+
+ <answer>
+ <para>
+ Of course, nothing prevents you from creating a table
+ <emphasis>without</emphasis> oids, and then add in your own application
+ column called <envar>oid</envar>, preferably with type information
+ <command>SERIAL NOT NULL UNIQUE</command>, which
+ <emphasis>can</emphasis> be replicated, and which is likely to be
+ suitable as a candidate primary key for the table.
+ </para>
+ </answer>
+ </qandaentry>
+</qandadiv>
+
+<qandadiv id="faqconnections">
+ <title> &slony1; FAQ: Problèmes relatifs aux connections</title>
+
+ <qandaentry>
+ <question>
+ <para>
+ Je cherche le namespace <envar>_clustername</envar>, mais il est
+ introuvable.
+ </para>
+ </question>
+
+ <answer>
+ <para>
+ Si les DNS sont erronés, alors l'instance &lslon; ne pourra pas se
+ connecter aux nœuds.
+ </para>
+
+ <para>
+ Ceci mène au fait que les nœuds seront introuvables.
+ </para>
+
+ <para>
+ Vérifier de nouveau la configuration des connexions. D'ailleurs,
+ puisque <xref linkend="slon"/> est lié à libpq, vous pouvez stocker le
+ mot de passe dans <filename>$HOME/.pgpass</filename>, le problème vient
+ peut-être d'une erreur dans ce fichier.
+ </para>
+ </answer>
+ </qandaentry>
+
+ <qandaentry id="morethansuper">
+ <question>
+ <para>
+ J'ai créé un compte <quote>super-utilisateur</quote>,
+ <command>slony</command>, pour exécuter les activités de réplication.
+ Comme suggéré, je l'ai configuré comme super-utilisateur, avec la
+ requête suivante :
+
+ <command>UPDATE pg_shadow SET usesuper = 't'
+WHERE usename IN ('slony', 'molly', 'dumpy');</command>
+
+ (Cette même commande permet d'autoriser autres utilisateurs à exécuter
+ VACUUM et sauvegardes).
+ </para>
+
+ <para>
+ Malheureusement, j'ai eu une erreur à chaque fois où je voulais
+ souscrire à un nouveau ensemble.
+ </para>
+
+ <programlisting>DEBUG1 copy_set 28661
DEBUG1 remoteWorkerThread_1: connected to provider DB
DEBUG2 remoteWorkerThread_78: forward confirm 1,594436 received by 78
DEBUG2 remoteWorkerThread_1: copy table public.billing_discount
ERROR remoteWorkerThread_1: "select "_mycluster".setAddTable_int(28661, 51, 'public.billing_discount', 'billing_discount_pkey', 'Table public.billing_discount with candidate primary key billing_discount_pkey'); " PGRES_FATAL_ERROR ERROR: permission denied for relation pg_class
CONTEXT: PL/pgSQL function "altertableforreplication" line 23 at select into variables
PL/pgSQL function "setaddtable_int" line 76 at perform
-WARN remoteWorkerThread_1: data copy for set 28661 failed - sleep 60 seconds
-</programlisting>
+WARN remoteWorkerThread_1: data copy for set 28661 failed - sleep 60 seconds</programlisting>
-<para> Cela continue de planter, encore et toujours, jusqu'à ce que je redémarre <application>slon</application> pour qu'il se connecte avec le compte <command>postgres</command>.</para>
-</question>
+ <para>
+ Cela continue de s'arrêter avec une erreur, encore et toujours, jusqu'à
+ ce que je redémarre <application>slon</application> pour qu'il se
+ connecte avec le compte <command>postgres</command>.
+ </para>
+ </question>
-<answer><para> Le problème est assez évident en soi; la permission sur la table de système <envar>pg_class</envar> est ignorée.</para></answer>
+ <answer>
+ <para>
+ Le problème est assez évident en soi ; le droit sur la table
+ système <envar>pg_class</envar> est ignoré.
+ </para>
+ </answer>
-<answer><para> La <quote>solution</quote> est la suivante:</para>
-<programlisting>
-update pg_shadow set usesuper = 't', usecatupd='t' where usename = 'slony';
-</programlisting>
-</answer>
+ <answer>
+ <para>
+ La <quote>solution</quote> est la suivante :
+ </para>
+
+ <programlisting>UPDATE pg_shadow SET usesuper = 't', usecatupd='t'
+WHERE usename = 'slony';</programlisting>
+ </answer>
-<answer><para> En version 8.1 et supérieure, vous avez aussi besoin de:</para>
-<programlisting>
-update pg_authid set rolcatupdate = 't', rolsuper='t' where rolname = 'slony';
-</programlisting>
-</answer>
-</qandaentry>
+ <answer>
+ <para>
+ En version 8.1 et supérieure, vous avez aussi besoin de :
+ </para>
+
+ <programlisting>UPDATE pg_authid SET rolcatupdate = 't', rolsuper='t'
+WHERE rolname = 'slony';</programlisting>
+ </answer>
+ </qandaentry>
-<qandaentry>
-<question><para> Au moment d'enregistrer un esclave, j'obtiens le message suivant dans les logs :
+ <qandaentry>
+ <question>
+ <para>
+ Au moment d'enregistrer un esclave, j'obtiens le message suivant dans
+ les journaux applicatifs :
-<screen>
-DEBUG1 copy_set 1
+ <screen>DEBUG1 copy_set 1
DEBUG1 remoteWorkerThread_1: connected to provider DB
WARN remoteWorkerThread_1: transactions earlier than XID 127314958 are still in progress
-WARN remoteWorkerThread_1: data copy for set 1 failed - sleep 60 seconds
-</screen></para></question>
+WARN remoteWorkerThread_1: data copy for set 1 failed - sleep 60 seconds</screen>
+ </para>
+ </question>
-<answer> <para> Il y a évidemment un certain nombre de vieilles transactions qui empêche &slony1; de traiter des synchronisations. Vous devriez jeter un coup d'oeil à pg_locks pour ce qu'il en est :</para>
+ <answer>
+ <para>
+ Il y a évidemment un certain nombre de vieilles transactions qui
+ empêchent &slony1; de traiter des synchronisations. Vous devriez
+ jeter un coup d'œil à pg_locks pour voir ce qu'il en est :
+ </para>
-<screen>
-sampledb=# select * from pg_locks where transaction is not null order by transaction;
+ <screen>sampledb=# select * from pg_locks where transaction is not null order by transaction;
relation | database | transaction | pid | mode | granted
----------+----------+-------------+---------+---------------+---------
| | 127314921 | 2605100 | ExclusiveLock | t
| | 127326504 | 5660904 | ExclusiveLock | t
-(2 rows)
-</screen>
+(2 rows)</screen>
-<para>Vous voyez ? la transaction 127314921 est en effet plus vieilles que la transaction 127314958, et elle est toujours en cours d'exécution.</para>
+ <para>
+ Vous voyez ? la transaction 127314921 est en effet plus vieille
+ que la transaction 127314958, et elle est toujours en cours d'exécution.
+ </para>
-<para> Un long traitement de publi-postage, une requête <application>RT3</application> qui s'emballe, un
-<application>pg_dump</application>, toutes ces opérations ouvrent des transactions pour une période importante.
-Jusqu'à ce qu'elles soient complétées ou bien interrompues, on verra alors le message d'erreur suivant:
-<quote> data copy
-for set 1 failed - sleep 60 seconds </quote>.</para>
+ <para>
+ Un long traitement de publi-postage, une requête
+ <application>RT3</application> qui s'emballe, un
+ <application>pg_dump</application>, toutes ces opérations ouvrent des
+ transactions pour une période importante. Jusqu'à ce qu'elles soient
+ complétées ou bien interrompues, on verra alors le message d'erreur
+ suivant :
-
-<para>Quoiqu'il en soit, s'il y a plus d'une base de données sur le cluster du &postgres; , et que la charge se situe sur une autre base, vous verrez apparaitre des <quote>transactions en cours avec un XID
-antérieur</quote> à celle de &slony1;. Le fait que la transaction se déroule sur une base de donnée dissociée ne change rien ; &slony1; attendra jusqu'à ce que ces vieilles transactions se terminent.</para>
-</answer>
-</qandaentry>
+ <quote>data copy
+for set 1 failed - sleep 60 seconds </quote>
+ </para>
+ <para>
+ Quoiqu'il en soit, s'il y a plus d'une base de données sur le cluster
+ &postgres; et que la charge se situe sur une autre base, vous verrez
+ apparaître des <quote>transactions en cours avec un XID
+ antérieur</quote> à celle de &slony1;. Le fait que la transaction se
+ déroule sur une base de donnée dissociée ne change rien ; &slony1;
+ attendra jusqu'à ce que ces vieilles transactions se terminent.
+ </para>
+ </answer>
+ </qandaentry>
-<qandaentry>
-<question><para>Même question que précèdemment. J'ai oublié de mentionner que j'essayais d'ajouter
-<emphasis>DEUX</emphasis> abonnés, simultanément.</para></question>
+ <qandaentry>
+ <question>
+ <para>
+ Même question que précèdemment. J'ai oublié de mentionner que
+ j'essayais d'ajouter <emphasis>DEUX</emphasis> abonnés simultanément.
+ </para>
+ </question>
-<answer><para> Cela ne peut pas marcher: &slony1; ne peut employer la commande
-<command>COPY</command> de manière concurrente. Voir la fonction
-<function>copy_set()</function> dans le fichier <filename>src/slon/remote_worker.c</filename></para>
+ <answer>
+ <para>
+ Cela ne peut pas fonctionner : &slony1; ne peut employer pas la
+ commande <command>COPY</command> de manière concurrente. Voir la
+ fonction <function>copy_set()</function> dans le fichier
+ <filename>src/slon/remote_worker.c</filename>.
+ </para>
-<screen>
-$ ps -aef | egrep '[2]605100'
-postgres 2605100 205018 0 18:53:43 pts/3 3:13 postgres: postgres sampledb localhost COPY
-</screen>
+ <screen>$ ps -aef | egrep '[2]605100'
+postgres 2605100 205018 0 18:53:43 pts/3 3:13 postgres: postgres sampledb localhost COPY</screen>
-<para>Une transaction <command>COPY</command>
-essaie d'installer l'abonnement pour un des noeuds. Tout a l'air bien;
-le système s'occupe de configurer le premier abonné; il ne vapas démarrer sur le second tant que le premier n'a pas fini son enregistrement. Cela représente une cause possible.</para>
+ <para>
+ Une transaction <command>COPY</command> essaie d'installer l'abonnement
+ pour un des nœuds. Tout a l'air bien ; le système s'occupe
+ de configurer le premier abonné ; il ne va pas démarrer sur le
+ second tant que le premier n'a pas fini son enregistrement. Cela
+ représente une cause possible.
+ </para>
-<para>Ceci a comme (facheuse) conséquence que vous ne pouvez pas peupler deux esclaves simultanément à partir d'un même fournisseur. Vous devez souscrire un et un seul abonné à la fois,
-une fois qu'il a accompli l'abonnement,( en copiant le contenu des table, etc.), on peut s'occuper de débuter l'enregistrement
-du deuxième.</para></answer>
-</qandaentry>
+ <para>
+ Ceci a comme (fâcheuse) conséquence que vous ne pouvez pas peupler deux
+ esclaves simultanément à partir d'un même fournisseur. Vous devez
+ souscrire un et un seul abonné à la fois. Une fois qu'il a accompli
+ l'abonnement (en copiant le contenu des table, etc.), on peut s'occuper
+ de débuter l'enregistrement du deuxième.
+ </para>
+ </answer>
+ </qandaentry>
-<qandaentry id="missingoids"> <question> <para> Nous avons rencontré un message inattendu en désinstallant entièrement un cluster de réplication slony sur le maître et l'esclave.</para>
+ <qandaentry id="missingoids">
+ <question>
+ <para>
+ Nous avons rencontré un message inattendu en désinstallant entièrement
+ un cluster de réplication slony sur le maître et l'esclave.
+ </para>
-<warning> <para><emphasis>MAKE SURE YOU STOP YOUR APPLICATION RUNNING
-AGAINST YOUR MASTER DATABASE WHEN REMOVING THE WHOLE SLONY
-CLUSTER</emphasis>, or at least re-cycle all your open connections
-after the event! </para></warning>
+ <warning>
+ <para>
+ <emphasis>MAKE SURE YOU STOP YOUR APPLICATION RUNNING AGAINST YOUR
+ MASTER DATABASE WHEN REMOVING THE WHOLE SLONY CLUSTER</emphasis>,
+ or at least re-cycle all your open connections after the event!
+ </para>
+ </warning>
-<para> The connections <quote>remember</quote> or refer to OIDs which
-are removed by the uninstall node script. And you will get lots of
-errors as a result...
-</para>
+ <para>
+ The connections <quote>remember</quote> or refer to OIDs which are
+ removed by the uninstall node script. And you will get lots of errors
+ as a result...
+ </para>
+ </question>
+ <answer>
+ <para>
+ Il y a deux mécanismes de &postgres; qui mettent en cache les plans
+ d'interrogation et les OIDs :
+ </para>
-</question>
+ <itemizedlist>
+ <listitem>
+ <para>les requêtes préparées (« prepared statements ») ;</para>
+ </listitem>
+ <listitem>
+ <para>les fonctions PL/pgsql.</para>
+ </listitem>
+ </itemizedlist>
-<answer><para> Il y a deux mécanismes de
-&postgres; qui mettent en cache les plans d'interrogation et les OIDs:</para>
-<itemizedlist>
-<listitem><para> Les requêtes préparées ("prepared statements")</para></listitem>
-<listitem><para> Les fonctions pl/pgSQL </para></listitem>
-</itemizedlist>
+ <para>
+ Ce problème n'est pas particulier à &slony1;; il se produit à chaque
+ fois que des modifications importantes sont apportées aux schémas de
+ la base de données. Cela n'entraîne pas de perte des données mais cela
+ provoque des vagues d'erreurs relatives aux OID.
+ </para>
+ </answer>
-<para>Ce problème n'est pas pas particulier à &slony1;;
-il se produit à chaque fois quand des modifications importantes sont apportées aux schémas de la base
-de données. Cela n'entaine pas de perte des données, mais cela provoque des vagues d'erreurs relatives aux OID.
-</para></answer>
-
-<answer><para> Le problème survient lorsque vous utilisez une sorte de
-<quote>pool de connexion</quote> qui recycle les vieilles connexions.
-Si vous relancez l'application après ceci, les nouvelles connexions
-vont produire de <emphasis>nouveau</emphasis>plan d'exécution et les erreurs disparaitront. Si votre pool de connexion tue les sessions, et en recrée de nouvelles, alors ces nouvelles sessions auront de <emphasis>nouveaux</emphasis> plans d'exécution, et que les erreurs disparaîtront. </para></answer>
+ <answer>
+ <para>
+ Le problème survient lorsque vous utilisez une sorte de <quote>pool de
+ connexion</quote> qui recycle les vieilles connexions. Si vous relancez
+ l'application après ceci, les nouvelles connexions vont produire de
+ <emphasis>nouveaux</emphasis> plans d'exécution et les erreurs
+ disparaîtront. Si votre pool de connexion tue les sessions et en
+ recrée de nouvelles, alors ces nouvelles sessions auront de
+ <emphasis>nouveaux</emphasis> plans d'exécution et les erreurs disparaîtront.
+ </para>
+ </answer>
-<answer> <para> Dans notre code nous éliminons toutes connexions ayant des erreurs inattendues dans
-le contexte. Ainsi, toutes les connexions devraient être renouvelées dès l'apparition d'une erreur
-inattendue. Naturellement si l'erreur remonte une violation de contrainte, qui est une condition reconnue, ce va provoquer une renouvellement de connexion, et si le problème persiste, les connexions sont recyclées en permanence, ce qui annulera l'effet du pool, dans ce cas, le pooler de connexion proposera probablement à l'administrateur de jeter un coup d'oeil à la situation. </para> </answer>
+ <answer>
+ <para>
+ Dans notre code, nous éliminons toutes connexions ayant des erreurs
+ inattendues dans le contexte. Ainsi, toutes les connexions devraient
+ être renouvelées dès l'apparition d'une erreur inattendue.
+ Naturellement, si l'erreur remonte une violation de contrainte, qui est
+ une condition reconnue, cela va provoquer un renouvellement de connexion.
+ Si le problème persiste, les connexions sont recyclées en permanence,
+ ce qui annulera l'effet du pool. Dans ce cas, le pooler de connexion
+ proposera probablement à l'administrateur de jeter un coup d'œil
+ à la situation.
+ </para>
+ </answer>
+ </qandaentry>
-</qandaentry>
+ <qandaentry>
+ <question>
+ <para>
+ J'ai migré mon &slony1; en version 1.2. J'ai maintenant cet
+ avertissement dans les journaux applicatifs :
+ </para>
-<qandaentry><question><para> J'ai migré mon &slony1; en version
-1.2. J'ai maintenant cet avertissement dans les logs:</para>
+ <screen>NOTICE: Slony-I: log switch to sl_log_2 still in progress - sl_log_1 not truncated</screen>
-<screen>NOTICE: Slony-I: log switch to sl_log_2 still in progress - sl_log_1 not truncated</screen>
+ <para>
+ Les tables <envar>sl_log_1</envar> et <envar>sl_log_2</envar>
+ continuent de prendre du volume, et <envar>sl_log_1</envar> n'est
+ jamais vidée. Quel est le souci ?
+ </para>
+ </question>
-<para> Les tables <envar>sl_log_1</envar> et <envar>sl_log_2</envar> continue de prendre du volume,
-et <envar>sl_log_1</envar> n'est jamais vidée.
-Quel est le souci?
-</para> </question>
+ <answer>
+ <para>
+ Ceci est un cas symptomatique du problème précèdent, relatif à la
+ suppression de la réplication : s'il y a des vieilles connexions
+ établies, qui continuent à utiliser des plan d'exécutions basés sur
+ des vieilles procédures stockées, cela provoque des écritures dans
+ <envar>sl_log_1</envar>.
+ </para>
-<answer><para> Ceci est un cas symptomatique du problème précèdent,
-relatif à la suppression de réplication : s'il y a des vieilles connexions établies, qui continuent à utiliser des plan d'exécutions
-basés sur des vieilles fonctions stockées, ce qui provoque des écritures dans <envar>sl_log_1</envar> </para>
+ <para>
+ La fermeture des vieilles connexions et l'ouverture de nouvelles
+ connexions résoudra ce problème.
+ </para>
+ </answer>
-<para> La fermeture des vieilles connexions et l'ouverture des nouvelles connexions, résoudra ce problème.</para> </answer>
+ <answer>
+ <para>
+ À plus long terme, un élément de la liste des choses à faire pour
+ &postgres; est l'implantation d'une vérification des dépendances, qui
+ pourra supprimer un plan d'exécution caché lorsqu'un objet lié à ce
+ plan est modifié.
+ </para>
+ </answer>
+ </qandaentry>
-<answer> <para> A plus long terme, il y a un item dans la TODO liste de &postgres; pour implémenter une vérification des dépendances, qui pourra supprimer un plan d'exécution caché, lorsque un objet lié à ce plan est modifié. </para> </answer>
-</qandaentry>
+ <qandaentry>
+ <question>
+ <para>
+ J'ai pointé un nœud abonné vers un nœud fournisseur différent,
+ et il a cessé la réplication.
+ </para>
+ </question>
-<qandaentry>
-<question><para>J'ai pointé un noeud abonné vers un noeud fournisseur différent, et il a cessé la réplication.</para></question>
+ <answer>
+ <para>
+ Nous avons constaté que ceci arrive lorsque on réinitialise un
+ nœud dans la configuration suivante :
-<answer><para>
-Nous avons constaté que ceci arrive lorsque on réinitialise un noeud dans la configuration suivante:
+ <itemizedlist>
+ <listitem>
+ <para>Nœud 1 - fournisseur</para>
+ </listitem>
+ <listitem>
+ <para>
+ Nœud 2 - abonné au nœud 1 - le nœud que l'on
+ réinitialise
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Nœud 3 - abonné au nœud 3 - le nœud qui doit
+ continuer à répliquer
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
-<itemizedlist>
-<listitem><para> Noeud 1 - fournisseur</para></listitem>
-<listitem><para> Noeud 2 - abonné au noeud 1 - le noeud que l'on réinitialise</para></listitem>
-<listitem><para> Noeud 3 - abonné au noeud 3 - le noeud qui doit continuer à répliquer</para></listitem>
-</itemizedlist></para>
+ <para>
+ L'abonnement du nœud 3 est changé pour que le nœud 1 soit
+ son fournisseur et on exécute <xref linkend="stmtdropset"/> / <xref
+ linkend="stmtsubscribeset"/> sur le nœud 2 pour qu'il soit
+ repeuplé.
+ </para>
-<para>L'abonnement du noeud 3 est changé pour que le noeud 1 soit
-son fournisseur et on exécute <xref linkend="stmtdropset"/> /<xref
-linkend="stmtsubscribeset"/> sur le noeud 2 pour qu'il soit repeuplé.</para>
+ <para>
+ Malheureusement, la réplication s'arrête soudainement sur le nœud
+ 3.
+ </para>
-<para>Malheureusement, la réplication s'arrête soudainement sur le noeud 3.</para>
+ <para>
+ Le problème vient du fait qu'il n'y a pas d'ensemble approprié de
+ <quote>voies d'écoute</quote> dans la table <xref
+ linkend="table.sl-listen"/> pour propager les évènements depuis le
+ nœud 1 vers le nœud 3. Les événements sont transportés vers
+ le nœud 2 et sont bloqués par l'événement <xref
+ linkend="stmtsubscribeset"/> que le nœud 2 est en train de
+ traiter.
+ </para>
-<para>Le problème vient du fait qu'il n'y a pas d'ensemble approprié de
-<quote>voies d'écoute</quote> dans la table <xref linkend="table.sl-listen"/> pour propager les évènements
-depuis le noeud 1 vers sur le noeud 3. Les événements sont transportés vers le noeud 2 et sont bloqués par l'événement <xref linkend="stmtsubscribeset"/> que le noeud 2 est en train de traiter.</para>
+ <para>
+ Le script suivant supprime les voies d'écoute qui font transiter les
+ événements par le nœud 2 et ajoute une voie d'écoute directe
+ entre les nœuds 1 et 3.
-<para>Le script suivant supprime les voies d'écoute qui font transiter les events par le noeud 2 et ajouter une voie d'écoute directe entre les noeuds 1 et 3.
-
-<programlisting>
-cluster name = oxrslive;
+ <programlisting>cluster name = oxrslive;
node 1 admin conninfo='host=32.85.68.220 dbname=oxrslive user=postgres port=5432';
node 2 admin conninfo='host=32.85.68.216 dbname=oxrslive user=postgres port=5432';
node 3 admin conninfo='host=32.85.68.244 dbname=oxrslive user=postgres port=5432';
@@ -449,32 +1071,46 @@
store listen (origin = 3, receiver = 1, provider = 3);
drop listen (origin = 1, receiver = 3, provider = 2);
drop listen (origin = 3, receiver = 1, provider = 2);
-}
-</programlisting></para>
+}</programlisting></para>
-<para>Juste après l'éxécution de ce script, les événements <command>SYNC</command> se propagent à nouveau vers le noeud 3.
+ <para>
+ Juste après l'exécution de ce script, les événements
+ <command>SYNC</command> se propagent à nouveau vers le nœud 3.
+ Ceci souligne deux principes :
-Ceci souligne deux principes:
-<itemizedlist>
-<listitem><para>
-Si vous avez plusieurs noeuds, et des abonnés en cascade,
-vous devez faire attention en repeuplant les entrés <xref
-linkend="stmtstorelisten"/>, et en modifiant si la structure de l'<quote>arbre</quote> de réplication a changé.</para></listitem>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Si vous avez plusieurs nœuds et des abonnés en cascade,
+ vous devez faire attention en repeuplant les entrées <xref
+ linkend="stmtstorelisten"/> et en les modifiant si la structure
+ de l'<quote>arbre</quote> de réplication a changé.
+ </para>
+ </listitem>
-<listitem><para> La version 1.1 fourni des meilleurs outils pour gérer ce cas.</para>
-</listitem>
+ <listitem>
+ <para>
+ La version 1.1 fourni des meilleurs outils pour gérer ce cas.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
-</itemizedlist></para>
+ <para>
+ Les problèmes relatifs aux <quote>voies d'écoute</quote> sont discutés
+ avec plus de précisions dans la section <xref linkend="listenpaths"/>.
+ </para>
+ </answer>
+ </qandaentry>
-<para>Les problèmes relatifs aux <quote>voies d'écoute</quote> sont discutés plus précisions dans la section <xref linkend="listenpaths"/> </para></answer>
-</qandaentry>
+ <qandaentry id="multipleslonconnections">
+ <question>
+ <para>
+ En redémarrant &lslon;, j'obtiens les messages <quote>FATAL</quote>
+ suivants dans les journaux applicatifs. Que se passe-t-il ?
+ </para>
-<qandaentry id="multipleslonconnections">
-
-<question><para> En redémarrant &lslon;, j'obtiens
-les messages <quote>FATAL</quote> suivants dans le log. Que se passe-t-il??? </para>
-<screen>
-2006-03-29 16:01:34 UTC CONFIG main: slon version 1.2.0 starting up
+ <screen>2006-03-29 16:01:34 UTC CONFIG main: slon version 1.2.0 starting up
2006-03-29 16:01:34 UTC DEBUG2 slon: watchdog process started
2006-03-29 16:01:34 UTC DEBUG2 slon: watchdog ready - pid = 28326
2006-03-29 16:01:34 UTC DEBUG2 slon: worker process created - pid = 28327
@@ -490,247 +1126,488 @@
2006-03-29 16:01:34 UTC FATAL localListenThread: "select "_test1538".cleanupNodelock(); insert into "_test1538".sl_nodelock values ( 1, 0, "pg_catalog".pg_backend_pid()); " - ERROR: duplicate key violates unique constraint "sl_nodelock-pkey"
2006-03-29 16:01:34 UTC FATAL Do you already have a slon running against this node?
-2006-03-29 16:01:34 UTC FATAL Or perhaps a residual idle backend connection from a dead slon?
-</screen>
+2006-03-29 16:01:34 UTC FATAL Or perhaps a residual idle backend connection from a dead slon?</screen>
-</question>
+ </question>
-<answer><para> La table <envar>sl_nodelock</envar> est utilisée comme un
-<quote>verrou partagé</quote>pour empêcher que deux processus &lslon; essaient de prendre le controle du même noeud en même temps. Le &lslon; essaie d'insérer un enregistrement dans la table; il ne peut réussier que si il est le seul à gérer le noeud. </para></answer>
+ <answer>
+ <para>
+ La table <envar>sl_nodelock</envar> est utilisée comme un <quote>verrou
+ partagé</quote> pour empêcher que deux processus &lslon; essaient de
+ prendre le controle du même nœud en même temps. Le &lslon; essaie
+ d'insérer un enregistrement dans la table ; il ne peut réussir que
+ s'il est le seul à gérer le nœud.
+ </para>
+ </answer>
-<answer><para> Ce message d'erreur est typiquement un signe que vous avez démarrez un second processus &lslon; pour un noeud donné. Le &lslon; pose la question évidente qui est : <quote>Avez vous déjà un slon démarré pour gérer ce noeud?</quote> </para></answer>
+ <answer>
+ <para>
+ Ce message d'erreur est typiquement un signe que vous avez démarrez un
+ second processus &lslon; pour un nœud donné. Le &lslon; pose la
+ question évidente suivante : <quote>avez-vous déjà un slon démarré
+ pour gérer ce nœud ?</quote>
+ </para>
+ </answer>
-<answer><para> En supposant que vous subissez une panne de réseau,
-les connections entre &lslon; et la base de données peuvent échouer, et &lslon; peut s'en apercevoir bien avant l'instance de &postgres; sur laquelle il est connecté.
-La conséquence en est qu'un certain nombre de connexion pré-établie vont rester ouvertes sur la base de données jusqu'à ce que le timeout de TCP/IP arrive à échéance, chose qui nomallement arrive au bout de
-deux heures. Durant cette période de deux heures, le &lslon; va essayer de se reconnecter, encore et encore, et obtient le message d'erreur ci-dessous, encore et encore. </para>
+ <answer>
+ <para>
+ En supposant que vous subissez une panne réseau, les connections entre
+ &lslon; et la base de données peuvent échouer et &lslon; peut s'en
+ apercevoir bien avant l'instance de &postgres; sur laquelle il est
+ connecté. La conséquence en est qu'un certain nombre de connexions
+ pré-établies vont rester ouvertes sur la base de données jusqu'à ce
+ que le timeout TCP/IP arrive à échéance, chose qui normalement arrive
+ au bout de deux heures. Durant cette période de deux heures, le &lslon;
+ va essayer de se reconnecter, encore et encore, et fait que vous
+ obtenez le message d'erreur ci-dessous, encore et encore.
+ </para>
-<para> Un administrateur peut mettre fin à cette situation en se connectant sur
-le serveur et en lançant <command>kill -2</command> pour terminer les connexions bloquantes.
-Malheureusement , puisque le problème a eu lieu au niveau de la couche réseau, &postgres; et &slony1;
-n'ont aucun moyen direct de détecter ceci. </para>
+ <para>
+ Un administrateur peut mettre fin à cette situation en se connectant sur
+ le serveur et en lançant <command>kill -2</command> pour terminer les
+ connexions bloquantes. Malheureusement, puisque le problème a eu lieu
+ au niveau de la couche réseau, &postgres; et &slony1; n'ont aucun
+ moyen direct de détecter ceci.
+ </para>
-<para> Vous pouvez éviter ceci dans <emphasis>la plupart</emphasis> des cas en vous assurant que le processus &lslon; est hébergé à proximité des serveurs qu'il gère. Si le &lslon;
-est hébergé sur le même serveur que la base de donnée qu'il gère, alors
-toute <quote>panne de réseau</quote> qui peut interrompre les connexions
-serait susceptible d'être assez sérieuse pour menacer le serveur entier. </para></answer>
-</qandaentry>
+ <para>
+ Vous pouvez éviter ceci dans la <emphasis>plupart</emphasis> des cas
+ en vous assurant que le processus &lslon; est hébergé à proximité des
+ serveurs qu'il gère. Si le &lslon; est hébergé sur le même serveur que
+ la base de donnée qu'il gère, alors toute <quote>panne réseau</quote>
+ qui peut interrompre les connexions serait susceptible d'être assez
+ sérieus pour menacer le serveur entier.
+ </para>
+ </answer>
+ </qandaentry>
+ <qandaentry>
+ <question>
+ <para>
+ Quand puis-je arrêter les processus &lslon; ?
+ </para>
+ </question>
-<qandaentry>
-<question><para> Quand est-ce que je peux arrêter les processus &lslon;?</para></question>
+ <answer>
+ <para>
+ Généralement, il n'y a aucun risque à arrêter un processus &lslon;.
+ Chacun d'eux est <quote>simplement</quote> un client de &postgres;,
+ gérant un nœud, qui déploie des threads pour gérer et recevoir
+ des évènements depuis d'autres nœuds.
+ </para>
-<answer><para> Généralement, il n'y a aucun risque à arrêter un processus &lslon;. Chacun d'eux est un <quote>simplement</quote> un client de &postgres;, gérant un noeud, qui déploie des threads pour gérer et recevoir des évènements
-depuis d'autres noeuds. </para>
+ <para>
+ Les threads des <quote>évènements d'écoute</quote> ne sont pas très
+ importants ; ils ne font que vérifier de temps en temps les
+ nœuds distants pour déterminer s'il y a des taches à faire sur
+ le nœud local. Si vous tuez le processus &lslon; ces threads de
+ surveillance seront fermés, ce qui aura peu ou pas du tout d'impact.
+ Les événements produits pendant que &lslon; est arrêté seront récupérés
+ lors de son redémarrage.
+ </para>
-<para>Les threads des<quote>évènements d'écoute</quote> ne sont pas
-très importants; ils ne font que vérifier de temps en temps les noeuds distants pour déterminer si il y a des taches à faire sur le noeud local. Si vous tuez le processus &lslon; ces threads de surveillance seront fermés, qui aura peu ou pas du tout d'impact. Les éventements produits pendant que &lslon; est arrêté seront récupérés
-lors de son redémarrage.</para>
+ <para>
+ Le thread de <quote>gestion des nœuds</quote> est un peu plus
+ intéressant ; la plupart du temps, sur un abonné, on peut
+ s'attendre à ce que le thread traite des événements
+ <command>SYNC</command>. Si vous arrêtez le &lslon; durant un évènement,
+ la transaction va échouer et s'annuler. Lorsque &lslon; redémarre, il
+ reprendra l'évènement pour l'exécuter.
+ </para>
-<para> Le thread de <quote>gestion des noeuds</quote> est un peu plus intéressant; la plupart du temps sur un abonné, on peut s'attendre à ce que le ce thread traite des évènements <command>SYNC</command>. Si vous arrêtez le &lslon; durant un évènement, la transaction va échouer, et s'annuler, et lorsque &lslon;
-redémarre, il reprendra l'évènement pour l'exécuter.</para>
+ <para>
+ L'unique situation où cela peut provoquer des problèmes
+ <emphasis>particulièrs</emphasis> est lorsque l'évènement en cours est
+ un traitement de longue durée comme un <command>COPY_SET</command> pour
+ un large ensemble de réplication.
+ </para>
-<para> L'unique situation où cela peut provoquer des problèmes <emphasis>particulièrs</emphasis> est lorsque l'évènement en cours est un traitement de longue durée comme,
-un <command>COPY_SET</command> pour une large ensemble de réplication.</para>
+ <para>
+ L'autre chose qui <emphasis>pourrait</emphasis> poser problème
+ est s'il est relativement distant du nœud auxquel il est
+ connecté ; vous pouvez découvrir que les connexions de la base
+ de données sont laissées <command>disponibles en transaction</command>
+ (« idle in transaction »). Ceci peut survenir si les
+ connexions réseaux sont supprimées sans que ni &lslon; ni la base en
+ aient pris connaissance. Dans ce cas, vous pouvez découvrir que des
+ connexions <quote>zombies</quote> traînent encore durant deux longues
+ heures si vous n'allez pas tuer à la main les processus &postgres;.
+ </para>
-<para>L'autre chose qui <emphasis>pourrait</emphasis> poser problème relativement distant du noeud auxquel il est connecté;
-vous pouvez découvrir que les connexions de la base de données sont laissées <command>disponible en transaction</command> ("idle in transaction").
-Ceci peut peut arriver si les connexions réseaux sont supprimées sans que &lslon; ni la base en ait pris connaissance
-.Dans ce cas vous pouvez découvrir que des connexions <quote>zombies</quote> traînent encore durant deux long heures
-si vous n'aller pas tuer à la main les processus &postgres;
-.</para>
+ <para>
+ Il y existe un autre cas qui peut poser problème : quand le
+ processus &lslon; qui administre le nœud origine ne fonctionne
+ pas, aucun évènement <command>SYNC</command> ne s'exécute sur ce
+ nœud. Si le &lslon; reste arrêté pendant une longue durée et
+ qu'aucun processus de type <xref linkend="gensync"/> n'est en cours,
+ alors vous pouvez vous retrouver avec <emphasis>un énorme
+ <command>SYNC</command></emphasis> à effectuer lorsque le processus
+ &lslon; du nœud origine sera relancé. Toutefois, ceci est vrai
+ seulement si &lslon; est en arrêt pendant une période assez
+ longue ; un arrêt de quelques secondes ne génère pas de problèmes.
+ </para>
+ </answer>
+ </qandaentry>
-<para> Il y existe un autre cas qui peut poser problème : quand
+ <qandaentry>
+ <question>
+ <para>
+ Y a-t-il des risques lorsqu'on arrête &lslon; ? Quels sont les
+ avantages ?
+ </para>
+ </question>
-le processus &lslon; qui administre le noeud origine ne fonctionne pas,
-aucun évènement <command>SYNC</command> ne s'exécute sur ce noeud.
-Si le &lslon; reste arrêté pendant une longue durée, et qu'aucun processus de type
-<xref linkend="gensync"/> n'est en cours, alors vous pouvez vous retrouvez avec
-<emphasis>un énorme <command>SYNC</command></emphasis> à effectuer
-lorsque le processus &lslon; du noeud origine sera relancé.
-Toutefois ceci est vrai seulement si &lslon; est en arrêt pendant une période
-assez longue; un arrêt de quelques secondes ne génère pas de problèmes.</para> </answer>
-</qandaentry>
+ <answer>
+ <para>
+ En bref, si un <command>COPY_SET</command> qui dure 18h n'est pas en
+ cours d'exécution, alors ce n'est pas un grand sacrifice d'arrêter un
+ &lslon; pendant quelques instants, ni même de relancer
+ <emphasis>tous</emphasis> les &lslon;.
+ </para>
+ </answer>
+ </qandaentry>
+</qandadiv>
-<qandaentry>
-<question><para> Y a-t-il des risques lorsque l'on arrête &lslon; ? Quels sont les avantages ?</para></question>
+<qandadiv id="faqconfiguration">
+ <title>FAQ &slony1; : Problèmes de configuration</title>
-<answer><para> En bref, si un <command>COPY_SET</command> qui dure 18h n'est pas en cours d'exécution
-, alors ce n'est pas un grand sacrifice d'arrêter un &lslon; pendant quelques instants, ni même
-de relancer <emphasis>tous</emphasis> les &lslon;s. </para> </answer>
-</qandaentry>
+ <qandaentry>
+ <question>
+ <para>
+ Slonik échoue lors du chargement des bibliothèques &postgres; :
+ <command>PGRES_FATAL_ERROR load '$libdir/xxid';</command>
+ </para>
-</qandadiv>
+ <para>
+ Lorsque j'exécute un simple script de configuration, j'obtiens un
+ message similaire à :
-<qandadiv id="faqconfiguration"> <title> &slony1; FAQ: Problèmes de configuration </title>
-<qandaentry>
-<question><para>Slonik tombe échoue lors du chargement des librairies &postgres; :
-<command>PGRES_FATAL_ERROR load '$libdir/xxid';</command></para>
+ <command>stdin:64: PGRES_FATAL_ERROR load '$libdir/xxid'; - ERROR: LOAD:
+could not open file '$libdir/xxid': No such file or directory</command>
+ </para>
+ </question>
-<para> Lorsque j'exécute un simple script de configuration, j'obtiens un message similaire à :
+ <answer>
+ <para>
+ Évidemment, vous n'avez pas accès à la bibliothèque
+ <filename>xxid.so</filename> dans le répertoire <envar>$libdir</envar>
+ que l'instance &postgres; utilise. Notez que les composants &slony1;
+ doivent être installés avec le noyau &postgres; sur <emphasis>chacun
+ des nœuds</emphasis> et pas seulement sur le nœud d'origine.
+ </para>
-<command>
-stdin:64: PGRES_FATAL_ERROR load '$libdir/xxid'; - ERROR: LOAD:
-could not open file '$libdir/xxid': No such file or directory
-</command></para></question>
+ <para>
+ Cela peut également venir du fait d'une disparité entre les binaires
+ du noyau &postgres; et celui du noyau de &slony1;. Si vous avez
+ manuellement compilé &slony1; par vous-même, sur une machine où il y
+ a plusieurs versions de &postgres;, il est possible que les binaires
+ slon ou slonik demande de charger une bibliothèque qui n'est pas
+ accessible dans les répertoires des bibliothèques de la version de
+ &postgres; utilisée.
+ </para>
-<answer><para> Evidemment, vous n'avez pas accès à la librairie
-<filename>xxid.so</filename> dans le répertoire <envar>$libdir</envar>
-que l'instance &postgres; utilise. Notez que les composants &slony1; doivent être installés avec le noyau du &postgres;
-sur <emphasis>chacun des noeuds</emphasis> et pas seulement sur le noeud d'origine.</para>
+ <para>
+ En deux mots : ceci indique que vous devez <quote>auditer</quote>
+ l'installation des instances &postgres; et &slony1; qui sont en place
+ sur la machine. Malheureusement, n'importe quelle incompatibilité peut
+ faire remonter ce genre d'erreur. Voir aussi la <link
+ linkend="threadsafety">sécurité des threads</link> à propos de la
+ gestion des threads sur Solaris.
+ </para>
-<para>Cela peut également venir du fait d'une disparité entre les binaires du noyau &postgres; et celui du noyau de &slony1;. Si vous avez manuellement compilé &slony1; par vous-même, sur une machine où il y a plusieurs versions de &postgres;, il est possible que les binaires slon ou lslonik demande de charger une librairie qui n'est pas accessible dans les répertoires des librairies de la version de &postgres; utilisée.</para>
+ <para>
+ La situation est plus simple si vous avez une seule version de
+ &postgres; installée par serveur ; dans ce cas, il n'y aura pas
+ d'<quote>incompatibilité de chemins</quote> là où les composants de
+ &slony1; sont installés. Si vous avez une installation multiple, vous
+ devrez vous assurer que la bonne version de &slony1; est associée à la
+ bonne version du noyau de &postgres;.
+ </para>
+ </answer>
+ </qandaentry>
-<para>En deux mots : Ceci indique que vous devez <quote>auditer</quote>
-comment ont été installés les instances &postgres; et de &slony1; qui sont en place sur la machine. Malheureusement, n'importe quelle incompatibilité peut faire remonter ce genre d'erreur. Voir aussi <link linkend="threadsafety"> sécurité des threads </link> à propos de la gestion des threads sur Solaris.</para>
+ <qandaentry>
+ <question>
+ <para>
+ J'essaie de créer un cluster dont le nom contient un tiret. Cela ne
+ fonctionne pas.
+ </para>
+ </question>
-<para> La situation est plus simple si vous avez une seule version de &postgres; installée par serveur; dans ce cas il n'y aura pas d' <quote>incompatibilité de chemins</quote> là ou les composants de &slony1; sont installés. Si vous avez une installation multiple,
-vous devrez vous assurez que la bonne version de &slony1; est associée
-Ã la bonne version du noyau de &postgres;. </para></answer></qandaentry>
+ <answer>
+ <para>
+ &slony1; utilise les mêmes règles de nommage que &postgres;, donc vous
+ ne devriez pas utiliser un tiret dans les identifiants.
+ </para>
-<qandaentry>
-<question> <para>J'essaie de créer un cluster dont le nom contient un "-". Cela ne marche pas.</para></question>
+ <para>
+ Vous pouvez tenter de mettre des simples <quote>guillemets</quote> pour
+ l'identifiant, mais vous allez vous exposer à des soucis qui pourront
+ surgir à tout moment.
+ </para>
+ </answer>
+ </qandaentry>
-<answer><para> &slony1; utilise les mêmes règles de nommage que &postgres;, donc vous ne devrize pas utiliser un "-"
-dans les identifiants.</para>
+ <qandaentry>
+ <question>
+ <para>
+ La commande ps affiche le mot de passe en clair.
+ </para>
-<para> Vous pouvez tenter de mettre des simples <quote>quotes</quote> pour l'identifiant, mais vous allez vous exposer à des soucis, qui pourront surgir à tout moment.</para>
-</answer>
-</qandaentry>
+ <para>
+ Avec la commande <command>ps</command>, tout le monde peut voir le mot
+ de passe qui a été fourni sur la ligne de commande.
+ </para>
+ </question>
-<qandaentry>
-<question><para>La commande ps affiche le mot de passe en clair</para>
+ <answer>
+ <para>
+ Conservez le mot de passe en dehors de la configuration Slony, en les
+ mettant dans le fichier <filename>$(HOME)/.pgpass.</filename>.
+ </para>
+ </answer>
+ </qandaentry>
-<para> Avec la commande <command>ps</command>, tout le monde,
-peut voir le mot de passe qui a été fourni à la ligne de commande.</para></question>
+ <qandaentry>
+ <question>
+ <para>
+ Les index dont le nom contient le namespace
-<answer> <para>Conservez le mot de passe en dehors de la configuration Slony, en les mettant dans le fichier <filename>$(HOME)/.pgpass.</filename></para>
-</answer></qandaentry>
-
-<qandaentry>
-<question><para>Indexes dont le nom contient le namespace
-
-<programlisting>
-set add table (set id = 1, origin = 1, id = 27,
+ <programlisting>set add table (set id = 1, origin = 1, id = 27,
full qualified name = 'nspace.ma_table',
key = 'clef_sur_une_colonne',
- comment = 'une table ma_table dans le namespace nspace avec une clef primaire');
-</programlisting></para></question>
+ comment = 'une table ma_table dans le namespace nspace avec une clef primaire');</programlisting>
+ </para>
+ </question>
-<answer><para> Si vous avez <command> key =
-'nspace.clef_sur_une_colonne'</command> la requête
-<emphasis>échoura</emphasis>.</para>
-</answer></qandaentry>
+ <answer>
+ <para>
+ Si vous avez <command> key = 'nspace.clef_sur_une_colonne'</command>,
+ la requête <emphasis>échouera</emphasis>.
+ </para>
+ </answer>
+ </qandaentry>
-<qandaentry>
-<question> <para> La réplication est retardée, et il semble que les requêtes sur les tables
-<xref linkend="table.sl-log-1"/>/<xref
-linkend="table.sl-log-2"/> prennent beaucoup de temps alors qu'il n'y a que quelques événements <command>SYNC</command>s. </para>
-</question>
+ <qandaentry>
+ <question>
+ <para>
+ La réplication est retardée, et il semble que les requêtes sur les
+ tables &sllog1;/&sllog2; prennent beaucoup de temps alors qu'il n'y a
+ que quelques événements <command>SYNC</command>.
+ </para>
+ </question>
-<answer> <para> Jusqu'Ã la version 1.1.1, les tables <xref
-linkend="table.sl-log-1"/>/<xref linkend="table.sl-log-2"/>,possédaient seulement un index, et lorsque il y avait plusieurs ensembles de réplication, quelques colonnes dans l'index n'était pas assez très discriminantes.
-Si l'index ne contient pas la colonne<function> log_xid</function>, il est conseillé de l'ajouter. Voir le script
-<filename>slony1_base.sql</filename> pour regarder la manière de créer cet index.
-</para>
-</answer>
-</qandaentry>
+ <answer>
+ <para>
+ Jusqu'à la version 1.1.1, les tables &sllog1;/&sllog2; possédaient
+ seulement un index, et lorsqu'il y avait plusieurs ensembles de
+ réplication, quelques colonnes dans l'index n'étaient pas assez
+ discriminantes. Si l'index ne contient pas la colonne
+ <function>log_xid</function>, il est conseillé de l'ajouter. Voir le
+ script <filename>slony1_base.sql</filename> pour regarder la manière
+ de créer cet index.
+ </para>
+ </answer>
+ </qandaentry>
-<qandaentry><question> <para> J'ai besoin de renommer une colonne qui figure dans la clef
-primaire pour l'une de mes tables répliquées. L'opération est un peu dangereuse, n'est-ce pas ?
-Je dois retirer la table de la réplication puis la replacer, c'est bien ça ?</para>
-</question>
+ <qandaentry>
+ <question>
+ <para>
+ J'ai besoin de renommer une colonne qui figure dans la clef primaire
+ pour l'une de mes tables répliquées. L'opération est un peu dangereuse,
+ n'est-ce pas ? Je dois retirer la table de la réplication puis la
+ replacer, c'est bien ça ?
+ </para>
+ </question>
-<answer><para> En fait, cette opération fonctionne proprement. &slony1; fait un usage intensif des
-clefs primaires, mais en pratique ce type d'opération peut se faire de manière transparente.</para>.
+ <answer>
+ <para>
+ En fait, cette opération fonctionne proprement. &slony1; fait un usage
+ intensif des clefs primaires mais, en pratique, ce type d'opération
+ peut se faire de manière transparente.
+ </para>
-<para> Supposons que vous souhaiter renommez une colonne, avec la
-commande DDL suivante<command> alter table accounts alter column aid rename to cid; </command> Ceci
-permet de renommer la colonne dans la table; elle permet de mettre à jour <emphasis>simultanément</emphasis> l'index de la clef primaire. Le résultat est que ce genre de changement s'effectue simultanément sur un noeud donné.</para>
+ <para>
+ Supposons que vous souhaitez renommer une colonne, avec la commande DDL
+ suivante <command>ALTER TABLE accounts ALTER COLUMN aid RENAME TO
+ cid;</command>. Ceci permet de renommer la colonne dans la table ;
+ elle permet de mettre à jour <emphasis>simultanément</emphasis> l'index
+ de la clef primaire. Le résultat est que ce genre de changement
+ s'effectue simultanément sur un nœud donné.
+ </para>
-<para> Dans l' <emphasis>ideal</emphasis> et pour bien faire les choses il aurait fallu utiliser <xref linkend="stmtddlscript"/> pour déployer la modification au moment sur chaque noeud.</para>
+ <para>
+ Dans l'<emphasis>ideal</emphasis> et pour bien faire les choses, il
+ aurait fallu utiliser <xref linkend="stmtddlscript"/> pour déployer
+ la modification au bon moment sur chaque nœud.
+ </para>
-<para> Toutefois ce n'est pas forcément nécessaire. Tant que la modification est appliquée sur le noeud origine avant d'être effectuée sur les abonnés, il n'y aura pas de cassure irrémédiable. Certains évènements <command>SYNC</command> qui n'incluent pas la table sur laquelle il y a la modification, pourront fonctionner sans problème... Par contre lorsqu'une mise à jour de la table est effectué sur un abonné, alors les événements <command>SYNC</command> vont échouer, puisque le fournisseur indiquera une <quote>nouvelle</quote> colonne alors que l'abonné connait toujours les <quote>anciennes</quote>. Dès que l'on appliquera la modification de la clef chez l'abonné, les évenements
-<command>SYNC</command> seront retraités et le <quote>nouveau</quote> nom de colonne sera présent et tout fonctionnera sans plantage .
-</para> </answer></qandaentry>
+ <para>
+ Toutefois, ce n'est pas forcément nécessaire. Tant que la modification
+ est appliquée sur le nœud origine avant d'être effectuée sur les
+ abonnés, il n'y aura pas de cassure irrémédiable. Certains évènements
+ <command>SYNC</command> qui n'incluent pas la table sur laquelle il y
+ a la modification, pourront fonctionner sans problème... Par contre,
+ lorsqu'une mise à jour de la table est effectuée sur un abonné, alors
+ les événements <command>SYNC</command> vont échouer puisque le
+ fournisseur indiquera une <quote>nouvelle</quote> colonne alors que
+ l'abonné connait toujours les <quote>anciennes</quote>. Dès que l'on
+ appliquera la modification de la clef chez l'abonné, les événements
+ <command>SYNC</command> seront traités de nouveau et le
+ <quote>nouveau</quote> nom de colonne sera présent. Tout fonctionnera
+ sans problème.
+ </para>
+ </answer>
+ </qandaentry>
-<qandaentry id="v72upgrade">
-<question> <para> J'ai un &postgres; version 7.2 et je souhaite
-<emphasis>vraiment</emphasis> utiliser &slony1; le migrer en
-version 8.0. Que faut-il faire pour que &slony1; fonctionne ?</para>
-</question>
+ <qandaentry id="v72upgrade">
+ <question>
+ <para>
+ J'ai un &postgres; version 7.2 et je souhaite
+ <emphasis>vraiment</emphasis> utiliser &slony1; pour le migrer en
+ version 8.0. Que faut-il faire pour que &slony1; fonctionne ?
+ </para>
+ </question>
-<answer> <para> Voici Rod Taylor écrit sur le sujet ...
-</para>
+ <answer>
+ <para>
+ Voici Rod Taylor écrit sur le sujet...
+ </para>
-<para> Voici ce dont approximativement vous avez besoin:</para>
-<itemizedlist>
-<listitem><para>Prendre les templates 7.3 et de les copier en 7.2 -- ou bien écrire en dur la version de vos templates </para></listitem>
-<listitem><para>Supprimer toute trace de schémas dans le code sql de vos templates. Concrètement j'ai remplacé les "." par "-". </para></listitem>
-<listitem><para> Pas mal de travaux sur les types et fonctins XID.
-Par exemple, Slony crée des CASTs pour la conversion xid vers xxid et vice versa -- mais la 7.2 ne peut pas créer de nouveaux casts et dans ce cas vous êtes obligé de le modifier à la main.
-Je me rappelle avoir créé une classe d'opérateur et modifié certaines fonctions. </para></listitem>
-<listitem><para>sl_log_1 aura de graves problèmes de performance quelque soit le volume de données. Ceci exige qu'un certain nombre d'index soient positionnés pour optimiser les interrogations en 7.2, 7.3 et supérieur. </para></listitem>
-<listitem><para> Ne pas s'embeter à essayer de faire fonctionner les séquences. Faites les à la main en utilisant pg_dump et grep. </para></listitem>
-</itemizedlist>
-<para> Bien sûr, une fois que ces pre-requis terminés, on n'est pas encore compatible avec le Slony standard. Ainsi ou bien, vous devez au moins modifier la version 7.2 de manière moins artisanale
-, ou vous modifiez slony pour qu'il fonctionne sans les schémas avec les nouvelles versions de &postgres; afin qu'ils puissent
-dialoguer.
-</para>
-<para> Juste après le déroulement de la procédure de migration de 7.2 vers 7.4,
-on peut désinstaller la version bidouillée de Slony (à la main encore pour la majeure partie), et démarrer la migration
-de 7.2 à 7.4 sur les différentes machines en utilisant un Slony standard. Ceci afin de s'assurer qu'on ne conserve pas les catalogues systèmes qui ont subi des changements manuels.
-</para>
+ <para>
+ Voici approximativement ce dont vous avez besoin :
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Prendre les templates 7.3 et les copier en 7.2 -- ou bien écrire
+ en dur la version de vos templates
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Supprimer toute trace de schémas dans le code SQL de vos templates.
+ Concrètement, j'ai remplacé les points par des tirets.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Pas mal de travaux sur les types et fonctions XID. Par exemple,
+ Slony crée des conversions pour la conversion xid vers xxid et
+ vice versa -- mais la 7.2 ne peut pas créer de nouvelles conversions
+ et dans ce cas vous êtes obligé de le modifier à la main. Je me
+ rappelle avoir créé une classe d'opérateur et modifié certaines
+ fonctions.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ sl_log_1 aura de graves problèmes de performance quelque soit le
+ volume des données. Ceci exige qu'un certain nombre d'index soient
+ positionnés pour optimiser les interrogations en 7.2, 7.3 et
+ supérieur.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Ne pas s'embêter à essayer de faire fonctionner les séquences.
+ Faites-les à la main en utilisant pg_dump et grep.
+ </para>
+ </listitem>
+
+ </itemizedlist>
-<para> Ceci étant dit, nous avons migré quelques centaines de Go de données,
-de 7.2 à 7.4 avec une coupure de service de 30 minutes. (contre 48 heures de dump/restore) et sans pertes de données.
-</para>
-</answer>
+ <para>
+ Bien sûr, une fois ces pre-requis terminés, on n'est pas encore
+ compatible avec le Slony standard. Ainsi soit vous devez au moins
+ modifier la version 7.2 de manière moins artisanale soit vous devez
+ modifier slony pour qu'il fonctionne sans les schémas avec les
+ nouvelles versions de &postgres; afin qu'ils puissent dialoguer.
+ </para>
+
+ <para>
+ Juste après le déroulement de la procédure de migration de 7.2 vers
+ 7.4, on peut désinstaller la version bidouillée de Slony (à la main
+ encore pour la majeure partie), et démarrer la migration de 7.2 à
+ 7.4 sur les différentes machines en utilisant un Slony standard.
+ Ceci afin de s'assurer qu'on ne conserve pas les catalogues systèmes
+ qui ont subi des changements manuels.
+ </para>
-<answer> <para> Ceci vous dresse un éventail assez laid des
-<quote>bidouilles</quote> qu'il faut faire entrer dans le périmètre de production.
-Si quelqu'un est intéressé pour
-<quote>industrialiser</quote> cette tache, il vaut mieux s'appuyer sur
-&slony1; en version 1.0, avec un maître mot de ne
-<emphasis>pas</emphasis> essayer de le rendre pérenne, étant donnée sa durée de vie limitée.</para>
+ <para>
+ Ceci étant dit, nous avons migré quelques centaines de Go de données,
+ de 7.2 à 7.4 avec une coupure de service de 30 minutes (contre 48
+ heures de sauvegarde/restauration) et sans pertes de données.
+ </para>
+ </answer>
-<para> Vous devriez seulement adapter cette solution que si vous êtes à l'aise avec
-&postgres; et &slony1; et si mettre la main au code ne vous fait pas peur. </para> </answer>
-</qandaentry>
+ <answer>
+ <para>
+ Ceci vous dresse un éventail assez laid des <quote>bidouilles</quote>
+ qu'il faut faire entrer dans le périmètre de production. Si quelqu'un
+ est intéressé pour <quote>industrialiser</quote> cette tache, il vaut
+ mieux s'appuyer sur &slony1; en version 1.0, avec un maître mot de ne
+ <emphasis>pas</emphasis> essayer de le rendre pérenne, étant donnée sa
+ durée de vie limitée.
+ </para>
-<qandaentry>
-<question> <para> J'ai subit une <quote>avarie réseau</quote> qui m'a obligé à utiliser
- <xref linkend="stmtfailover"/> pour basculer sur un noeud secondaire.
-Le plantage n'était pas causé par un problème de corruption de donnée venant du disque,
-Pourquoi serais-je obligé de reconstruire le noeud planté ? </para></question>
+ <para>
+ Vous devriez seulement adapter cette solution que si vous êtes à l'aise
+ avec &postgres; et &slony1; et si mettre la main dans le code ne vous
+ fait pas peur.
+ </para>
+ </answer>
+ </qandaentry>
-<answer><para> Le rôle de <xref linkend="stmtfailover"/> est d'
-<emphasis>abandonner</emphasis> le noeud planté, et par conséquence il n'a plus de
-charge générée par l'activité de &slony1;. Plus le temps passe plus le serveur planté se désynchronise.</para></answer>
+ <qandaentry>
+ <question>
+ <para>
+ J'ai subit une <quote>avarie réseau</quote> qui m'a obligé à utiliser
+ <xref linkend="stmtfailover"/> pour basculer sur un nœud
+ secondaire. Le plantage n'était pas causé par un problème de corruption
+ de données venant du disque. Pourquoi serais-je obligé de reconstruire
+ le nœud qui s'est arrêté brutalement&nbsop;?
+ </para>
+ </question>
-<answer><para> L'<emphasis>énorme</emphasis> problème pour restaurer le serveur planté,
-est qu'il peut contenir des mises à jours qui n'ont pas eu le temps de se propager en dehors.
-Vous ne pouvez pas non plus les rejouer, car elles vont être conflictuelles, car à moitié en place.
-En tout cas vous avez une sorte de corruption <quote>logique</quote>de donnée, qui n'est jamais causée par une erreur disque.
+ <answer>
+ <para>
+ Le rôle de <xref linkend="stmtfailover"/> est
+ d'<emphasis>abandonner</emphasis> le nœud arrêté brutalement et,
+ par conséquence il n'a plus de charge générée par l'activité de
+ &slony1;. Plus le temps passe plus, le serveur arrêté brutalement se
+ désynchronise.
+ </para>
+ </answer>
+
+<answer><para> L'<emphasis>énorme</emphasis> problème pour restaurer le serveur planté,
+est qu'il peut contenir des mises à jours qui n'ont pas eu le temps de se propager en dehors.
+Vous ne pouvez pas non plus les rejouer, car elles vont être conflictuelles, car à moitié en place.
+En tout cas vous avez une sorte de corruption <quote>logique</quote>de donnée, qui n'est jamais causée par une erreur disque.
dite <quote>physique.</quote>
</para></answer>
-<answer><para> Comme cela a été abordé dans la section <xref linkend="failover"/>, <xref
-linkend="stmtfailover"/> doit être utilisé en <emphasis>dernier
-recourt</emphasis> car cela implique d'abandonner le noeud d'origine pour cette corruption.</para></answer>
+<answer><para> Comme cela a été abordé dans la section <xref linkend="failover"/>, <xref
+linkend="stmtfailover"/> doit être utilisé en <emphasis>dernier
+recourt</emphasis> car cela implique d'abandonner le nœud d'origine pour cette corruption.</para></answer>
</qandaentry>
-<qandaentry> <question><para> Après notification d'un abonnement sur un
-<emphasis>autre</emphasis> noeud, la réplication échoue sur l'un des abonnés, avec le message d'erreur suivant:</para>
+<qandaentry> <question><para> Après notification d'un abonnement sur un
+<emphasis>autre</emphasis> nœud, la réplication échoue sur l'un des abonnés, avec le message d'erreur suivant:</para>
<screen>
ERROR remoteWorkerThread_1: "begin transaction; set transaction isolation level serializable; lock table "_livesystem".sl_config_lock; select "_livesystem".enableSubscription(25506, 1, 501); notify "_livesystem_Event"; notify "_livesystem_Confirm"; insert into "_livesystem".sl_event (ev_origin, ev_seqno, ev_timestamp, ev_minxid, ev_maxxid, ev_xip, ev_type , ev_data1, ev_data2, ev_data3, ev_data4 ) values ('1', '4896546', '2005-01-23 16:08:55.037395', '1745281261', '1745281262', '', 'ENABLE_SUBSCRIPTION', '25506', '1', '501', 't'); insert into "_livesystem".sl_confirm (con_origin, con_received, con_seqno, con_timestamp) values (1, 4, '4896546', CURRENT_TIMESTAMP); commit transaction;" PGRES_FATAL_ERROR ERROR: insert or update on table "sl_subscribe" violates foreign key constraint "sl_subscribe-sl_path-ref"
DETAIL: Key (sub_provider,sub_receiver)=(1,501) is not present in table "sl_path".
</screen>
-<para> Par la suite l'erreur est suivie par un ensemble de SYNCs en échec
-tandis que <xref linkend="slon"/> s'arrête :</para>
+<para> Par la suite l'erreur est suivie par un ensemble de SYNCs en échec
+tandis que <xref linkend="slon"/> s'arrête :</para>
<screen>
DEBUG2 remoteListenThread_1: queue event 1,4897517 SYNC
@@ -747,16 +1624,16 @@
</question>
-<answer><para> Si vous constatez qu'un &lslon; s'arrête et que le jounal de log indique que
-des événements ont été ignorés, vous devez remonter dans le journal
+<answer><para> Si vous constatez qu'un &lslon; s'arrête et que le jounal de log indique que
+des événements ont été ignorés, vous devez remonter dans le journal
<emphasis>avant</emphasis> que ces erreurs apparaissent, pour trouver des indications
-sur l'origine du problème.</para></answer>
+sur l'origine du problème.</para></answer>
-<answer><para> Dans ce cas particulier, l'erreur est due à la commande
-<xref linkend="stmtstorepath"/> qui n'est pas encore répercutée sur le noeud 4 en attendant la propagation
+<answer><para> Dans ce cas particulier, l'erreur est due à la commande
+<xref linkend="stmtstorepath"/> qui n'est pas encore répercutée sur le nœud 4 en attendant la propagation
de <xref linkend="stmtsubscribeset"/> command</para>
-<para>Cet exemple démontre à nouveau qu'il ne faut pas se précipiter;
+<para>Cet exemple démontre à nouveau qu'il ne faut pas se précipiter;
vous devez vous assurer que tout fonctionne correctement
<emphasis>avant</emphasis> de poursuivre les changements de configuration.
</para></answer>
@@ -765,25 +1642,25 @@
<qandaentry>
-<question><para>J'ai juste utilisé <xref linkend="stmtmoveset"/> afin de déporter le noeud d'origine sur
-un nouveau serveur. Malheureusement certains abonnés sont toujours attachés à l'ancien noeud que je viens de migrer,
-or je ne peux les mettre hors service tant qu'il n'ont pas reçu le signalement de ce changement.
+<question><para>J'ai juste utilisé <xref linkend="stmtmoveset"/> afin de déporter le nœud d'origine sur
+un nouveau serveur. Malheureusement certains abonnés sont toujours attachés à l'ancien nœud que je viens de migrer,
+or je ne peux les mettre hors service tant qu'il n'ont pas reçu le signalement de ce changement.
Que puis-je faire? </para></question>
<answer><para> Vous avez besoin d'utiliser <xref linkend="stmtsubscribeset"/> afin de modifier les abonnements
- de ces serveurs abonnés et les réorienter vers un fournisseur qui <emphasis>sera</emphasis> disponible durant la période de maintenance.</para>
+ de ces serveurs abonnés et les réorienter vers un fournisseur qui <emphasis>sera</emphasis> disponible durant la période de maintenance.</para>
<warning> <para> Il <emphasis>ne faut pas</emphasis> faire <xref
-linkend="stmtunsubscribeset"/>; car vous seriez obligé de
-recharger toutes les données à partir de zéro.
+linkend="stmtunsubscribeset"/>; car vous seriez obligé de
+recharger toutes les données à partir de zéro.
</para></warning>
</answer>
</qandaentry>
<qandaentry>
-<question><para> Après la notification d'un abonnement auprès
-<emphasis>d'un autre</emphasis> serveur fournisseur, la réplication tombe en panne, et affiche des messages d'erreurs
+<question><para> Après la notification d'un abonnement auprès
+<emphasis>d'un autre</emphasis> serveur fournisseur, la réplication tombe en panne, et affiche des messages d'erreurs
du type :</para>
<screen>
@@ -791,8 +1668,8 @@
DETAIL: Key (sub_provider,sub_receiver)=(1,501) is not present in table "sl_path".
</screen>
-<para> Ceci est suivi plus tard par une série d'erreur de syncs tandis que le <xref
-linkend="slon"/> s'arrête :
+<para> Ceci est suivi plus tard par une série d'erreur de syncs tandis que le <xref
+linkend="slon"/> s'arrête :
<screen>
DEBUG2 remoteListenThread_1: queue event 1,4897517 SYNC
@@ -809,47 +1686,47 @@
</para></question>
-<answer><para> Si vous constatez qu'un &lslon; s'arrête et que le jounal de log indique que
-des événements ont été ignorés, vous devez remonter dans le journal
+<answer><para> Si vous constatez qu'un &lslon; s'arrête et que le jounal de log indique que
+des événements ont été ignorés, vous devez remonter dans le journal
<emphasis>avant</emphasis> que ces erreurs apparaissent, pour trouver des indications
-sur l'origine du problème.</para></answer>
+sur l'origine du problème.</para></answer>
-<answer><para> Dans ce cas particulier, le problème était que certaines commandes
- <xref linkend="stmtstorepath"/> n'ont pas été transmises aux noeud 4 avant que
-le commande <xref linkend="stmtsubscribeset"/> ne soit propagée. </para>
+<answer><para> Dans ce cas particulier, le problème était que certaines commandes
+ <xref linkend="stmtstorepath"/> n'ont pas été transmises aux nœud 4 avant que
+le commande <xref linkend="stmtsubscribeset"/> ne soit propagée. </para>
-<para>C'est encore un exemple où il ne faut pas hâtivement modifier les choses
-; vous devez être sur que tout fonctionne bien
+<para>C'est encore un exemple où il ne faut pas hâtivement modifier les choses
+; vous devez être sur que tout fonctionne bien
<emphasis>avant</emphasis> de faire de nouveau changement de configuration.
</para></answer>
</qandaentry>
<qandaentry>
-<question> <para> Est-ce que l'ordre dans une ensemble de réplication est important ?</para>
+<question> <para> Est-ce que l'ordre dans une ensemble de réplication est important ?</para>
</question>
<answer> <para> La plupart de temps il ne l'est pas. On pourrait imaginer qu'il faille
-déclarer les tables <quote>mères</quote> avant leurs <quote>filles</quote>
-en fonction des relations de clefs étrangères qui les relient;
-mais ce n'est <emphasis>pas nécessaire</emphasis> si sur le noeud abonné,
-on a pris le soin, de désactiver les déclencheurs.
+déclarer les tables <quote>mères</quote> avant leurs <quote>filles</quote>
+en fonction des relations de clefs étrangères qui les relient;
+mais ce n'est <emphasis>pas nécessaire</emphasis> si sur le nœud abonné,
+on a pris le soin, de désactiver les déclencheurs.
</para>
</answer>
<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 interbloqués ("deadlock") et par conséquent faire tomber l'application ou bien
+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 interbloqués ("deadlock") et par conséquent faire tomber l'application ou bien
<application>slon</application>.
</para>
-<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.
+<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
+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>
@@ -858,11 +1735,11 @@
<qandaentry>
-<question><para> Si votre script <xref linkend="slonik"/> ressemble à quelque chose à celui ci-dessous,
+<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 ne jamais avoir lieu
+<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 ne jamais avoir lieu
dans le scope de la transaction.</para>
<programlisting>
@@ -884,25 +1761,25 @@
</programlisting></question>
<answer><para> Vous ne devez pas invoquer<xref linkend="stmtwaitevent"/>
-à l'intérieur d'un bloc <quote>try</quote>.</para></answer>
+à l'intérieur d'un bloc <quote>try</quote>.</para></answer>
</qandaentry>
<qandaentry>
<question><para>Slony-I: cannot add table to currently subscribed set 1</para>
-<para> J'ai essayé de rajouter une table à un jeu d'ensemble et j'ai le message
+<para> J'ai essayé de rajouter une table à un jeu d'ensemble et j'ai le message
d'erreur suivant :
<screen>
Slony-I: cannot add table to currently subscribed set 1
</screen></para></question>
-<answer><para> Vous ne pouvez pas rajouter des tables à un ensemble pour lequel il y a des abonnées.
+<answer><para> Vous ne pouvez pas rajouter des tables à un ensemble pour lequel il y a des abonnées.
</para>
-<para>Le contournement est de créer un <emphasis>AUTRE</emphasis>
-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
+<para>Le contournement est de créer un <emphasis>AUTRE</emphasis>
+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>
@@ -910,7 +1787,7 @@
<question><para>
ERROR: duplicate key violates unique constraint "sl_table-pkey"</para>
-<para>En essayant de monter un deuxième ensemble de réplication, j'ai ce message :
+<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,43 +1795,43 @@
CONTEXT: PL/pgSQL function "setaddtable_int" line 71 at SQL statement
</screen></para></question>
-<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.
+<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>
<qandaentry>
-<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,
+<question><para> L'un de mes nœudss 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 nœud, il tourne durant cinq minutes, puis s'arrête,
avec l'erreur suivante : <command>ERROR: remoteListenThread_%d: timeout
-for event selection</command> Quel est le problème ? Que faire ? </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, 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,
+<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, lorsqu'il tente
+de déterminer quel est l'évènement à reprendre sur ce nœud. 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érieures à 1.1.7, 1.2.7, et à 1.3, serait de dire
-d'augmenter le délai d'expiration dans
+<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>
-<answer><para> Une autre réponse serait de conseiller de reconstruire entièrement le noeud ayant échoué,
-à l'aide de la commande &lslonik; <xref linkend="stmtdropnode"/> en le supprimant d'abord et le recréer après.
-Si les mises à jours sont volumineuses côté base de données, il vaut mieux reconstruir plutôt que d'essayer de rattraper.
+<answer><para> Une autre réponse serait de conseiller de reconstruire entièrement le nœud ayant échoué,
+à l'aide de la commande &lslonik; <xref linkend="stmtdropnode"/> en le supprimant d'abord et le recréer après.
+Si les mises à jours sont volumineuses côté base de données, il vaut mieux reconstruir plutôt que d'essayer de rattraper.
</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
-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>
+<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
+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 nœud, que d'essayer de rattraper les mises à jours. </para> </answer>
</qandaentry>
@@ -962,35 +1839,35 @@
-<qandadiv id="faqperformance"> <title> &slony1; FAQ: Problèmes de Performances </title>
+<qandadiv id="faqperformance"> <title> &slony1; FAQ: Problèmes de Performances </title>
<qandaentry id="longtxnsareevil">
-<question><para> La réplication ralentit, je vois des requêtes <command> FETCH 100 FROM LOG </command> très longues , la table <xref linkend="table.sl-log-1"/> grossit, et les performances se dégradent de manière continue. </para>
+<question><para> La réplication ralentit, je vois des requêtes <command> FETCH 100 FROM LOG </command> très longues , la table &sllog1;/&sllog2; grossit, et les performances se dégradent de manière continue. </para>
</question>
<answer> <para> Il y a beaucoup de causes possibles pour ce genre de choses.
-Il s'agit de même genre de pathologies qui entrainent l'augmentation du volume dans
+Il s'agit de même genre de pathologies qui entrainent l'augmentation du volume dans
<link linkend="pglistenerfull">
-&pglistener; lorsque la purge via vacuum n'est pas exécutée.</link>
+&pglistener; lorsque la purge via vacuum n'est pas exécutée.</link>
</para>
<para> Par rapprochement <quote> on peut avancer </quote>, que cette augmentation de volume,
-est due à une session existante sur le serveur rend le noeud
+est due à une session existante sur le serveur rend le nœud
<command>
-IDLE IN TRANSACTION </command> pour une durée très longue. </para>
+IDLE IN TRANSACTION </command> pour une durée très longue. </para>
-<para> Cette transaction ouverte peut avoir de multiples effets négatifs,
-chacun entrainant une dégradation de performances.</para>
+<para> Cette transaction ouverte peut avoir de multiples effets négatifs,
+chacun entrainant une dégradation de performances.</para>
<itemizedlist>
-<listitem><para> Le fait de lancer un Vacuum sur la totalité des tables,
-&pglistener; y compris, ne va pas nettoyer les tuples morts après après le début de la transaction en attente. </para> </listitem>
+<listitem><para> Le fait de lancer un Vacuum sur la totalité des tables,
+&pglistener; y compris, ne va pas nettoyer les tuples morts après après le début de la transaction en attente. </para> </listitem>
-<listitem><para> Le processus de nettoyage ne pourra pas se supprimer les entrées dans <xref linkend="table.sl-log-1"/> et <xref
-linkend="table.sl-seqlog"/>, qui entraîne par conséquence, une croissance
+<listitem><para> Le processus de nettoyage ne pourra pas se supprimer les entrées dans &sllog1;, &sllog2;
+et &slseqlog;, qui entraîne par conséquence, une croissance
de volume tant que la transaction persiste. </para>
</listitem>
</itemizedlist>
@@ -998,47 +1875,47 @@
<answer> <para> Vous pouvez surveiller cette situation, uniquement si
dans le fichier de configuration de &postgres; <filename> postgresql.conf </filename>
-le paramètre <envar>stats_command_string</envar> est positionner à vrai.
-Dans ce cas, vous pouvez lancer une intérrogation sql comme suit :
+le paramètre <envar>stats_command_string</envar> est positionner à vrai.
+Dans ce cas, vous pouvez lancer une intérrogation sql comme suit :
<command> select * from pg_stat_activity where current_query like '%IDLE% in transaction';
-</command> dont le résultat vous donnent les transactions en activités. </para> </answer>
+</command> dont le résultat vous donnent les transactions en activités. </para> </answer>
-<answer> <para> Vous pouvez également rechercher
+<answer> <para> Vous pouvez également rechercher
les <quote> idle in transaction </quote> dans la table des processes
-ceux qui détiennent encore des transactions anciennes.
+ceux qui détiennent encore des transactions anciennes.
</para> </answer>
-<answer> <para> Il est aussi possible (quoique plus rare) que le problème soit causé par
-une transaction, qui pour d'autres raisons, est conservée comme ouverte et ceci pour une longue durée.
+<answer> <para> Il est aussi possible (quoique plus rare) que le problème soit causé par
+une transaction, qui pour d'autres raisons, est conservée comme ouverte et ceci pour une longue durée.
La valeur <envar> query_start </envar> dans la table <envar>
-pg_stat_activity </envar> vous présentra les longues requêtes qui s'exécutent depuis longtemps. </para> </answer>
+pg_stat_activity </envar> vous présentra les longues requêtes qui s'exécutent depuis longtemps. </para> </answer>
-<answer> <para> Il est prévu que &postgres; ait un paramètre d'expiration de
-délai, <envar> open_idle_transaction_timeout </envar>, qui permettrait de venir à bout des transactions après une certaine période.
+<answer> <para> Il est prévu que &postgres; ait un paramètre d'expiration de
+délai, <envar> open_idle_transaction_timeout </envar>, qui permettrait de venir à bout des transactions après une certaine période.
-Les pool de connexions peuvent engendrer ce genre de situation d'erreurs. Il est prévu des amélioration où <productname> <link linkend="pgpool"> pgpool
-</link> </productname> devrait présenter des meilleurs alternatives afin de mieux gérer les connexions partagées.
-Il existe des pools de connexions plus ou moins buggués dans les applications
+Les pool de connexions peuvent engendrer ce genre de situation d'erreurs. Il est prévu des amélioration où <productname> <link linkend="pgpool"> pgpool
+</link> </productname> devrait présenter des meilleurs alternatives afin de mieux gérer les connexions partagées.
+Il existe des pools de connexions plus ou moins buggués dans les applications
Java ou PHP;si un nombre restreint de <emphasis> vrai </emphasis>
-connections sont conservées dans<productname>pgpool</productname>, ceci va faire croire à la base,
-qu'en réalité les connexions de l'application reste dans un statut disponible et en activité, pendant des heures.
+connections sont conservées dans<productname>pgpool</productname>, ceci va faire croire à la base,
+qu'en réalité les connexions de l'application reste dans un statut disponible et en activité, pendant des heures.
</para> </answer>
</qandaentry>
<qandaentry id="faq17">
-<question><para>Après une suppression de noeud, la table <xref linkend="table.sl-log-1"/>
-n'est plus purgée.</para></question>
+<question><para>Après une suppression de nœud, les tables &sllog1;/&sllog2;
+ne sont plus purgées.</para></question>
-<answer><para> Ceci est un scénario commun dans les versions d'avant 1.0.5, en effet
-le <quote>nettoyage</quote> du noeud oublie les vieilles entrées de la table <xref linkend="table.sl-confirm"/>, pour le serveur qui vient de disparaître.</para>
+<answer><para> Ceci est un scénario commun dans les versions d'avant 1.0.5, en effet
+le <quote>nettoyage</quote> du nœud oublie les vieilles entrées de la table <xref linkend="table.sl-confirm"/>, pour le serveur qui vient de disparaître.</para>
-<para> Le noeud n'est plus présent et n'envoie plus les confirmations annonçant les syncs qui viennent de s'effectuer sur ce serveur,
-et le processus de nettoyage estime qu'il ne peut supprimer sans risque les entrées plus récentes
-que la dernière entrée de la <xref linkend="table.sl-confirm"/> , ce qui limite nettement la capacité de purge des anciens journaux.</para>
+<para> Le nœud n'est plus présent et n'envoie plus les confirmations annonçant les syncs qui viennent de s'effectuer sur ce serveur,
+et le processus de nettoyage estime qu'il ne peut supprimer sans risque les entrées plus récentes
+que la dernière entrée de la <xref linkend="table.sl-confirm"/> , ce qui limite nettement la capacité de purge des anciens journaux.</para>
-<para>Diagnostics: Exécuter les requêtes suivantes pour voir si il y a
-un résidus d'entrées en état <quote>fantôme/obsolète/bloqué</quote> dans la table <xref
+<para>Diagnostics: Exécuter les requêtes suivantes pour voir si il y a
+un résidus d'entrées en état <quote>fantôme/obsolète/bloqué</quote> dans la table <xref
linkend="table.sl-confirm"/>:
<screen>
@@ -1055,64 +1932,65 @@
</screen></para>
<para>Dans la version 1.0.5, la fonction <xref linkend="stmtdropnode"/>
-purges les données dans <xref linkend="table.sl-confirm"/> pour le noeud qui quitte la configuration.
-Dans les versions plus anciennes, il faut faire cela à la main. Supposons que l'identifiant du noeud soit 3, alors la requête serait la suivante :
+purges les données dans <xref linkend="table.sl-confirm"/> pour le nœud qui quitte la configuration.
+Dans les versions plus anciennes, il faut faire cela à la main. Supposons que l'identifiant du nœud soit 3, alors la requête serait la suivante :
<screen>
delete from _namespace.sl_confirm where con_origin = 3 or con_received = 3;
</screen></para>
-<para>Sinon, pour chasser <quote>tous les fantômes,</quote> vous pouvez utiliser
+<para>Sinon, pour chasser <quote>tous les fantômes,</quote> vous pouvez utiliser
<screen>
oxrsbar=# delete from _oxrsbar.sl_confirm where con_origin not in (select no_id from _oxrsbar.sl_node) or con_received not in (select no_id from _oxrsbar.sl_node);
DELETE 6
</screen></para>
<para>Une <quote>raisonnable diligence</quote> dicterait de commencer par
-<command>BEGIN</command> et vérifier le contenu des <command>SYNC</command> dans la table <xref linkend="table.sl-confirm"/> avant de les purger, puis de valider l'opération par un <command>COMMIT</command>. Si
-vous supprimer par erreur les données d'un autre noeud, votre journée est perdue le temps de rattraper l'erreur commise.</para>
+<command>BEGIN</command> et vérifier le contenu des <command>SYNC</command> dans la table <xref linkend="table.sl-confirm"/> avant de les purger, puis de valider l'opération par un <command>COMMIT</command>. Si
+vous supprimer par erreur les données d'un autre nœud, votre journée est perdue le temps de rattraper l'erreur commise.</para>
-<para>Vous aurez besoin d'exécuter cette opération, sur chaque noeud qui reste...</para>
+<para>Vous aurez besoin d'exécuter cette opération, sur chaque nœud qui reste...</para>
-<para>A noter qu'à partir de la version 1.0.5, ce n'est plus un problème, car il purge les entrées inutiles
-de <xref linkend="table.sl-confirm"/> Ã deux instants :
+<para>A noter qu'à partir de la version 1.0.5, ce n'est plus un problème, car il purge les entrées inutiles
+de <xref linkend="table.sl-confirm"/> à deux instants :
<itemizedlist>
-<listitem><para> Lorsque un noeud est supprimé</para></listitem>
+<listitem><para> Lorsque un nœud est supprimé</para></listitem>
-<listitem><para> Au démarrage de chaque
-<function>cleanupEvent</function>, qui est l'évènement qui purge les vieilles données de
-<xref linkend="table.sl-log-1"/> et de <xref
-linkend="table.sl-seqlog"/></para></listitem> </itemizedlist></para>
+<listitem><para> Au démarrage de chaque
+<function>cleanupEvent</function>, qui est l'évènement qui purge les vieilles données de
+&sllog1;/&sllog2; et de &slseqlog;</para></listitem> </itemizedlist></para>
</answer>
</qandaentry>
<qandaentry>
-<question><para>Le <application>slon</application> était éteint ce week-end , et désormais il lui faut énormément de temps pour exécuter un
+<question><para>Le <application>slon</application> était éteint ce week-end , et désormais il lui faut énormément de temps pour exécuter un
sync.</para></question>
-<answer><para> Jetez un coup d'oeil, sur les tables <xref
-linkend="table.sl-log-1"/>/<xref linkend="table.sl-log-2"/>,
- pour voir brièvement si il y a une énorme transaction
-en cours d'exécution. Jusqu'à la version 1.0.2, il faut qu'il y ait un
-&lslon; connecté au noeud origine pour que les événements <command>SYNC</command> soient générés.</para>
+<answer><para> Jetez un coup d'oeil, sur les tables &sllog1;/&sllog2;,
+ pour voir brièvement si il y a une énorme transaction
+en cours d'exécution. Jusqu'à la version 1.0.2, il faut qu'il y ait un
+&lslon; connecté au nœud origine pour que les événements <command>SYNC</command> soient générés.</para>
-<para>Si aucun évènement n'est généré, alors toute les mises à jour jusqu'au prochain évènement seront aggrégées dans une énorme transaction &slony1;.</para>
+<note><para>À partir de la version 1.0.2, la fonction
+<function>generate_sync_event()</function> fournit une alternative à la sauvegarde...</para> </note>
-<para>Conclusion: Même si il n'y a pas d'abonné dans votre réplication,
+<para>Si aucun évènement n'est généré, alors toute les mises à jour jusqu'au prochain évènement seront aggrégées dans une énorme transaction &slony1;.</para>
+
+<para>Conclusion: Même si il n'y a pas d'abonné dans votre réplication,
vous avez <emphasis>vraiment</emphasis> mettre en place un
-<application>slon</application> pour qu'il se connecte au noeud origine.</para>
+<application>slon</application> pour qu'il se connecte au nœud origine.</para>
-<para>&slony1; 1.1 fournit une procédure stockée qui permet aux SYNCs d'être
-mis à jour par le planificateur <application>cron</application>même si <xref
-linkend="slon"/> ne tourne pas en tâche de fond.</para> </answer></qandaentry>
+<para>&slony1; 1.1 fournit une procédure stockée qui permet aux SYNCs d'être
+mis à jour par le planificateur <application>cron</application>même si <xref
+linkend="slon"/> ne tourne pas en tâche de fond.</para> </answer></qandaentry>
<qandaentry id="pglistenerfull">
-<question><para>Quelques noeuds commencent à se ralentir constamment. </para>
+<question><para>Quelques nœuds commencent à se ralentir constamment. </para>
-<para>J'avais lancé, depuis un moment, &slony1; sur un noeud, et je vois que la machine est Ã
+<para>J'avais lancé, depuis un moment, &slony1; sur un nœud, et je vois que la machine est à
genoux.</para>
<para>Je vois des instructions en cours comme :
@@ -1120,61 +1998,61 @@
fetch 100 from LOG;
</screen></para></question>
-<answer><para> Typiquement ceci peut se produire lorsque &pglistener; (la table qui contient les données de
+<answer><para> Typiquement ceci peut se produire lorsque &pglistener; (la table qui contient les données de
<command>NOTIFY</command>) est rempplie de tuple morts.
-Ce qui fait que les évènements <command>NOTIFY</command> prend du temps,
-et cause le ralentissement de plus en plus fort du noeud affecté.</para>
+Ce qui fait que les évènements <command>NOTIFY</command> prend du temps,
+et cause le ralentissement de plus en plus fort du nœud affecté.</para>
<para>Vous avez probablement besoin d'effectuer un <command>VACUUM FULL</command> sur
&pglistener;, pour le nettoyer vigoureusement, puis d'effectuer un vacuum simple sur
-&pglistener; vraiment fréquemment. Une planification tous les cinq minutes fera l'affaire.</para>
+&pglistener; vraiment fréquemment. Une planification tous les cinq minutes fera l'affaire.</para>
-<para> Les démons Slon font déjà un vacuum sur beaucoup de tables ,et
-<filename>cleanup_thread.c</filename> contient une liste de tables à nettoyer fréquemment de manière automatique.
-Dans &slony1; 1.0.2,&pglistener; n'est pas inclus. Dans la version 1.0.5 et supérieure, il est purgé régulièrement,
-du coup ce problème n'a plus le lieu d'être. Dans la version 1.2,
-&pglistener; est seulement utilisé quand le noeud reçoit périodiquement l'évènement,
-ce qui signifie que ce problème la plupart du temps disparaître même
-en présence des transaction longues et lentes...</para>
+<para> Les démons Slon font déjà un vacuum sur beaucoup de tables ,et
+<filename>cleanup_thread.c</filename> contient une liste de tables à nettoyer fréquemment de manière automatique.
+Dans &slony1; 1.0.2,&pglistener; n'est pas inclus. Dans la version 1.0.5 et supérieure, il est purgé régulièrement,
+du coup ce problème n'a plus le lieu d'être. Dans la version 1.2,
+&pglistener; est seulement utilisé quand le nœud reçoit périodiquement l'évènement,
+ce qui signifie que ce problème la plupart du temps disparaître même
+en présence des transaction longues et lentes...</para>
-<para>Il y a, cependant, toujours un scénario où ceci peut
+<para>Il y a, cependant, toujours un scénario où ceci peut
<quote>surgir</quote>. Pour respecter le MVCC, les vacuums ne peuvent pas supprimer des tuples qui sont rendus
-<quote>obsolètes</quote> à n'importe quel moment après le démarrage de la transaction la plus ancienne
-qui reste encore ouverte. Les transactions longues, devront être évitées, car elles sont sources de soucis,
-même sur les noeuds abonnés.</para> </answer></qandaentry>
+<quote>obsolètes</quote> à n'importe quel moment après le démarrage de la transaction la plus ancienne
+qui reste encore ouverte. Les transactions longues, devront être évitées, car elles sont sources de soucis,
+même sur les nœuds abonnés.</para> </answer></qandaentry>
-<qandaentry> <question> <para> J'ai soumis une requête <xref
+<qandaentry> <question> <para> J'ai soumis une requête <xref
linkend="stmtmoveset"/> / <xref linkend="stmtddlscript"/>, et
-elle semble être coincée, sur mon serveur. Les journaux de &slony1; ne montre aucun avertissement et aucune erreur.
+elle semble être coincée, sur mon serveur. Les journaux de &slony1; ne montre aucun avertissement et aucune erreur.
</para> </question>
-<answer> <para> Peut-être que
-<application>pg_autovacuum</application> est en cours d'exécution, et qu'il a posé
-des verrous sur des tables dans l'ensemble de réplication ? Ceci entraine manière silencieuse le blocage de &slony1;
-en l'empêchant d'effectuer les opérations qui exigent l'acquisition des <link
+<answer> <para> Peut-être que
+<application>pg_autovacuum</application> est en cours d'exécution, et qu'il a posé
+des verrous sur des tables dans l'ensemble de réplication ? Ceci entraine manière silencieuse le blocage de &slony1;
+en l'empêchant d'effectuer les opérations qui exigent l'acquisition des <link
linkend="locking"> exclusifs. </link> </para>
-<para> Vous pourriez vérifier la présence de ce genre de verrous à l'aide de cette requête :
+<para> Vous pourriez vérifier la présence de ce genre de verrous à l'aide de cette requête :
<command> select l.*, c.relname from pg_locks l, pg_class c
where c.oid = l.relation ; </command> Un verrou
-<envar>ShareUpdateExclusiveLock</envar> peut bloquer les opérations de &slony1;
-qui nécessitent leurs propres verrous exclusifs, et les mettre en en attentes et marquées comme non-validées. </para>
+<envar>ShareUpdateExclusiveLock</envar> peut bloquer les opérations de &slony1;
+qui nécessitent leurs propres verrous exclusifs, et les mettre en en attentes et marquées comme non-validées. </para>
</answer> </qandaentry>
<qandaentry>
-<question><para> Je remarque que dans les journaux, qu'un &lslon; change d'état fréquemment : <quote>LISTEN - switch from polling mode to use
+<question><para> Je remarque que dans les journaux, qu'un &lslon; change d'état fréquemment : <quote>LISTEN - switch from polling mode to use
LISTEN</quote> et <quote>UNLISTEN - switch into polling
mode</quote>. </para> </question>
-<answer><para> Les seuils pour commuter entre ces modes sont commandés par
-les paramètres de configuration <xref
+<answer><para> Les seuils pour commuter entre ces modes sont commandés par
+les paramètres de configuration <xref
linkend="slon-config-sync-interval"/> et <xref
linkend="slon-config-sync-interval-timeout"/>; si la valeur du temps d'expiration
-(par défaut étant à 10000, impliquant 10s) est maintenu bas, cela encourage le &lslon; à retourner dans l'état <quote>d'écoute</quote>.
+(par défaut étant à 10000, impliquant 10s) est maintenu bas, cela encourage le &lslon; à retourner dans l'état <quote>d'écoute</quote>.
Vous devriez augmenter cette valeur d'expiration de temps. </para>
</answer>
</qandaentry>
@@ -1183,25 +2061,25 @@
</qandadiv>
<qandadiv id="faqbugs"> <title> &slony1; FAQ: &slony1; Bugs dans les versions anciennes</title>
<qandaentry>
-<question><para>Les processus &lslon; gérant mes abonnés devient énorme, mettant en danger la ressource du système en terme de swap ainsi que le risque d'atteindre la taille limite
+<question><para>Les processus &lslon; gérant mes abonnés devient énorme, mettant en danger la ressource du système en terme de swap ainsi que le risque d'atteindre la taille limite
de 2GB par processus . </para>
-<para> D'ailleurs, les données que je suis en train de répliquer,
+<para> D'ailleurs, les données que je suis en train de répliquer,
ont une taille assez grande. Il y a des enregistrements dont la taille
-dépasse des dizaine de megaoctets. Peut-être que c'est lié ? </para> </question>
+dépasse des dizaine de megaoctets. Peut-être que c'est lié ? </para> </question>
-<answer> <para> Oui, ces enregistrements volumineux sont à la racine du problème.
-Le problème vient du fait que &lslon; normalement procède par paquet de
- 100 enregistrements à la fois, lorsqu'un abonné charge des données depuis le fournisseur.
+<answer> <para> Oui, ces enregistrements volumineux sont à la racine du problème.
+Le problème vient du fait que &lslon; normalement procède par paquet de
+ 100 enregistrements à la fois, lorsqu'un abonné charge des données depuis le fournisseur.
Ainsi si la taille moyenne des enregistrements est de
-is 10MB, ceci entraîne des paquets de données atteignant 1000MB qui sont ensuite transformés en
+is 10MB, ceci entraîne des paquets de données atteignant 1000MB qui sont ensuite transformés en
<command>INSERT</command> ou en <command>UPDATE</command>
-dans la mémoire du processus &lslon;.</para>
+dans la mémoire du processus &lslon;.</para>
-<para> Cela mène évidemment &lslon; à des tailles gigantesques. </para>
+<para> Cela mène évidemment &lslon; à des tailles gigantesques. </para>
-<para> Le nombre d'enregistrement regroupés est controllé par la valeur <envar> SLON_DTA_FETCH_SIZE </envar>,
-définie dans le fichier <filename>src/slon/slon.h</filename>. Voici un extrait de ce fichier contenant ce paramètre :
+<para> Le nombre d'enregistrement regroupés est controllé par la valeur <envar> SLON_DTA_FETCH_SIZE </envar>,
+définie dans le fichier <filename>src/slon/slon.h</filename>. Voici un extrait de ce fichier contenant ce paramètre :
</para>
<programlisting>
@@ -1216,74 +2094,74 @@
#endif
</programlisting>
-<para> Si vous rencontrez ce problème, vous devriez définir
- <envar> SLON_DATA_FETCH_SIZE </envar>, peut-être le réduire par un facteur de 10, et recompiler ensuite &lslon;.
+<para> Si vous rencontrez ce problème, vous devriez définir
+ <envar> SLON_DATA_FETCH_SIZE </envar>, peut-être le réduire par un facteur de 10, et recompiler ensuite &lslon;.
L'activation de <envar> SLON_CHECK_CMDTUPLES</envar> permet de faire une surveillance
-supplémentaire pour s'assurer que les abonnés ne sont pas désynchronisés par
-rapport au fournisseur. Par défaut, cette option est désactivée, donc la modification par défaut consiste réduire la seconde définition de
-<envar> SLON_DATA_FETCH_SIZE </envar> en remplaçant 10 par 1. </para> </answer>
+supplémentaire pour s'assurer que les abonnés ne sont pas désynchronisés par
+rapport au fournisseur. Par défaut, cette option est désactivée, donc la modification par défaut consiste réduire la seconde définition de
+<envar> SLON_DATA_FETCH_SIZE </envar> en remplaçant 10 par 1. </para> </answer>
<answer><para> Dans la version 1.2, la configuration des valeurs de<xref
linkend="slon-config-max-rowsize"/> et de <xref
-linkend="slon-config-max-largemem"/> sont associées avec un nouvel algorithme
-qui change la logique des choses. Plutôt que de restituer 100
-enregistrements à la fois :</para>
+linkend="slon-config-max-largemem"/> sont associées avec un nouvel algorithme
+qui change la logique des choses. Plutôt que de restituer 100
+enregistrements à la fois :</para>
<itemizedlist>
<listitem><para> La lecture de <command>fetch from LOG</command> se fera
-par paquet de 500 enregistrements à la fois, tant que la taille n'excède pas
-<xref linkend="slon-config-max-rowsize"/>. Avec les valeurs par défaut, ceci limitera
-ce phénomène de consommation de mémoire à un plafond de 8MB. </para>
+par paquet de 500 enregistrements à la fois, tant que la taille n'excède pas
+<xref linkend="slon-config-max-rowsize"/>. Avec les valeurs par défaut, ceci limitera
+ce phénomène de consommation de mémoire à un plafond de 8MB. </para>
</listitem>
-<listitem><para> Les tuples sont lus jusqu'à ce que la taille n'excède pas
-le paramètre <xref linkend="slon-config-max-largemem"/>. Par défaut, cette restriction
+<listitem><para> Les tuples sont lus jusqu'à ce que la taille n'excède pas
+le paramètre <xref linkend="slon-config-max-largemem"/>. Par défaut, cette restriction
ne consommera pas plus de 5MB. Cette valeur n'est pas un seil de limitation stricte;
-si vous avez des tuples dont la taille est de 50MB, il <emphasis>seront</emphasis> forcément chargé en mémoire. Il n'est pas possible d'éviter cela.
-Mais &lslon; au moins, n'essayera pas de charger, à la fois 100 enregistrements coûte que coûte, dépassant les 10GB de
-mémoire consommée à cet effet.</para> </listitem>
+si vous avez des tuples dont la taille est de 50MB, il <emphasis>seront</emphasis> forcément chargé en mémoire. Il n'est pas possible d'éviter cela.
+Mais &lslon; au moins, n'essayera pas de charger, à la fois 100 enregistrements coûte que coûte, dépassant les 10GB de
+mémoire consommée à cet effet.</para> </listitem>
</itemizedlist>
-<para> Ceci devrait alléger des problèmes que les gens avaient éprouvé, quand ils ont chargés sporadiquement,
-des séries de tuples très volumineux. </para>
+<para> Ceci devrait alléger des problèmes que les gens avaient éprouvé, quand ils ont chargés sporadiquement,
+des séries de tuples très volumineux. </para>
</answer>
</qandaentry>
-<qandaentry id="faqunicode"> <question> <para> Je suis en train de répliquer
-les données de type <envar>UNICODE</envar> depuis la version 8.0 de &postgres; à la version 8.1,
-et je rencontre des problèmes. </para>
+<qandaentry id="faqunicode"> <question> <para> Je suis en train de répliquer
+les données de type <envar>UNICODE</envar> depuis la version 8.0 de &postgres; à la version 8.1,
+et je rencontre des problèmes. </para>
</question>
-<answer> <para> &postgres; 8.1 est un peu plus strict dans l'usage des codes caractères
-UTF-8 et Unicode, comparé à la version 8.0.</para>
+<answer> <para> &postgres; 8.1 est un peu plus strict dans l'usage des codes caractères
+UTF-8 et Unicode, comparé à la version 8.0.</para>
-<para> Si vous êtes amené à utiliser &slony1; pour migrer depuis une plus vieille version vers la version 8.1,
-et que avez de valeur UTF-8 invalide, vous aurez une surprise déplaisante.</para>
+<para> Si vous êtes amené à utiliser &slony1; pour migrer depuis une plus vieille version vers la version 8.1,
+et que avez de valeur UTF-8 invalide, vous aurez une surprise déplaisante.</para>
<para> Supposons que votre version de base est 8.0, avec l'encodage en UTF-8.
-La base va accepter des séquences <command>'\060\242'</command> comme un valeur UTF-8 conforme, même si ce n'est pas le cas. </para>
+La base va accepter des séquences <command>'\060\242'</command> comme un valeur UTF-8 conforme, même si ce n'est pas le cas. </para>
-<para> Si vous répliquez ceci dans des instances de &postgres; en version 8.1, il va se plaindre,
-, soit lors de l'enregistrement d'un abonné, car &slony1; va râler
-à propos des codes caractères invalides qu'il vient de rencontrer durant la COPY des données,
-ce qui empêchera que l'enregistrement se fasse, soit lors de l'ajout de données, plus tard, ce qui brisera irrémédiablement la réplication.
+<para> Si vous répliquez ceci dans des instances de &postgres; en version 8.1, il va se plaindre,
+, soit lors de l'enregistrement d'un abonné, car &slony1; va râler
+à propos des codes caractères invalides qu'il vient de rencontrer durant la COPY des données,
+ce qui empêchera que l'enregistrement se fasse, soit lors de l'ajout de données, plus tard, ce qui brisera irrémédiablement la réplication.
(Vous pouvez tricher sur le contenu de sl_log_1, mais rapidement
-cela deviendra <emphasis>vraiment</emphasis> intéressant...)</para>
+cela deviendra <emphasis>vraiment</emphasis> intéressant...)</para>
-<para>Il y a déjà eu des discussions sur ce sujet pour savoir ce qu'il faudra faire.
-Pour le moment une stratégie attractive ne se dégage pas sur le sujet. </para>
+<para>Il y a déjà eu des discussions sur ce sujet pour savoir ce qu'il faudra faire.
+Pour le moment une stratégie attractive ne se dégage pas sur le sujet. </para>
<para>Si vous utilisez Unicode avec la version 8.0 de &postgres;, vous courrez un risque
-considérable de corrompre vos données. </para>
+considérable de corrompre vos données. </para>
-<para> Si votre réplication a pour but de convertir une fois pour toutes vos données,
-il y a le risque évoqué ci-dessus; si cela vous arrive, il voudra mieux de convertir vos données de la version 8.0
-d'abord et de re-essayer après. </para>
+<para> Si votre réplication a pour but de convertir une fois pour toutes vos données,
+il y a le risque évoqué ci-dessus; si cela vous arrive, il voudra mieux de convertir vos données de la version 8.0
+d'abord et de re-essayer après. </para>
-<para> Au regard des risques encourus, exécuter la réplication en mettant en jeu des versions différentes,
-semble être non pérenne à maintenir. </para>
+<para> Au regard des risques encourus, exécuter la réplication en mettant en jeu des versions différentes,
+semble être non pérenne à maintenir. </para>
<para> Pour plus d'information, voir la discussion <ulink url=
"http://archives.postgresql.org/pgsql-hackers/2005-12/msg00181.php">
@@ -1292,74 +2170,73 @@
</qandaentry>
<qandaentry>
-<question> <para> J'utilise &slony1; 1.1 avec plus de 4 noeuds et deux ensemble de réplication, 1 et 2, qui ne partagent aucun noeuds. Je découvre que les confirmations pour l'ensemble 1
-n'arrivent jamais aux noeuds souscrivant à l'ensemble 2, et inversement, celles de l'ensemble 2 n'arrivent pas non plus
-aux noeuds souscrivant à l'ensemble 1. En conséquence, <xref
-linkend="table.sl-log-1"/> grossit et n'est jamais purgée. Ceci est mentionné dans le bug 1485 :
+<question> <para> J'utilise &slony1; 1.1 avec plus de 4 nœuds et deux ensemble de réplication, 1 et 2, qui ne partagent aucun nœuds. Je découvre que les confirmations pour l'ensemble 1
+n'arrivent jamais aux nœuds souscrivant à l'ensemble 2, et inversement, celles de l'ensemble 2 n'arrivent pas non plus
+aux nœuds souscrivant à l'ensemble 1. En conséquence, &sllog1;/&sllog2; grossissent et ne sont jamais
+purgées. Ceci est mentionné dans le bug 1485 :
<ulink
url="http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1485">
</ulink>.
</para>
</question>
-<answer><para> Apparemment le code de la fonction <function>RebuildListenEntries()</function> ne suffit pas pour résoudre ce cas.</para>
+<answer><para> Apparemment le code de la fonction <function>RebuildListenEntries()</function> ne suffit pas pour résoudre ce cas.</para>
-<para> <function> RebuildListenEntries()</function> sera rectifié dans &slony1; version 1.2
+<para> <function> RebuildListenEntries()</function> sera rectifié dans &slony1; version 1.2
avec un algorithme couvrant ce cas. </para>
<para>
-Dans l'intérim, vous drevez ajouter manuellement quelques entrées dans <xref linkend="table.sl-listen"/> en utilisant <xref
+Dans l'intérim, vous drevez ajouter manuellement quelques entrées dans <xref linkend="table.sl-listen"/> en utilisant <xref
linkend="stmtstorelisten"/> ou <function>storeListen()</function>,
-basé sur les principes décrits dans <xref linkend="listenpaths"/>.
-(apparemment pas aussi désuet que nous avons pensé)
+basé sur les principes décrits dans <xref linkend="listenpaths"/>.
+(apparemment pas aussi désuet que nous avons pensé)
</para></answer>
</qandaentry>
<qandaentry>
-<question> <para> Je trouve que quelques colonnes de multibyte (Unicode, Big5) sont tronqués un peu, il leur manque les derniers caractères. Pourquoi?
+<question> <para> Je trouve que quelques colonnes de multibyte (Unicode, Big5) sont tronqués un peu, il leur manque les derniers caractères. Pourquoi?
</para> </question>
-<answer> <para> C'était un bug présent jusqu'à la version 1.1.0 de &slony1; ; les colonnes étaient capturées par la fonction <function>logtrigger()</function>, qui coupait les derniers byte d'une colonne représentée dans un format de multibyte. que votre version de <filename>src/backend/slony1_funcs.c</filename> est bien 1.34 ou suppérieur; le patch a été intégré dans la version CVS de 1.34 de ce fichier. </para> </answer>
+<answer> <para> C'était un bug présent jusqu'à la version 1.1.0 de &slony1; ; les colonnes étaient capturées par la fonction <function>logtrigger()</function>, qui coupait les derniers byte d'une colonne représentée dans un format de multibyte. que votre version de <filename>src/backend/slony1_funcs.c</filename> est bien 1.34 ou suppérieur; le patch a été intégré dans la version CVS de 1.34 de ce fichier. </para> </answer>
</qandaentry>
<qandaentry id="sequenceset"><question><para> <ulink url=
"http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1226">
Le bug #1226 </ulink> indique une condition d'erreur qui peut survenir si
-vous faites placer une réplication composée seulement de séquences.
+vous faites placer une réplication composée seulement de séquences.
</para>
</question>
-<answer> <para> Une réponse courte consiste à dire qu'une réplication composée seulement de séquences, n'est pas une <link linkend="bestpractices">
+<answer> <para> Une réponse courte consiste à dire qu'une réplication composée seulement de séquences, n'est pas une <link linkend="bestpractices">
bonne pratique.</link> </para>
</answer>
<answer>
-<para> Le problème avec un ensemble de réplication contenant uniquement des séquences, ce sont les cas ou les seuls abonnements actifs sont composés uniquement de séquences. Si un noeud entre dans cet état,
-la réplication échouera, puisque la requête qui collecte les données dans <xref
-linkend="table.sl-log-1"/> ne trouvera aucune table et par conséquent la requête sera malformée et échouera. Si un ensemble de réplication <emphasis>contenant</emphasis> des tables reapparaît, tout va fonctionner correctement; cela <emphasis>parait</emphasis> effrayant.
+<para> Le problème avec un ensemble de réplication contenant uniquement des séquences, ce sont les cas ou les seuls abonnements actifs sont composés uniquement de séquences. Si un nœud entre dans cet état,
+la réplication échouera, puisque la requête qui collecte les données dans &sllog1;/&sllog2; ne trouveront aucune table et par conséquent la requête sera malformée et échouera. Si un ensemble de réplication <emphasis>contenant</emphasis> des tables reapparaît, tout va fonctionner correctement; cela <emphasis>parait</emphasis> effrayant.
</para>
-<para> Ce problème devrait être résolu après &slony1;
+<para> Ce problème devrait être résolu après &slony1;
1.1.0.</para>
</answer>
</qandaentry>
<qandaentry>
-<question><para>Je dois supprimer une table d'un ensemble de réplication</para></question>
+<question><para>Je dois supprimer une table d'un ensemble de réplication</para></question>
<answer><para>
-Ceci peut être accompli de plusieurs manières, pas toutes également souhaitables ;-).
+Ceci peut être accompli de plusieurs manières, pas toutes également souhaitables ;-).
<itemizedlist>
-<listitem><para> Vous pourriez supprimer tout le jeu de réplication, et les recréer avec juste les tables dont vous avez besoin. Hélas, ce signifie reproduire un tas de données, et interromp la réplicationdes autres éléments de l'ensemble pendant toute la duréel'opération</para></listitem>
+<listitem><para> Vous pourriez supprimer tout le jeu de réplication, et les recréer avec juste les tables dont vous avez besoin. Hélas, ce signifie reproduire un tas de données, et interromp la réplicationdes autres éléments de l'ensemble pendant toute la duréel'opération</para></listitem>
-<listitem><para> Si vous êtes en version 1.0.5 ou supérieur, il y a une commande SET DROP TABLE, qui "fera l'affaire."</para></listitem>
+<listitem><para> Si vous êtes en version 1.0.5 ou supérieur, il y a une commande SET DROP TABLE, qui "fera l'affaire."</para></listitem>
<listitem><para> Si vous utilisez toujours une version 1.0.1 ou 1.0.2,
-<emphasis>la fonctionnalité essentielle de <xref linkend="stmtsetdroptable"/> se trouve dans la fonction <function>droptable_int()</function> .
-Vous pouvez l'utilisez à la main en trouvant l'identifiant de la table à supprimer, qui se trouve dans la table <xref
-linkend="table.sl-table"/>, puis lancer les trois requêtes suivantes sur chaque noeud :</emphasis>
+<emphasis>la fonctionnalité essentielle de <xref linkend="stmtsetdroptable"/> se trouve dans la fonction <function>droptable_int()</function> .
+Vous pouvez l'utilisez à la main en trouvant l'identifiant de la table à supprimer, qui se trouve dans la table <xref
+linkend="table.sl-table"/>, puis lancer les trois requêtes suivantes sur chaque nœud :</emphasis>
<programlisting>
select _slonyschema.alterTableRestore(40);
@@ -1367,23 +2244,23 @@
delete from _slonyschema.sl_table where tab_id = 40;
</programlisting></para>
-<para>Évidement le nom du schéma dépend de la façon dont vous avez défini le cluster &slony1;. L'identifiant de la table, dans cet exemple: 40, doit être remplacé par celui de la table dont voulez vous débarrasser.</para>
+<para>Évidement le nom du schéma dépend de la façon dont vous avez défini le cluster &slony1;. L'identifiant de la table, dans cet exemple: 40, doit être remplacé par celui de la table dont voulez vous débarrasser.</para>
-<para> Vous devrez lancer ces trois interrogations sur tous les noeuds, de préférence premièrement sur le noeud d'origine, de sorte que la suppressions se propage correctement.
-On peut également Implémenter ceci à travers un commande <xref linkend="slonik"/> et
-un nouvel évenement &slony1;. Soumettre les trois requêtes en utilisant <xref linkend="stmtddlscript"/> permet de le faire.
-Il est égalementt possible de se connecter à chaque base de données et de lancer les requêtes à la main.</para></listitem> </itemizedlist></para>
+<para> Vous devrez lancer ces trois interrogations sur tous les nœuds, de préférence premièrement sur le nœud d'origine, de sorte que la suppressions se propage correctement.
+On peut également Implémenter ceci à travers un commande <xref linkend="slonik"/> et
+un nouvel évenement &slony1;. Soumettre les trois requêtes en utilisant <xref linkend="stmtddlscript"/> permet de le faire.
+Il est égalementt possible de se connecter à chaque base de données et de lancer les requêtes à la main.</para></listitem> </itemizedlist></para>
</answer>
</qandaentry>
<qandaentry>
-<question><para>Je dois supprimer une séquence dans une séquence pour un ensemble de réplication</para></question>
+<question><para>Je dois supprimer une séquence dans une séquence pour un ensemble de réplication</para></question>
-<answer><para></para><para>Si vous êtes en version 1.0.5 ou supérieure, il existe une commande <xref linkend="stmtsetdropsequence"/> dans Slonik vous permettant de le faire en paralelle <xref linkend="stmtsetdroptable"/>.</para>
+<answer><para></para><para>Si vous êtes en version 1.0.5 ou supérieure, il existe une commande <xref linkend="stmtsetdropsequence"/> dans Slonik vous permettant de le faire en paralelle <xref linkend="stmtsetdroptable"/>.</para>
-<para>Si vous êtes en version 1.0.2 ou antérieure, l'opération sera un peu plus manuelle.</para>
+<para>Si vous êtes en version 1.0.2 ou antérieure, l'opération sera un peu plus manuelle.</para>
-<para>À supposer que je veux me débarrasser des deux séquences suivante : ,<envar>whois_cachemgmt_seq</envar> et
+<para>À supposer que je veux me débarrasser des deux séquences suivante : ,<envar>whois_cachemgmt_seq</envar> et
<envar>epp_whoi_cach_seq_</envar>, tout d'abord il nous faut les valeurs de <envar>seq_id</envar>.
<screen>
@@ -1395,45 +2272,83 @@
(2 rows)
</screen></para>
-<para>Les données à supprimer pour empêcher Slony de continuer la réplication sont :
+<para>Les données à supprimer pour empêcher Slony de continuer la réplication sont :
<programlisting>
delete from _oxrsorg.sl_seqlog where seql_seqid in (93, 59);
delete from _oxrsorg.sl_sequence where seq_id in (93,59);
</programlisting></para>
-<para>Ces deux interrogations peuvent être soumises à l'ensemble des noeud via la fonction &funddlscript; / <xref
-linkend="stmtddlscript"/>, éliminant la séquence partout
-<quote>en même temps.</quote> Ou bien on peut les appliquer à la main à chacun des noeuds.</para>
+<para>Ces deux interrogations peuvent être soumises à l'ensemble des nœud via la fonction &funddlscript; / <xref
+linkend="stmtddlscript"/>, éliminant la séquence partout
+<quote>en même temps.</quote> Ou bien on peut les appliquer à la main à chacun des nœuds.</para>
-<para>De la même manière que <xref linkend="stmtsetdroptable"/>,
-cette fonction est implementée dans &slony1; version 1.0.5 sous
+<para>De la même manière que <xref linkend="stmtsetdroptable"/>,
+cette fonction est implementée dans &slony1; version 1.0.5 sous
le nom <xref
linkend="stmtsetdropsequence"/>.</para></answer></qandaentry>
+<qandaentry>
+<question><para> I set up my cluster using pgAdminIII, with cluster
+name <quote>MY-CLUSTER</quote>. Time has passed, and I tried using
+Slonik to make a configuration change, and this is failing with the
+following error message:</para>
+
+<programlisting>
+ERROR: syntax error at or near -
+</programlisting>
+</question>
+
+<answer><para> The problem here is that &slony1; expects cluster names
+to be valid <ulink url=
+"http://www.postgresql.org/docs/8.3/static/sql-syntax-lexical.html">
+SQL Identifiers</ulink>, and &lslonik; enforces this. Unfortunately,
+<application>pgAdminIII</application> did not do so, and allowed using
+a cluster name that now causes <emphasis>a problem.</emphasis> </para> </answer>
+
+<answer> <para> If you have gotten into this spot, it's a problem that
+we mayn't be help resolve, terribly much. </para>
+
+<para> It's <emphasis>conceivably possible</emphasis> that running the
+SQL command <command>alter namespace "_My-Bad-Clustername" rename to
+"_BetterClusterName";</command> against each database may work. That
+shouldn't particularly <emphasis>damage</emphasis> things!</para>
+
+<para> On the other hand, when the problem has been experienced, users
+have found they needed to drop replication and rebuild the
+cluster.</para> </answer>
+
+<answer><para> A change in version 2.0.2 is that a function runs as
+part of loading functions into the database which checks the validity
+of the cluster name. If you try to use an invalid cluster name,
+loading the functions will fail, with a suitable error message, which
+should prevent things from going wrong even if you're using tools
+other than &lslonik; to manage setting up the cluster. </para></answer>
+</qandaentry>
+
</qandadiv>
-<qandadiv id="faqobsolete"> <title> &slony1; FAQ: Problèmes devenus obsolètes</title>
+<qandadiv id="faqobsolete"> <title> &slony1; FAQ: Problèmes devenus obsolètes</title>
<qandaentry>
-<question><para> &lslon; ne se remet pas en marche après un incident</para>
+<question><para> &lslon; ne se remet pas en marche après un incident</para>
-<para> Après un arrêt immédiat de &postgres; (équivalent à un crash du système),
+<para> Après un arrêt immédiat de &postgres; (équivalent à un crash du système),
dans la table &pglistener; on trouve un tuple contenant <command>
-relname='_${cluster_name}_Restart'</command>. slon ne démarre pas car
-il considère qu'un autre processus gère le cluster sur ce noeud. Que puis-je faire?
-Le tuple ne peuventt pas être supprimés dans cette relation.</para>
+relname='_${cluster_name}_Restart'</command>. slon ne démarre pas car
+il considère qu'un autre processus gère le cluster sur ce nœud. Que puis-je faire?
+Le tuple ne peuventt pas être supprimés dans cette relation.</para>
-<para> Les journaux de traces indique qu' <blockquote><para>un autre slon en tâche de fond gère déjà ce noeud.</para></blockquote></para></question>
+<para> Les journaux de traces indique qu' <blockquote><para>un autre slon en tâche de fond gère déjà ce nœud.</para></blockquote></para></question>
-<answer><para> Le problème est que la table système &pglistener;, utilisée par
-&postgres; pour gérer les notification d'évènements, contient quelques entrées pointant vers des processus qui n'existent plus.
+<answer><para> Le problème est que la table système &pglistener;, utilisée par
+&postgres; pour gérer les notification d'évènements, contient quelques entrées pointant vers des processus qui n'existent plus.
La nouvelle instance de <xref
-linkend="slon"/> se connecte à la base, et elle est convaincue, à cause de la
-présence de ces entrées qu'un ancien
-<application>slon</application> est toujours en activité pour s'occuper de ce noeud de &slony1;.</para>
+linkend="slon"/> se connecte à la base, et elle est convaincue, à cause de la
+présence de ces entrées qu'un ancien
+<application>slon</application> est toujours en activité pour s'occuper de ce nœud de &slony1;.</para>
-<para> Les <quote>détritus</quote> dans cette table doivent être nettoyés.</para>
+<para> Les <quote>détritus</quote> dans cette table doivent être nettoyés.</para>
<para>Il est utile de maintenir un script manuel pour ce genre de situation:
@@ -1451,20 +2366,20 @@
</programlisting></para>
<para> <xref linkend="stmtrestartnode"/> nettoie les notifications mortes
-pour qu'on puisse ensuite redémarrer le noeud.</para>
+pour qu'on puisse ensuite redémarrer le nœud.</para>
-<para>A partir de la version 1.0.5, le processus de démarrage de sloncherche ce genre de données obsolètes et les nettoient
-le cas échéant.</para>
+<para>A partir de la version 1.0.5, le processus de démarrage de sloncherche ce genre de données obsolètes et les nettoient
+le cas échéant.</para>
<para> A partir de la version 8.1 de &postgres;, la fonction manipulant
-&pglistener; ne supporte pas cet usage, alors pour les versions de &slony1; postérieurs à la
+&pglistener; ne supporte pas cet usage, alors pour les versions de &slony1; postérieurs à la
1.1.2 (<emphasis>e.g. - </emphasis> 1.1.5), ce risque d'
-<quote>inter-blocage</quote> est géré vias une nouvelle table,
-et le problème disparait de manière transparente. <quote>.</quote> </para>
+<quote>inter-blocage</quote> est géré vias une nouvelle table,
+et le problème disparait de manière transparente. <quote>.</quote> </para>
</answer></qandaentry>
-<qandaentry><question><para> J'ai essayé la requête suivante qui ne marche pas:</para>
+<qandaentry><question><para> J'ai essayé la requête suivante qui ne marche pas:</para>
<programlisting>
sdb=# explain select query_start, current_query from pg_locks join
@@ -1474,38 +2389,38 @@
ERROR: could not find hash function for hash operator 716373
</programlisting>
-<para> Il semble que les fonctions <function>xxid</function> de &slony1; prétendent pouvoir faire du hashing, mais qu'elles n'y arrivent pas.</para>
+<para> Il semble que les fonctions <function>xxid</function> de &slony1; prétendent pouvoir faire du hashing, mais qu'elles n'y arrivent pas.</para>
<para> Que se passe-t-il ? </para>
</question>
-<answer><para> &slony1; a défini un nouveau type de données et d'opérateurs XXID
-afin de permettre la manipulation des IDs de transaction qui sont employés
-pour grouper ensemble, les mises à jour qui sont associées dans une même transaction.
+<answer><para> &slony1; a défini un nouveau type de données et d'opérateurs XXID
+afin de permettre la manipulation des IDs de transaction qui sont employés
+pour grouper ensemble, les mises à jour qui sont associées dans une même transaction.
</para>
-<para> Ces opérateurs n'étaient pas disponible pour &postgres; version
-7.3 et inférieur; afin de rendre &slony1; opérationnel avec la version 7.3, des fonctions spécifiques
-doivent être ajoutées. L'opérateur <function>=</function>
-a été marqué comme supportant
-le hachage, mais pour que cela fonctionne, l'opérateur de jointure doit
-apparaître dans une classe d'opérateur d'index haché. Cela n'a pas été défini ainsi,
-et en conséquence, les requêtes (comme celle ci-dessus) qui décident d'employer
-des hash-joins échoueront. </para> </answer>
+<para> Ces opérateurs n'étaient pas disponible pour &postgres; version
+7.3 et inférieur; afin de rendre &slony1; opérationnel avec la version 7.3, des fonctions spécifiques
+doivent être ajoutées. L'opérateur <function>=</function>
+a été marqué comme supportant
+le hachage, mais pour que cela fonctionne, l'opérateur de jointure doit
+apparaître dans une classe d'opérateur d'index haché. Cela n'a pas été défini ainsi,
+et en conséquence, les requêtes (comme celle ci-dessus) qui décident d'employer
+des hash-joins échoueront. </para> </answer>
<answer> <para> Ceci <emphasis> n'a pas </emphasis>
-été considéré comme bug <quote>critiques</quote>, car &slony1;
-ne produit pas de requêtes employant des hash-join. Ce problème ne devrait
-pas perturber la réplication. </para> </answer>
+été considéré comme bug <quote>critiques</quote>, car &slony1;
+ne produit pas de requêtes employant des hash-join. Ce problème ne devrait
+pas perturber la réplication. </para> </answer>
<answer> <para> Les versions suivantes de &slony1; (<emphasis>par exemple :</emphasis>
1.0.6, 1.1) omettent l'indicateur <command>HASHES</command>
</para> </answer>
-<answer> <para> Supposons que vous souhaitiez réparer une instance existante, et vous constatez
-que vos propres scripts ne fonctionneront pas bien, vous pouvez suivre la démarche suivante : </para>
+<answer> <para> Supposons que vous souhaitiez réparer une instance existante, et vous constatez
+que vos propres scripts ne fonctionneront pas bien, vous pouvez suivre la démarche suivante : </para>
<programlisting>
/* cbbrowne@[local]/dba2 slony_test1=*/ \x
@@ -1539,30 +2454,30 @@
</qandaentry>
<qandaentry> <question><para> Je peux faire un <command>pg_dump</command>
-et rechargez les données beaucoup plus rapidement qu'avec <command>SUBSCRIBE
+et rechargez les données beaucoup plus rapidement qu'avec <command>SUBSCRIBE
SET</command>. Comment est-ce possible ? </para></question>
-<answer><para> &slony1; dépend de l'existance d'un index sur la clef primaire
-et ne touche pas aux autres index pendant l'opération &postgres; <command>COPY</command> qui charge les données.
-Par ailleur il peut y avoir une dégradation de performance, provoquée par l'évènement <command>COPY SET</command> (un
-évènement généré lors d'un abonnement) dans la mesure où l'opération commence par une suppression des contenus des tables, ce qui laisse la tables remplie de tuples morts.</para>
+<answer><para> &slony1; dépend de l'existance d'un index sur la clef primaire
+et ne touche pas aux autres index pendant l'opération &postgres; <command>COPY</command> qui charge les données.
+Par ailleur il peut y avoir une dégradation de performance, provoquée par l'évènement <command>COPY SET</command> (un
+évènement généré lors d'un abonnement) dans la mesure où l'opération commence par une suppression des contenus des tables, ce qui laisse la tables remplie de tuples morts.</para>
-<para> Lorsque vous utilisez <command>pg_dump</command> pour exporter le contenus de la base, et que vous les re-importez après, les indexes ne sont crées qu'à la fin.
-Il est <emphasis>beaucoup</emphasis> plus performant de reconstruire les indexes sur une table entièrement re-importée, plutôt que de refaire les indexes à la volée lorsque les enregistrements sont rajoutés un à un à la table.</para></answer>
+<para> Lorsque vous utilisez <command>pg_dump</command> pour exporter le contenus de la base, et que vous les re-importez après, les indexes ne sont crées qu'à la fin.
+Il est <emphasis>beaucoup</emphasis> plus performant de reconstruire les indexes sur une table entièrement re-importée, plutôt que de refaire les indexes à la volée lorsque les enregistrements sont rajoutés un à un à la table.</para></answer>
-<answer><para> Si vous pouvez supprimer des indexes inutiles, lorsque <command>COPY</command> se met en marche, les performances sont sensiblement améliorée.
-Encore mieux, si vous pouvez faire un <command>TRUNCATE</command> sur les tables dont le contenu devra disparaître, les performances vont augmenter <emphasis>énormément</emphasis>. </para></answer>
+<answer><para> Si vous pouvez supprimer des indexes inutiles, lorsque <command>COPY</command> se met en marche, les performances sont sensiblement améliorée.
+Encore mieux, si vous pouvez faire un <command>TRUNCATE</command> sur les tables dont le contenu devra disparaître, les performances vont augmenter <emphasis>énormément</emphasis>. </para></answer>
-<answer><para> &slony1; en version 1.1.5 et supérieures, fait cela automatiquement;
-il <quote>dégage</quote> sur les indexes dans le catalogue de &postgres; afin de les cacher, de la même façon qu'il cache les triggers,
-puis il <quote>répare</quote> les pointeurs d'index et effectue une
+<answer><para> &slony1; en version 1.1.5 et supérieures, fait cela automatiquement;
+il <quote>dégage</quote> sur les indexes dans le catalogue de &postgres; afin de les cacher, de la même façon qu'il cache les triggers,
+puis il <quote>répare</quote> les pointeurs d'index et effectue une
reindexationd de la table. </para> </answer>
</qandaentry>
<qandaentry id="dupkey">
-<question><para>La réplication échoue - Violation de Constrainte Unique</para>
+<question><para>La réplication échoue - Violation de Constrainte Unique</para>
-<para>Alors que la Réplication se déroule correctement depuis un bout de temps, lorsque que tout a coup 'un noeud rencontre un <quote>soucis</quote> et les erreurs suivantes envoyées dans le journal:
+<para>Alors que la Réplication se déroule correctement depuis un bout de temps, lorsque que tout a coup 'un nœud rencontre un <quote>soucis</quote> et les erreurs suivantes envoyées dans le journal:
<screen>
DEBUG2 remoteWorkerThread_1: syncing set 2 with 5 table(s) from provider 1
@@ -1586,77 +2501,73 @@
ERROR remoteWorkerThread_1: SYNC aborted
</screen></para>
-<para>La transaction s'annule, et &slony1; essaie à nouveau sans cesse.
-Le problème est dû à une des <emphasis>dernières</emphasis> requêtes SQL, celle qui contenait <command>log_cmdtype = 'I'</command>.
-Ce n'est pas évident du tout;e &slony1; regroupe 10 opérations de mise à jour ensemble, afin de diminuer les allers-retours réseau.</para></question>
+<para>La transaction s'annule, et &slony1; essaie à nouveau sans cesse.
+Le problème est dû à une des <emphasis>dernières</emphasis> requêtes SQL, celle qui contenait <command>log_cmdtype = 'I'</command>.
+Ce n'est pas évident du tout;e &slony1; regroupe 10 opérations de mise à jour ensemble, afin de diminuer les allers-retours réseau.</para></question>
-<answer><para> Il est difficile de déterminer avec <emphasis>exactitude</emphasis> l'origine de tout ceci.</para>
+<answer><para> Il est difficile de déterminer avec <emphasis>exactitude</emphasis> l'origine de tout ceci.</para>
-<para>En même temps, nous notons qu'il y a un problème : les transactions annulées ont été supprimées dans <xref
-linkend="table.sl-log-1"/>,
-et on constate qu'il est impossible de les récupérer.
-A ce stade, il parait nécessaire de supprimer l'ensemble de réplication (ou même le noeud), et de redémarrer la réplication à partir de zéro pour ce noeud.</para>
+<para>En même temps, nous notons qu'il y a un problème : les transactions annulées ont été supprimées dans &sllog1;,
+et on constate qu'il est impossible de les récupérer.
+A ce stade, il parait nécessaire de supprimer l'ensemble de réplication (ou même le nœud), et de redémarrer la réplication à partir de zéro pour ce nœud.</para>
-<para>Dans &slony1; 1.0.5, l'opération de purge de <xref
-linkend="table.sl-log-1"/> devient plus prudente, en refusant
-de purger des entrées qui n'ont pas encore été synchronisées, pendanttr au moins 10 minutes sur l'ensemble des noeuds. Il n'est pas certain que ceci empêche que
-<quote>le problème</quote> ait lieu, mais il paraît plausible que cela laisse assez de données dans <xref linkend="table.sl-log-1"/> permettant un recouvrement ou bien de permettre d'au moins de diagnostiquer plus exactement la situation.
-Et peut-être que le problème venait du fait que <xref linkend="table.sl-log-1"/> était brutalement purgée, donc cette solution permet de résoudre complètement ce genre d'incident.</para>
+<para>Dans &slony1; 1.0.5, l'opération de purge de &sllog1; devient plus prudente, en refusant
+de purger des entrées qui n'ont pas encore été synchronisées, pendanttr au moins 10 minutes sur l'ensemble des nœuds. Il n'est pas certain que ceci empêche que
+<quote>le problème</quote> ait lieu, mais il paraît plausible que cela laisse assez de données dans &sllog1; permettant un recouvrement ou bien de permettre d'au moins de diagnostiquer plus exactement la situation.
+Et peut-être que le problème venait du fait que &sllog1; était brutalement purgée, donc cette solution permet de résoudre complètement ce genre d'incident.</para>
-<para> C'est une honte de devoir reconstruire une réplication volumineuse sur un noeud à cause de cela.
-Si vous découvrez que le problème persiste,
-La bonne idée serait de diviser la réplication
-en plusieurs ensemble de réplication afin de dimininuer
-la charge de travail lors de la reconstruction de la réplication.
-Si un seul ensemble est cassé, vous n'auriez qu'à désabonner et supprimer celui-ci.
+<para> C'est une honte de devoir reconstruire une réplication volumineuse sur un nœud à cause de cela.
+Si vous découvrez que le problème persiste,
+La bonne idée serait de diviser la réplication
+en plusieurs ensemble de réplication afin de dimininuer
+la charge de travail lors de la reconstruction de la réplication.
+Si un seul ensemble est cassé, vous n'auriez qu'à désabonner et supprimer celui-ci.
</para>
-<para> Dans un cas, nous avons trouvé dans le journal de trace deux lignes <emphasis> identiques </emphasis> concernant l'insertion dans
- <xref linkend="table.sl-log-1"/>.
+<para> Dans un cas, nous avons trouvé dans le journal de trace deux lignes <emphasis> identiques </emphasis> concernant l'insertion dans &sllog1;.
Ceci <emphasis> devrait
-</emphasis> être impossible d'autant plus qu'il s'agit d'une clef primaire sur <xref
-linkend="table.sl-log-1"/>. La dernière théorie sur le sujet laisserait à penser que cette situation
+</emphasis> être impossible d'autant plus qu'il s'agit d'une clef primaire sur &sllog1;. La dernière théorie sur le sujet laisserait à penser que cette situation
viendrait du fait que l'index de <emphasis>cette</emphasis>
-clé était peut-être corrompu (à cause d'un bug de &postgres;),
-et qu'il serait possible d'éviter ce problème en exécutant la
+clé était peut-être corrompu (à cause d'un bug de &postgres;),
+et qu'il serait possible d'éviter ce problème en exécutant la
commande suivante:</para>
<programlisting>
# reindex table _slonyschema.sl_log_1;
</programlisting>
-<para> Au moins dans une occasion cette solution s'est révélée efficace, alors cela sera dommage de ne pas suivre l'exemple.</para>
+<para> Au moins dans une occasion cette solution s'est révélée efficace, alors cela sera dommage de ne pas suivre l'exemple.</para>
</answer>
-<answer> <para> Ce problème s'est avéré être un bug dans &postgres; plutot qu'un bug dans &slony1;. La version 7.4.8 a intégré deux solutions qui permettent de résoudre ce cas. Donc si vous avez un noyau de &postgres; antérieur à 7.4.8,
-vous devriez migrer pour éviter l'erreur.
+<answer> <para> Ce problème s'est avéré être un bug dans &postgres; plutot qu'un bug dans &slony1;. La version 7.4.8 a intégré deux solutions qui permettent de résoudre ce cas. Donc si vous avez un noyau de &postgres; antérieur à 7.4.8,
+vous devriez migrer pour éviter l'erreur.
</para>
</answer>
</qandaentry>
-<qandaentry> <question><para>J'ai commencé à faire une sauvegarde via
+<qandaentry> <question><para>J'ai commencé à faire une sauvegarde via
<application>pg_dump</application>, et Slony
-s'arrête soudainement</para></question>
+s'arrête soudainement</para></question>
-<answer><para>Aïe. Ce qui se passe ici est un conflit entre:
+<answer><para>Aïe. Ce qui se passe ici est un conflit entre:
<itemizedlist>
<listitem><para> <application>pg_dump</application>, qui pose un verrou <command>AccessShareLock</command> sur toutes les tables de la base, y compris celle de &slony1; et</para></listitem>
-<listitem><para> Un événement SYNC de &slony1; qui veut poser un verrou
+<listitem><para> Un événement SYNC de &slony1; qui veut poser un verrou
<command>AccessExclusiveLock</command> sur la table <xref
linkend="table.sl-event"/>.</para></listitem> </itemizedlist></para>
-<para>La requête initiale qui est bloquée est :
+<para>La requête initiale qui est bloquée est :
<screen>
select "_slonyschema".createEvent('_slonyschema, 'SYNC', NULL);
</screen></para>
-<para>(vous pouvez voir ceci dans la vue <envar>pg_stat_activity</envar>, si l'affichage des requête est activé dans
+<para>(vous pouvez voir ceci dans la vue <envar>pg_stat_activity</envar>, si l'affichage des requête est activé dans
<filename>postgresql.conf</filename>)</para>
-<para>La requête qui demandece verrou vient de la fonction <function>Slony_I_ClusterStatus()</function>, que vous trouverez dans
-<filename>slony1_funcs.c</filename>, localisé dans un bloc de code qui est :
+<para>La requête qui demandece verrou vient de la fonction <function>Slony_I_ClusterStatus()</function>, que vous trouverez dans
+<filename>slony1_funcs.c</filename>, localisé dans un bloc de code qui est :
<programlisting>
LOCK TABLE %s.sl_event;
@@ -1665,84 +2576,84 @@
</programlisting></para>
<para>La demande de <command>VERROU</command> va donc attendre et
-durer jusqu'à ce que <command>pg_dump</command> (un autre programme ayant un verrou d'accès sur <xref linkend="table.sl-event"/>)
+durer jusqu'à ce que <command>pg_dump</command> (un autre programme ayant un verrou d'accès sur <xref linkend="table.sl-event"/>)
se termine.</para>
<para>Chaque lecture touchant
-<xref linkend="table.sl-event"/> sera bloqué derrière les appels Ã
+<xref linkend="table.sl-event"/> sera bloqué derrière les appels à
<function>createEvent</function>.</para>
-<para>Les réponses à cette question sont multiples:
+<para>Les réponses à cette question sont multiples:
<itemizedlist>
-<listitem><para> Indiquer explicitement à <application>pg_dump</application>
-les schémas qu'il doit exporter en utilisant l'option <option>--schema=whatever</option>, et ne pas essayer d'exporter le schéma du cluster.</para></listitem>
+<listitem><para> Indiquer explicitement à <application>pg_dump</application>
+les schémas qu'il doit exporter en utilisant l'option <option>--schema=whatever</option>, et ne pas essayer d'exporter le schéma du cluster.</para></listitem>
<listitem><para> Il sera utile aussi d'avoir une option
<option>--exclude-schema</option> dans
-<application>pg_dump</application> afin d'exclure le schéma du cluster de &slony1;. Pourquoi pas dans 8.2...</para></listitem>
+<application>pg_dump</application> afin d'exclure le schéma du cluster de &slony1;. Pourquoi pas dans 8.2...</para></listitem>
-<listitem><para>Notez que la version 1.0.5 utilise des verrous plus précis et moins exclusifs qui évitent ce problème.</para></listitem>
+<listitem><para>Notez que la version 1.0.5 utilise des verrous plus précis et moins exclusifs qui évitent ce problème.</para></listitem>
</itemizedlist></para>
</answer></qandaentry>
</qandadiv>
<qandadiv id="faqoddities"> <title> &slony1; FAQ: Bizareries et modifications dans Slony-I </title>
-<qandaentry><question><para> Que se produit-il avec les règles et les déclencheurs pour ls tables répliquées par
+<qandaentry><question><para> Que se produit-il avec les règles et les déclencheurs pour ls tables répliquées par
&slony1;?</para>
</question>
-<answer><para> Premièrement regardons comment ceci est géré
-<emphasis>en dehors</emphasis> du cas spécifique de la commande Slonik<xref
+<answer><para> Premièrement regardons comment ceci est géré
+<emphasis>en dehors</emphasis> du cas spécifique de la commande Slonik<xref
linkend="stmtstoretrigger"/>. </para>
<para> La fonction <xref
-linkend="function.altertableforreplication-integer"/> prépare chacune des tables
-pour la réplication.</para>
+linkend="function.altertableforreplication-integer"/> prépare chacune des tables
+pour la réplication.</para>
<itemizedlist>
-<listitem><para> Sur le noeud maître, ceci implique l'ajout sur la table d'un déclencheur
+<listitem><para> Sur le nœud maître, ceci implique l'ajout sur la table d'un déclencheur
qui utilise la fonction <xref linkend="function.logtrigger"/>.</para>
-<para> Le déclencheur a pour action d'enregistrer, toutes les mises à jours dans
-la table <xref linkend="table.sl-log-1"/> de &slony1;.
+<para> Le déclencheur a pour action d'enregistrer, toutes les mises à jours dans
+la table &sllog1; de &slony1;.
</para></listitem>
-<listitem><para> Sur un noeud d'abonné, ceci revient à désactiver les déclencheurs et les règles,
-puis, via un déclencheur, de refuser le droit d'accès en écriture sur celle-ci en
+<listitem><para> Sur un nœud d'abonné, ceci revient à désactiver les déclencheurs et les règles,
+puis, via un déclencheur, de refuser le droit d'accès en écriture sur celle-ci en
utilisant la fonction <function>denyAccess()</function>.</para>
-<para> Jusqu'à la version 1.1 (et peut-être après), la
-<quote>désactivation</quote> est faite en modifiant
+<para> Jusqu'à la version 1.1 (et peut-être après), la
+<quote>désactivation</quote> est faite en modifiant
la valeur de <envar>tgrelid</envar> dans les tables
<envar>pg_trigger</envar> ou <envar>pg_rewrite</envar>
en pointant l'identifiant OID sur
-la <quote>clé primaire</quote> de l'index du catalogue, plutôt que
-sur la table elle-même.</para></listitem>
+la <quote>clé primaire</quote> de l'index du catalogue, plutôt que
+sur la table elle-même.</para></listitem>
</itemizedlist>
-<para> Un effet secondaire malheureux est que cette gestion des règles et des déclencheurs a pour effet de les <quote>piétiner</quote>.
-Les règles et les déclencheurs sont toujours là ,
-mais ne plus correctement attachés à leurs tables. Si vous faite un <command>pg_dump</command> sur
-<quote>le noeud d'abonné</quote>, il ne trouvera pas les règles ni les déclencheurs, et puisqu' il ne s'attend pas
-à les voir associés à un index.</para>
+<para> Un effet secondaire malheureux est que cette gestion des règles et des déclencheurs a pour effet de les <quote>piétiner</quote>.
+Les règles et les déclencheurs sont toujours là,
+mais ne plus correctement attachés à leurs tables. Si vous faite un <command>pg_dump</command> sur
+<quote>le nœud d'abonné</quote>, il ne trouvera pas les règles ni les déclencheurs, et puisqu' il ne s'attend pas
+à les voir associés à un index.</para>
</answer>
<answer> <para> Maintenant observer comment <xref linkend="stmtstoretrigger"/>
entre en jeu.</para>
-<para> Pour simplifier, cette commande permet de restaurer les déclencheurs
+<para> Pour simplifier, cette commande permet de restaurer les déclencheurs
avec la fonction <function>alterTableRestore(table id)</function>,
qui restaure l'identifiant OID
de la table dans la colonne <envar>tgrelid</envar> de <envar>pg_trigger</envar> ou
-<envar>pg_rewrite</envar> sur le noeud affecté.</para></answer>
+<envar>pg_rewrite</envar> sur le nœud affecté.</para></answer>
-<answer><para> Ceci implique que le jour où vous souhaitez lancer une sauvegarde directement
-sur un abonné, vous devrez reprendre le schéma depuis un noeud d'origine. Clairement il faudra faire : </para>
+<answer><para> Ceci implique que le jour où vous souhaitez lancer une sauvegarde directement
+sur un abonné, vous devrez reprendre le schéma depuis un nœud d'origine. Clairement il faudra faire : </para>
<screen>
% pg_dump -h originnode.example.info -p 5432 --schema-only --schema=public ourdb > schema_backup.sql
@@ -1753,9 +2664,9 @@
</qandaentry>
<!-- todo -->
-<qandaentry> <question> <para> J'ai essayé les commandes <xref
-linkend="stmtddlscript"/> ou <xref linkend="stmtmoveset"/>, et trouvé
-les messages suivants sur l'un des abonnés :</para>
+<qandaentry> <question> <para> J'ai essayé les commandes <xref
+linkend="stmtddlscript"/> ou <xref linkend="stmtmoveset"/>, et trouvé
+les messages suivants sur l'un des abonnés :</para>
<screen>
NOTICE: Slony-I: multiple instances of trigger defrazzle on table frobozz
@@ -1764,47 +2675,47 @@
</screen>
</question>
-<answer> <para> La difficulté semble venir du fait que
-vous avez ajouté des déclencheurs sur des tables dont le nom rentre en conflit,
-avec les déclencheurs que &slony1; a caché. </para>
+<answer> <para> La difficulté semble venir du fait que
+vous avez ajouté des déclencheurs sur des tables dont le nom rentre en conflit,
+avec les déclencheurs que &slony1; a caché. </para>
-<para> &slony1; cache des déclencheurs (sauf ceux marqués comme <quote>visibles</quote>
-via <xref linkend="stmtstoretrigger"/>) en les attachant à la clé primaire de leur table.
-Dans le cas d'un déclencheur pour clef étrangère, ou d'autres déclencheurs de cohérence des données,
-il est complètement inutile de les placer sur un abonnné,
-au contraire ces déclencheurs doivent être mis en place
-sur le noeud d'origine. En revanche, les déclencheurs de type
-<quote>invalidation de cache</quote> peuvent être placés sur l'abonné.</para>
+<para> &slony1; cache des déclencheurs (sauf ceux marqués comme <quote>visibles</quote>
+via <xref linkend="stmtstoretrigger"/>) en les attachant à la clé primaire de leur table.
+Dans le cas d'un déclencheur pour clef étrangère, ou d'autres déclencheurs de cohérence des données,
+il est complètement inutile de les placer sur un abonnné,
+au contraire ces déclencheurs doivent être mis en place
+sur le nœud d'origine. En revanche, les déclencheurs de type
+<quote>invalidation de cache</quote> peuvent être placés sur l'abonné.</para>
-<para> La <emphasis>bonne manière</emphasis> de manipuler ce genre de déclencheurs est d'utiliser
- <xref linkend="stmtstoretrigger"/>, qui indique Ã
-&slony1; de ne pas désactiver le déclencheur. </para> </answer>
+<para> La <emphasis>bonne manière</emphasis> de manipuler ce genre de déclencheurs est d'utiliser
+ <xref linkend="stmtstoretrigger"/>, qui indique à
+&slony1; de ne pas désactiver le déclencheur. </para> </answer>
-<answer> <para> Mais il peut y avoir quelques DBAs intrépides, qui vont assumer individuellement ce travail en
-installant les déclencheur à la main sur l'abonné, et cela mène généralement créer ce genre de situation. Que faire ? Que faire ?
+<answer> <para> Mais il peut y avoir quelques DBAs intrépides, qui vont assumer individuellement ce travail en
+installant les déclencheur à la main sur l'abonné, et cela mène généralement créer ce genre de situation. Que faire ? Que faire ?
</para>
-<para> La réponse est assez simple : Retirez le déclencheur
-<quote>spécifique</quote> sur l'abonné avant que slony tente de les
+<para> La réponse est assez simple : Retirez le déclencheur
+<quote>spécifique</quote> sur l'abonné avant que slony tente de les
restaurer.
-Dans le meilleur des cas, si le DBA est intrépide et réactif, il aurait fait cela
+Dans le meilleur des cas, si le DBA est intrépide et réactif, il aurait fait cela
<emphasis>avant</emphasis> que le message ait le temps d'arriver. </para>
-<para> Si le DBA n'est pas intrépide, il faut se connecter au noeud
-qui pose problème, et de supprimer la version <quote>visible</quote> du déclencheur utilisant l'ordre
+<para> Si le DBA n'est pas intrépide, il faut se connecter au nœud
+qui pose problème, et de supprimer la version <quote>visible</quote> du déclencheur utilisant l'ordre
<acronym>SQL</acronym> <command>DROP
-TRIGGER</command>. Ceci permet à l'évènement de se dérouler.
-Si l'évènement était <xref linkend="stmtddlscript"/>, alors notre
-<quote>pas-tellement-intrépide </quote> DBA devra remettre en place le déclencheur à la main, ou, s'il a plus de sagesse, il les réactivera avec
+TRIGGER</command>. Ceci permet à l'évènement de se dérouler.
+Si l'évènement était <xref linkend="stmtddlscript"/>, alors notre
+<quote>pas-tellement-intrépide </quote> DBA devra remettre en place le déclencheur à la main, ou, s'il a plus de sagesse, il les réactivera avec
<xref linkend="stmtstoretrigger"/>.</para>
</answer>
</qandaentry>
<qandaentry id="neededexecddl">
-<question> <para> Le comportement : tous les noeuds abonné commencent
- Ã tomber et ont le message d'erreur suivant dans le journal,
-(lorsque j'ai rencontré ce problème, il y avait une longue requête SQL devant chaque message ):</para>
+<question> <para> Le comportement : tous les nœuds abonné commencent
+ à tomber et ont le message d'erreur suivant dans le journal,
+(lorsque j'ai rencontré ce problème, il y avait une longue requête SQL devant chaque message ):</para>
<screen>
ERROR remoteWorkerThread_1: helper 1 finished with error
@@ -1812,22 +2723,22 @@
</screen>
</question>
-<answer> <para> La cause : vous avez probablement effectué
+<answer> <para> La cause : vous avez probablement effectué
un <command>alter table</command> directement sur la
base au lieu d'utiliser la commande slonik
<xref linkend="stmtddlscript"/>.</para>
-<para>La solution consiste à remettre le trigger sur la table affectée,
-et de corriger à la main les données afférentes dans <xref linkend="table.sl-log-1"/>.</para>
+<para>La solution consiste à remettre le trigger sur la table affectée,
+et de corriger à la main les données afférentes dans &sllog1;/&sllog2;.</para>
<itemizedlist>
<listitem><para> A partir des journaux de slon ou de &postgres;,
-vous devrez identifier la requête sql exacte qui a causé l'anomalie.</para></listitem>
+vous devrez identifier la requête sql exacte qui a causé l'anomalie.</para></listitem>
-<listitem><para> Vous avez besoin de réparer les déclencheurs
-définis par Slony dans la table en question.
-Ceci peut se faire à l'aide de la procédure suivante :</para>
+<listitem><para> Vous avez besoin de réparer les déclencheurs
+définis par Slony dans la table en question.
+Ceci peut se faire à l'aide de la procédure suivante :</para>
<screen>
BEGIN;
@@ -1837,12 +2748,11 @@
COMMIT;
</screen>
-<para>Ensuite vous devez trouver les enregistrements dans <xref
-linkend="table.sl-log-1"/> qui sont incohérents et les corriger.
-Il sera préférable d'arrêter les démons Slon
-pour l'ensemble des noeuds excepté celui du maître;
-de cette manière, si vous faites une erreur,elle ne se propagera
-pas immédiatement sur tous les noeuds abonnés.</para>
+<para>Ensuite vous devez trouver les enregistrements dans &sllog1;/&sllog2; qui sont incohérents et les corriger.
+Il sera préférable d'arrêter les démons Slon
+pour l'ensemble des nœuds excepté celui du maître;
+de cette manière, si vous faites une erreur,elle ne se propagera
+pas immédiatement sur tous les nœuds abonnés.</para>
<para> Voici un exemple:</para>
@@ -1887,9 +2797,9 @@
<qandaentry>
-<question><para> Le noeud numéro 1 a été supprimé via <xref
-linkend="stmtdropnode"/>, et le &lslon; d'un autre noeud
-plante systématiquement avec le message
+<question><para> Le nœud numéro 1 a été supprimé via <xref
+linkend="stmtdropnode"/>, et le &lslon; d'un autre nœud
+plante systématiquement avec le message
d'erreurs suivant:</para>
<screen>
@@ -1907,32 +2817,32 @@
DEBUG1 syncThread: thread done
</screen>
-<para> Il semble évident qu'un appel à <xref linkend="stmtstorelisten"/> n'avait pas encore été propagé avant que le noeud 1
-soit éliminé.</para></question>
+<para> Il semble évident qu'un appel à <xref linkend="stmtstorelisten"/> n'avait pas encore été propagé avant que le nœud 1
+soit éliminé.</para></question>
-<answer id="eventsurgery"><para> Ceci illustre le cas où vous avez besoin de
-réaliser <quote>opération chirurgicale</quote> sur un ou plusieurs noeuds.
-Un évènement<command>STORE_LISTEN</command> demeure sans réponse
+<answer id="eventsurgery"><para> Ceci illustre le cas où vous avez besoin de
+réaliser <quote>opération chirurgicale</quote> sur un ou plusieurs nœuds.
+Un évènement<command>STORE_LISTEN</command> demeure sans réponse
alors qu'il veut
-ajouter une voie d'écoute qui <emphasis>ne peut pas</emphasis>
-être crée car le noeud 1 ainsi que toutes les voies vers le
-noeud 1 ont disparus.</para>
+ajouter une voie d'écoute qui <emphasis>ne peut pas</emphasis>
+être crée car le nœud 1 ainsi que toutes les voies vers le
+nœud 1 ont disparus.</para>
-<para> Supposons, pour la démonstration, que les noeuds encore en place soient le 2 et le 3, ainsi le rapport d'erreur est remonté au noeud 3.</para>
+<para> Supposons, pour la démonstration, que les nœuds encore en place soient le 2 et le 3, ainsi le rapport d'erreur est remonté au nœud 3.</para>
-<para> cela implique que l'évènement est stocké sur le noeud 2,
-puisqu'il ne peut pas être sur le noeud 3, vu qu'il n'a pas été
-traité avec succès. La manière la plus facile à faire face Ã
+<para> cela implique que l'évènement est stocké sur le nœud 2,
+puisqu'il ne peut pas être sur le nœud 3, vu qu'il n'a pas été
+traité avec succès. La manière la plus facile à faire face à
cette situation,
-est, de supprimer sur la ligne erronées dans
- <xref linkend="table.sl-event"/> sur lenoeud 2.
-Vous vous connectez à la base du noeud 2, et vous recherchez
- l'évènement <command>STORE_LISTEN</command>:</para>
+est, de supprimer sur la ligne erronées dans
+ <xref linkend="table.sl-event"/> sur lenœud 2.
+Vous vous connectez à la base du nœud 2, et vous recherchez
+ l'évènement <command>STORE_LISTEN</command>:</para>
<para> <command> select * from sl_event where ev_type =
'STORE_LISTEN';</command></para>
-<para> La requête peut ramener plusieurs lignes, mais ne supprimez que la partie nécessaire.</para>
+<para> La requête peut ramener plusieurs lignes, mais ne supprimez que la partie nécessaire.</para>
<screen>
-# begin; -- Don't straight delete them; open a transaction so you can respond to OOPS
@@ -1945,13 +2855,51 @@
COMMIT
</screen>
-<para> La prochaine fois que le <application>slon</application> du noeud 3 va démarrer, il ne trouvera plus l' évènement
-<command>STORE_LISTEN</command> <quote>erroné</quote>, et la réplication pourra se poursuivre.
+<para> La prochaine fois que le <application>slon</application> du nœud 3 va démarrer, il ne trouvera plus l' évènement
+<command>STORE_LISTEN</command> <quote>erroné</quote>, et la réplication pourra se poursuivre.
-( Cependnat vous pourrez ensuite voir surgir un vieil évènement
-enregistré qui fait référence à une configuration qui n'existe plus...) </para></answer>
+( Cependnat vous pourrez ensuite voir surgir un vieil évènement
+enregistré qui fait référence à une configuration qui n'existe plus...) </para></answer>
</qandaentry>
+
+<qandaentry>
+
+<question> <para> I have a database where we have been encountering
+the following error message in our application: </para>
+
+<screen> permission denied for sequence sl_action_seq </screen>
+
+<para> When we traced it back, it was due to the application calling
+<function> lastval() </function> to capture the most recent sequence
+update, which happened to catch the last update to a &slony1; internal
+sequence. </para>
+
+</question>
+
+<answer>
+<para> &slony1; uses sequences to provide primary key values for log
+entries, and therefore this kind of behaviour may (perhaps
+regrettably!) be expected. </para>
+
+<para> Calling <function>lastval()</function>, to
+<quote>anonymously</quote> get <quote>the most recently updated
+sequence value</quote>, rather than using
+<function>currval('sequence_name')</function> is an unsafe thing to do
+in general, as anything you might add in that uses DBMS features for
+logging, archiving, or replication can throw in an extra sequence
+update that you weren't expecting. </para>
+
+<para> In general, use of <function>lastval()</function> doesn't seem
+terribly safe; using it when &slony1; (or any similar trigger-based
+replication system such as <application>Londiste</application> or
+<application>Bucardo</application>) can lead to capturing unexpected
+sequence updates. </para>
+
+</answer>
+
+</qandaentry>
+
</qandadiv>
</qandaset>
Plus d'informations sur la liste de diffusion Trad