[Trad] [svn:pgfr] r1083 - traduc/trunk/slony
svncommit at kryskool.org
svncommit at kryskool.org
Mer 2 Juil 17:45:24 CEST 2008
Auteur: david.tokmatchi at gmail.com
Date: 2008-07-02 17:45:22 +0200 (mer, 02 jui 2008)
Nouvelle Révision: 1083
Modification:
traduc/trunk/slony/faq.xml
Log:
Modified: traduc/trunk/slony/faq.xml
===================================================================
--- traduc/trunk/slony/faq.xml 2008-07-02 15:34:18 UTC (rev 1082)
+++ traduc/trunk/slony/faq.xml 2008-07-02 15:45:22 UTC (rev 1083)
@@ -1,2276 +1,2128 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modification
- le $Date$
- par $Author$
- révision $Revision$ -->
-
-<qandaset>
-<indexterm><primary>Frequently Asked Questions about &slony1;</primary></indexterm>
-
-<qandadiv id="faqcompiling"><title> &slony1; FAQ: Building and Installing &slony1; </title>
-
-<qandaentry>
-
-<question><para> I am using <productname> Frotznik Freenix
-4.5</productname>, with its <acronym>FFPM</acronym> (Frotznik Freenix
-Package Manager) package management system. It comes with
-<acronym>FFPM</acronym> packages for &postgres; 7.4.7, which are what
-I am using for my databases, but they don't include &slony1; in the
-packaging. How do I add &slony1; to this? </para>
-</question>
-
-
-<answer><para> <productname>Frotznik Freenix</productname> is new to
-me, so it's a bit dangerous to give really hard-and-fast definitive
-answers. </para>
-
-<para> The answers differ somewhat between the various combinations of
-&postgres; and &slony1; versions; the newer versions generally
-somewhat easier to cope with than are the older versions. In general,
-you almost certainly need to compile &slony1; from sources; depending
-on versioning of both &slony1; and &postgres;, you
-<emphasis>may</emphasis> need to compile &postgres; from scratch.
-(Whether you need to <emphasis> use </emphasis> the &postgres; compile
-is another matter; you probably don't...) </para>
-
-<itemizedlist>
-
-<listitem><para> &slony1; version 1.0.5 and earlier require having a
-fully configured copy of &postgres; sources available when you compile
-&slony1;.</para>
-
-<para> <emphasis>Hopefully</emphasis> you can make the configuration
-this closely match against the configuration in use by the packaged
-version of &postgres; by checking the configuration using the command
-<command> pg_config --configure</command>. </para> </listitem>
-
-<listitem> <para> &slony1; version 1.1 simplifies this considerably;
-it does not require the full copy of &postgres; sources, but can,
-instead, refer to the various locations where &postgres; libraries,
-binaries, configuration, and <command> #include </command> files are
-located. </para> </listitem>
-
-<listitem><para> &postgres; 8.0 and higher is generally easier to deal
-with in that a <quote>default</quote> installation includes all of the
-<command> #include </command> files. </para>
-
-<para> If you are using an earlier version of &postgres;, you may find
-it necessary to resort to a source installation if the packaged
-version did not install the <quote>server
-<command>#include</command></quote> files, which are installed by the
-command <command> make install-all-headers </command>.</para>
-</listitem>
-
-</itemizedlist>
-
-<para> In effect, the <quote>worst case</quote> scenario takes place
-if you are using a version of &slony1; earlier than 1.1 with an
-<quote>elderly</quote> version of &postgres;, in which case you can
-expect to need to compile &postgres; from scratch in order to have
-everything that the &slony1; compile needs even though you are using a
-<quote>packaged</quote> version of &postgres;.</para>
-
-<para> If you are running a recent &postgres; and a recent &slony1;,
-then the codependencies can be fairly small, and you may not need
-extra &postgres; sources. These improvements should ease the
-production of &slony1; packages so that you might soon even be able to
-hope to avoid compiling &slony1;.</para>
-
-</answer>
-
-<answer><para> </para> </answer>
-
-</qandaentry>
-
-<qandaentry id="missingheaders">
-<question><para> I tried building &slony1; 1.1 and got the following
-error message:
-<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>
-
-<answer><para> You are almost certainly running version &postgres; 7.4
-or earlier, where server headers are not installed by default if you
-just do a <command>make install</command> of &postgres;.</para>
-
-<para> You need to install server headers when you install &postgres;
-via the command <command>make install-all-headers</command>.
-
-</para> </answer> </qandaentry>
-
-<qandaentry id="threadsafety">
-
-<question><para> &slony1; seemed to compile fine; now, when I run a
-&lslon;, some events are moving around, but no
-replication is taking place.</para>
-
-<para> Slony logs might look like the following:
-
-<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,
- ev_data1, ev_data2,
- 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>
-
-<para> Alternatively, it may appear like...
-
-<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>
-
-<answer><para>On AIX and Solaris (and possibly elsewhere), both
-&slony1; <emphasis>and &postgres;</emphasis> must be compiled with the
-<option>--enable-thread-safety</option> option. The above results
-when &postgres; isn't so compiled.</para>
-
-<para>What breaks here is that the libc (threadsafe) and libpq
-(non-threadsafe) use different memory locations for errno, thereby
-leading to the request failing.</para>
-
-<para>Problems like this crop up with disadmirable regularity on AIX
-and Solaris; it may take something of an <quote>object code audit</quote> to
-make sure that <emphasis>ALL</emphasis> of the necessary components have been
-compiled and linked with <option>--enable-thread-safety</option>.</para>
-
-<para>For instance, I ran into the problem one that
-<envar>LD_LIBRARY_PATH</envar> had been set, on Solaris, to point to
-libraries from an old &postgres; compile. That meant that even though
-the database <emphasis>had</emphasis> been compiled with
-<option>--enable-thread-safety</option>, and
-<application>slon</application> had been compiled against that,
-<application>slon</application> was being dynamically linked to the
-<quote>bad old thread-unsafe version,</quote> so slon didn't work. It
-wasn't clear that this was the case until I ran <command>ldd</command>
-against <application>slon</application>.</para> </answer>
-
-<answer><para> Note that with libpq version 7.4.2, on Solaris, a
-further <link linkend="threadpatch"> thread patch </link> was
-required; similar is also required for &postgres; version 8.0.
-</para>
-</answer>
-</qandaentry>
-
-<qandaentry id="pg81funs">
-
-<question> <para> I'm trying to upgrade to a newer version of &slony1;
-and am running into a problem with <xref
-linkend="stmtupdatefunctions"/>. When I run <xref
-linkend="stmtupdatefunctions"/>, my
-<application>postmaster</application> falls over with a Signal 11.
-There aren't any seeming errors in the log files, aside from the
-&postgres; logs indicating that, yes indeed, the postmaster fell
-over.</para>
-
-<para> I connected a debugger to the core file, and it indicates that
-it was trying to commit a transaction at the time of the
-failure. </para>
-
-<para> By the way I'm on &postgres; 8.1.[0-3]. </para>
-</question>
-
-<answer> <para> Unfortunately, early releases of &postgres; 8.1 had a
-problem where if you redefined a function (such as, say,
-<function>upgradeSchema(text)</function>), and then, in the same
-transaction, ran that function, the
-<application>postmaster</application> would fall over, and the
-transaction would fail to commit. </para>
-
-<para> The &lslonik; command <xref linkend="stmtupdatefunctions"/>
-functions like that; it, in one transaction, tries to:
-
-<itemizedlist>
-<listitem><para> Load the new functions (from <filename>slony1_funcs.sql</filename>), notably including <function>upgradeSchema(text)</function>. </para> </listitem>
-<listitem><para> Run <function>upgradeSchema(text)</function> to do any necessary upgrades to the database schema. </para> </listitem>
-<listitem><para> Notify &lslon; processes of a change of configuration.</para> </listitem>
-</itemizedlist>
-</para>
-
-<para> Unfortunately, on &postgres; 8.1.0, 8.1.1, 8.1.2, and 8.1.3,
-this conflicts with a bug where using and modifying a plpgsql function
-in the same transaction leads to a crash. </para>
-
-<para> Several workarounds are available. </para>
-
-</answer>
-
-<answer> <para> The preferred answer would be to upgrade &postgres; to
-8.1.4 or some later version. Changes between minor versions do not
-require rebuilding databases; it should merely require copying a
-suitable 8.1.x build into place, and restarting the
-<application>postmaster</application> with the new version. </para>
-</answer>
-
-<answer><para> If that is unsuitable, it would be possible to perform
-the upgrade via a series of transactions, performing the equivalent of
-what &lslonik; does <quote>by hand</quote>: </para>
-
-<itemizedlist>
-<listitem><para> Take <filename>slony1_funcs.sql</filename> and do three replacements within it: </para>
-
-<itemizedlist>
-<listitem><para> Replace <quote>@CLUSTERNAME@</quote> with the name of the cluster </para> </listitem>
-<listitem><para> Replace <quote>@MODULEVERSION@</quote> with the &slony1; version string, such as <quote>1.2.10</quote> </para> </listitem>
-<listitem><para> Replace <quote>@NAMESPACE@</quote> with the <quote>double-quoted</quote> name of the cluster namespace, such as "_MyCluster" </para> </listitem>
-</itemizedlist>
-</listitem>
-<listitem><para> Load that <quote>remapped</quote> set of functions into the database.</para> </listitem>
-<listitem><para> Run the stored function via <command>select <function>upgradeSchema('1.2.7')</function>; </command>, assuming that the previous version of &slony1; in use was version 1.2.7. </para> </listitem>
-<listitem><para> Restarting all &lslon; processes would probably be a wise move with this sort of <quote>surgery.</quote> </para> </listitem>
-</itemizedlist>
-</answer>
-</qandaentry>
-
-<qandaentry>
-<question> <para> Problem building on Fedora/x86-64 </para>
-
-<para> When trying to configure &slony1; on a Fedora x86-64 system,
-where <application>yum</application> was used to install the package
-<filename>postgresql-libs.x86_64</filename>, the following complaint
-comes up:
-
-<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>
-
-<para> This happened with &postgres; 8.2.5, which is certainly rather
-newer than 7.3. </para>
-</question>
-
-<answer> <para> <application>configure</application> is looking for
-that symbol by compiling a little program that calls for it, and
-checking if the compile succeeds. On the <command>gcc</command>
-command line it uses <command>-lpq</command> to search for the
-library. </para>
-
-<para> Unfortunately, that package is missing a symlink, from
-<filename>/usr/lib64/libpq.so</filename> to
-<filename>libpq.so.5.0</filename>; that is why it fails to link to
-libpq. The <emphasis>true</emphasis> problem is that the compiler failed to
-find a library to link to, not that libpq lacked the function call.
-</para>
-
-<para> Eventually, this should be addressed by those that manage the
-<filename>postgresql-libs.x86_64</filename> package. </para>
-</answer>
-
-<answer> <para> Note that this same symptom can be the indication of
-similar classes of system configuration problems. Bad symlinks, bad
-permissions, bad behaviour on the part of your C compiler, all may
-potentially lead to this same error message. </para>
-
-<para> Thus, if you see this error, you need to look in the log file
-that is generated, <filename>config.log</filename>. Search down to
-near the end, and see what the <emphasis>actual</emphasis> complaint
-was. That will be helpful in tracking down the true root cause of the
-problem.</para>
-</answer>
-
-</qandaentry>
-
-</qandadiv>
-
-<qandadiv id="faqconnections"> <title> &slony1; FAQ: Connection Issues </title>
-<qandaentry>
-
-<question><para>I looked for the <envar>_clustername</envar> namespace, and
-it wasn't there.</para></question>
-
-<answer><para> If the DSNs are wrong, then &lslon;
-instances can't connect to the nodes.</para>
-
-<para>This will generally lead to nodes remaining entirely untouched.</para>
-
-<para>Recheck the connection configuration. By the way, since <xref
-linkend="slon"/> links to libpq, you could have password information
-stored in <filename> $HOME/.pgpass</filename>, partially filling in
-right/wrong authentication information there.</para>
-</answer>
-</qandaentry>
-
-<qandaentry id="morethansuper">
-<question> <para> I created a <quote>superuser</quote> account,
-<command>slony</command>, to run replication activities. As
-suggested, I set it up as a superuser, via the following query:
-<command>
-update pg_shadow set usesuper = 't' where usename in ('slony',
-'molly', 'dumpy');
-</command>
-(that command also deals with other users I set up to run vacuums and
-backups).</para>
-
-<para> Unfortunately, I ran into a problem the next time I subscribed
-to a new set.</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>
-
-<para> This continues to fail, over and over, until I restarted the
-<application>slon</application> to connect as
-<command>postgres</command> instead.</para>
-</question>
-
-<answer><para> The problem is fairly self-evident; permission is being
-denied on the system table, <envar>pg_class</envar>.</para></answer>
-
-<answer><para> The <quote>fix</quote> is thus:</para>
-<programlisting>
-update pg_shadow set usesuper = 't', usecatupd='t' where usename = 'slony';
-</programlisting>
-</answer>
-
-<answer><para> In version 8.1 and higher, you may also need the following:</para>
-<programlisting>
-update pg_authid set rolcatupdate = 't', rolsuper='t' where rolname = 'slony';
-</programlisting>
-</answer>
-</qandaentry>
-
-<qandaentry>
-<question><para> I'm trying to get a slave subscribed, and get the
-following messages in the logs:
-
-<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>
-
-<answer> <para> There is evidently some reasonably old outstanding
-transaction blocking &slony1; from processing the sync. You might
-want to take a look at pg_locks to see what's up:</para>
-
-<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>
-
-<para>See? 127314921 is indeed older than 127314958, and it's still
-running.</para>
-
-<para> A long running G/L report, a runaway
-<application>RT3</application> query, a
-<application>pg_dump</application>, all will open up transactions that
-may run for substantial periods of time. Until they complete, or are
-interrupted, you will continue to see the message <quote> data copy
-for set 1 failed - sleep 60 seconds </quote>.</para>
-
-<para>By the way, if there is more than one database on the &postgres;
-cluster, and activity is taking place on the OTHER database, that will
-lead to there being <quote>transactions earlier than XID
-whatever</quote> being found to be still in progress. The fact that
-it's a separate database on the cluster is irrelevant; &slony1; will
-wait until those old transactions terminate.</para>
-</answer>
-</qandaentry>
-
-<qandaentry>
-<question><para>Same as the above. What I forgot to mention, as well,
-was that I was trying to add <emphasis>TWO</emphasis> subscribers,
-concurrently.</para></question>
-
-<answer><para> That doesn't work out: &slony1; can't work on the
-<command>COPY</command> commands concurrently. See
-<filename>src/slon/remote_worker.c</filename>, function
-<function>copy_set()</function></para>
-
-<screen>
-$ ps -aef | egrep '[2]605100'
-postgres 2605100 205018 0 18:53:43 pts/3 3:13 postgres: postgres sampledb localhost COPY
-</screen>
-
-<para>This happens to be a <command>COPY</command> transaction
-involved in setting up the subscription for one of the nodes. All is
-well; the system is busy setting up the first subscriber; it won't
-start on the second one until the first one has completed subscribing.
-That represents one possible cause.</para>
-
-<para>This has the (perhaps unfortunate) implication that you cannot
-populate two slaves concurrently from a single provider. You have to
-subscribe one to the set, and only once it has completed setting up
-the subscription (copying table contents and such) can the second
-subscriber start setting up the subscription.</para></answer>
-</qandaentry>
-
-<qandaentry id="missingoids"> <question> <para> We got bitten by
-something we didn't foresee when completely uninstalling a slony
-replication cluster from the master and slave...</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>
-
-<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> There are two notable areas of
-&postgres; that cache query plans and OIDs:</para>
-<itemizedlist>
-<listitem><para> Prepared statements</para></listitem>
-<listitem><para> pl/pgSQL functions</para></listitem>
-</itemizedlist>
-
-<para> The problem isn't particularly a &slony1; one; it would occur
-any time such significant changes are made to the database schema. It
-shouldn't be expected to lead to data loss, but you'll see a wide
-range of OID-related errors.
-</para></answer>
-
-<answer><para> The problem occurs when you are using some sort of
-<quote>connection pool</quote> that keeps recycling old connections.
-If you restart the application after this, the new connections will
-create <emphasis>new</emphasis> query plans, and the errors will go
-away. If your connection pool drops the connections, and creates new
-ones, the new ones will have <emphasis>new</emphasis> query plans, and
-the errors will go away. </para></answer>
-
-<answer> <para> In our code we drop the connection on any error we
-cannot map to an expected condition. This would eventually recycle all
-connections on such unexpected problems after just one error per
-connection. Of course if the error surfaces as a constraint violation
-which is a recognized condition, this won't help either, and if the
-problem is persistent, the connections will keep recycling which will
-drop the effect of the pooling, in the latter case the pooling code
-could also announce an admin to take a look... </para> </answer>
-
-
-
-</qandaentry>
-
-<qandaentry><question><para> I upgraded my cluster to &slony1; version
-1.2. I'm now getting the following notice in the logs:</para>
-
-<screen>NOTICE: Slony-I: log switch to sl_log_2 still in progress - sl_log_1 not truncated</screen>
-
-<para> Both <envar>sl_log_1</envar> and <envar>sl_log_2</envar> are
-continuing to grow, and <envar>sl_log_1</envar> is never getting
-truncated. What's wrong?
-</para> </question>
-
-<answer><para> This is symptomatic of the same issue as above with
-dropping replication: if there are still old connections lingering
-that are using old query plans that reference the old stored
-functions, resulting in the inserts to <envar>sl_log_1</envar> </para>
-
-<para> Closing those connections and opening new ones will resolve the
-issue. </para> </answer>
-
-<answer> <para> In the longer term, there is an item on the &postgres;
-TODO list to implement dependancy checking that would flush cached
-query plans when dependent objects change. </para> </answer>
-</qandaentry>
-
-<qandaentry>
-<question><para>I pointed a subscribing node to a different provider
-and it stopped replicating</para></question>
-
-<answer><para>
-We noticed this happening when we wanted to re-initialize a node,
-where we had configuration thus:
-
-<itemizedlist>
-<listitem><para> Node 1 - provider</para></listitem>
-<listitem><para> Node 2 - subscriber to node 1 - the node we're reinitializing</para></listitem>
-<listitem><para> Node 3 - subscriber to node 3 - node that should keep replicating</para></listitem>
-</itemizedlist></para>
-
-<para>The subscription for node 3 was changed to have node 1 as
-provider, and we did <xref linkend="stmtdropset"/> /<xref
-linkend="stmtsubscribeset"/> for node 2 to get it repopulating.</para>
-
-<para>Unfortunately, replication suddenly stopped to node 3.</para>
-
-<para>The problem was that there was not a suitable set of
-<quote>listener paths</quote> in <xref linkend="table.sl-listen"/> to allow the events from
-node 1 to propagate to node 3. The events were going through node 2,
-and blocking behind the <xref linkend="stmtsubscribeset"/> event that
-node 2 was working on.</para>
-
-<para>The following slonik script dropped out the listen paths where
-node 3 had to go through node 2, and added in direct listens between
-nodes 1 and 3.
-
-<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';
- node 4 admin conninfo='host=10.28.103.132 dbname=oxrslive user=postgres port=5432';
-try {
- store listen (origin = 1, receiver = 3, provider = 1);
- 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>
-
-<para>Immediately after this script was run, <command>SYNC</command>
-events started propagating again to node 3.
-
-This points out two principles:
-<itemizedlist>
-
-<listitem><para> If you have multiple nodes, and cascaded subscribers,
-you need to be quite careful in populating the <xref
-linkend="stmtstorelisten"/> entries, and in modifying them if the
-structure of the replication <quote>tree</quote>
-changes.</para></listitem>
-
-<listitem><para> Version 1.1 provides better tools to help manage
-this.</para>
-</listitem>
-
-</itemizedlist></para>
-
-<para>The issues of <quote>listener paths</quote> are discussed
-further at <xref linkend="listenpaths"/> </para></answer>
-</qandaentry>
-
-<qandaentry id="multipleslonconnections">
-
-<question><para> I was starting a &lslon;, and got the
-following <quote>FATAL</quote> messages in its logs. What's up??? </para>
-<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
-2006-03-29 16:01:34 UTC CONFIG main: local node id = 1
-2006-03-29 16:01:34 UTC DEBUG2 main: main process started
-2006-03-29 16:01:34 UTC CONFIG main: launching sched_start_mainloop
-2006-03-29 16:01:34 UTC CONFIG main: loading current cluster configuration
-2006-03-29 16:01:34 UTC CONFIG storeSet: set_id=1 set_origin=1 set_comment='test set'
-2006-03-29 16:01:34 UTC DEBUG2 sched_wakeup_node(): no_id=1 (0 threads + worker signaled)
-2006-03-29 16:01:34 UTC DEBUG2 main: last local event sequence = 7
-2006-03-29 16:01:34 UTC CONFIG main: configuration complete - starting threads
-2006-03-29 16:01:34 UTC DEBUG1 localListenThread: thread starts
-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>
-
-</question>
-
-<answer><para> The table <envar>sl_nodelock</envar> is used as an
-<quote>interlock</quote> to prevent two &lslon; processes from trying
-to manage the same node at the same time. The &lslon; tries inserting
-a record into the table; it can only succeed if it is the only node
-manager. </para></answer>
-
-<answer><para> This error message is typically a sign that you have
-started up a second &lslon; process for a given node. The &lslon; asks
-the obvious question: <quote>Do you already have a slon running
-against this node?</quote> </para></answer>
-
-<answer><para> Supposing you experience some sort of network outage,
-the connection between &lslon; and database may fail, and the &lslon;
-may figure this out long before the &postgres; instance it was
-connected to does. The result is that there will be some number of
-idle connections left on the database server, which won't be closed
-out until TCP/IP timeouts complete, which seems to normally take about
-two hours. For that two hour period, the &lslon; will try to connect,
-over and over, and will get the above fatal message, over and
-over. </para>
-
-<para> An administrator may clean this out by logging onto the server
-and issuing <command>kill -2</command> to any of the offending
-connections. Unfortunately, since the problem took place within the
-networking layer, neither &postgres; nor &slony1; have a direct way of
-detecting this. </para>
-
-<para> You can <emphasis>mostly</emphasis> avoid this by making sure
-that &lslon; processes always run somewhere nearby the server that
-each one manages. If the &lslon; runs on the same server as the
-database it manages, any <quote>networking failure</quote> that could
-interrupt local connections would be likely to be serious enough to
-threaten the entire server. </para></answer>
-</qandaentry>
-
-<qandaentry>
-<question><para> When can I shut down &lslon; processes?</para></question>
-
-<answer><para> Generally, it's no big deal to shut down a &lslon;
-process. Each one is <quote>merely</quote> a &postgres; client,
-managing one node, which spawns threads to manage receiving events
-from other nodes. </para>
-
-<para>The <quote>event listening</quote> threads are no big deal; they
-are doing nothing fancier than periodically checking remote nodes to
-see if they have work to be done on this node. If you kill off the
-&lslon; these threads will be closed, which should have little or no
-impact on much of anything. Events generated while the &lslon; is
-down will be picked up when it is restarted.</para>
-
-<para> The <quote>node managing</quote> thread is a bit more
-interesting; most of the time, you can expect, on a subscriber, for
-this thread to be processing <command>SYNC</command> events. If you
-shut off the &lslon; during an event, the transaction
-will fail, and be rolled back, so that when the &lslon; restarts, it
-will have to go back and reprocess the event.</para>
-
-<para> The only situation where this will
-cause <emphasis>particular</emphasis> <quote>heartburn</quote> is if
-the event being processed was one which takes a long time to process,
-such as <command>COPY_SET</command> for a large replication
-set. </para>
-
-<para> The other thing that <emphasis>might</emphasis> cause trouble
-is if the &lslon; runs fairly distant from nodes that it connects to;
-you could discover that database connections are left <command>idle in
-transaction</command>. This would normally only occur if the network
-connection is destroyed without either &lslon; or database being made
-aware of it. In that case, you may discover
-that <quote>zombied</quote> connections are left around for as long as
-two hours if you don't go in by hand and kill off the &postgres;
-backends.</para>
-
-<para> There is one other case that could cause trouble; when the
-&lslon; managing the origin node is not running,
-no <command>SYNC</command> events run against that node. If the
-&lslon; stays down for an extended period of time, and something
-like <xref linkend="gensync"/> isn't running, you could be left
-with <emphasis>one big <command>SYNC</command></emphasis> to process
-when it comes back up. But that is only a concern if that &lslon; is
-down for an extended period of time; shutting it down for a few
-seconds shouldn't cause any great problem. </para> </answer>
-</qandaentry>
-
-<qandaentry>
-<question><para> Are there risks to doing so? How about
-benefits?</para></question>
-
-<answer><para> In short, if you don't have something like an 18
-hour <command>COPY_SET</command> under way, it's normally not at all a
-big deal to take a &lslon; down for a little while, or perhaps even
-cycle <emphasis>all</emphasis> the &lslon;s. </para> </answer>
-</qandaentry>
-
-</qandadiv>
-
-<qandadiv id="faqconfiguration"> <title> &slony1; FAQ: Configuration Issues </title>
-<qandaentry>
-<question><para>Slonik fails - cannot load &postgres; library -
-<command>PGRES_FATAL_ERROR load '$libdir/xxid';</command></para>
-
-<para> When I run the sample setup script I get an error message similar
-to:
-
-<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>
-
-<answer><para> Evidently, you haven't got the
-<filename>xxid.so</filename> library in the <envar>$libdir</envar>
-directory that the &postgres; instance is
-using. Note that the &slony1; components
-need to be installed in the &postgres;
-software installation for <emphasis>each and every one</emphasis> of
-the nodes, not just on the origin node.</para>
-
-<para>This may also point to there being some other mismatch between
-the &postgres; binary instance and the &slony1; instance. If you
-compiled &slony1; yourself, on a machine that may have multiple
-&postgres; builds <quote>lying around,</quote> it's possible that the
-slon or slonik binaries are asking to load something that isn't
-actually in the library directory for the &postgres; database cluster
-that it's hitting.</para>
-
-<para>Long and short: This points to a need to <quote>audit</quote>
-what installations of &postgres; and &slony1; you have in place on the
-machine(s). Unfortunately, just about any mismatch will cause things
-not to link up quite right. See also <link linkend="threadsafety">
-thread safety </link> concerning threading issues on Solaris
-...</para>
-
-<para> Life is simplest if you only have one set of &postgres;
-binaries on a given server; in that case, there isn't a <quote>wrong
-place</quote> in which &slony1; components might get installed. If
-you have several software installs, you'll have to verify that the
-right versions of &slony1; components are associated with the right
-&postgres; binaries. </para> </answer></qandaentry>
-
-<qandaentry>
-<question> <para>I tried creating a CLUSTER NAME with a "-" in it.
-That didn't work.</para></question>
-
-<answer><para> &slony1; uses the same rules for unquoted identifiers
-as the &postgres; main parser, so no, you probably shouldn't put a "-"
-in your identifier name.</para>
-
-<para> You may be able to defeat this by putting <quote>quotes</quote> around
-identifier names, but it's still liable to bite you some, so this is
-something that is probably not worth working around.</para>
-</answer>
-</qandaentry>
-
-<qandaentry>
-<question><para>ps finds passwords on command line</para>
-
-<para> If I run a <command>ps</command> command, I, and everyone else,
-can see passwords on the command line.</para></question>
-
-<answer> <para>Take the passwords out of the Slony configuration, and
-put them into <filename>$(HOME)/.pgpass.</filename></para>
-</answer></qandaentry>
-
-<qandaentry>
-<question><para>Table indexes with FQ namespace names
-
-<programlisting>
-set add table (set id = 1, origin = 1, id = 27,
- full qualified name = 'nspace.some_table',
- key = 'key_on_whatever',
- comment = 'Table some_table in namespace nspace with a candidate primary key');
-</programlisting></para></question>
-
-<answer><para> If you have <command> key =
-'nspace.key_on_whatever'</command> the request will
-<emphasis>FAIL</emphasis>.</para>
-</answer></qandaentry>
-
-<qandaentry>
-<question> <para> Replication has fallen behind, and it appears that the
-queries to draw data from <xref linkend="table.sl-log-1"/>/<xref
-linkend="table.sl-log-2"/> are taking a long time to pull just a few
-<command>SYNC</command>s. </para>
-</question>
-
-<answer> <para> Until version 1.1.1, there was only one index on <xref
-linkend="table.sl-log-1"/>/<xref linkend="table.sl-log-2"/>, and if
-there were multiple replication sets, some of the columns on the index
-would not provide meaningful selectivity. If there is no index on
-column <function> log_xid</function>, consider adding it. See
-<filename>slony1_base.sql</filename> for an example of how to create
-the index.
-</para>
-</answer>
-</qandaentry>
-
-<qandaentry><question> <para> I need to rename a column that is in the
-primary key for one of my replicated tables. That seems pretty
-dangerous, doesn't it? I have to drop the table out of replication
-and recreate it, right?</para>
-</question>
-
-<answer><para> Actually, this is a scenario which works out remarkably
-cleanly. &slony1; does indeed make intense use of the primary key
-columns, but actually does so in a manner that allows this sort of
-change to be made very nearly transparently.</para>
-
-<para> Suppose you revise a column name, as with the SQL DDL <command>
-alter table accounts alter column aid rename to cid; </command> This
-revises the names of the columns in the table; it
-<emphasis>simultaneously</emphasis> renames the names of the columns
-in the primary key index. The result is that the normal course of
-things is that altering a column name affects both aspects
-simultaneously on a given node.</para>
-
-<para> The <emphasis>ideal</emphasis> and proper handling of this
-change would involve using <xref linkend="stmtddlscript"/> to deploy
-the alteration, which ensures it is applied at exactly the right point
-in the transaction stream on each node.</para>
-
-<para> Interestingly, that isn't forcibly necessary. As long as the
-alteration is applied on the replication set's origin before
-application on subscribers, things won't break irrepairably. Some
-<command>SYNC</command> events that do not include changes to the
-altered table can make it through without any difficulty... At the
-point that the first update to the table is drawn in by a subscriber,
-<emphasis>that</emphasis> is the point at which
-<command>SYNC</command> events will start to fail, as the provider
-will indicate the <quote>new</quote> set of columns whilst the
-subscriber still has the <quote>old</quote> ones. If you then apply
-the alteration to the subscriber, it can retry the
-<command>SYNC</command>, at which point it will, finding the
-<quote>new</quote> column names, work just fine.
-</para> </answer></qandaentry>
-
-<qandaentry id="v72upgrade">
-<question> <para> I have a &postgres; 7.2-based system that I
-<emphasis>really, really</emphasis> want to use &slony1; to help me
-upgrade it to 8.0. What is involved in getting &slony1; to work for
-that?</para>
-</question>
-
-<answer> <para> Rod Taylor has reported the following...
-</para>
-
-<para> This is approximately what you need to do:</para>
-<itemizedlist>
-<listitem><para>Take the 7.3 templates and copy them to 7.2 -- or otherwise
- hardcode the version your using to pick up the 7.3 templates </para></listitem>
-<listitem><para>Remove all traces of schemas from the code and sql templates. I
- basically changed the "." to an "_". </para></listitem>
-<listitem><para> Bunch of work related to the XID datatype and functions. For
- example, Slony creates CASTs for the xid to xxid and back -- but
- 7.2 cannot create new casts that way so you need to edit system
- tables by hand. I recall creating an Operator Class and editing
- several functions as well. </para></listitem>
-<listitem><para>sl_log_1 will have severe performance problems with any kind of
- data volume. This required a number of index and query changes
- to optimize for 7.2. 7.3 and above are quite a bit smarter in
- terms of optimizations they can apply. </para></listitem>
-<listitem><para> Don't bother trying to make sequences work. Do them by hand
- after the upgrade using pg_dump and grep. </para></listitem>
-</itemizedlist>
-<para> Of course, now that you have done all of the above, it's not compatible
-with standard Slony now. So you either need to implement 7.2 in a less
-hackish way, or you can also hack up slony to work without schemas on
-newer versions of &postgres; so they can talk to each other.
-</para>
-<para> Almost immediately after getting the DB upgraded from 7.2 to 7.4, we
-deinstalled the hacked up Slony (by hand for the most part), and started
-a migration from 7.4 to 7.4 on a different machine using the regular
-Slony. This was primarily to ensure we didn't keep our system catalogues
-which had been manually fiddled with.
-</para>
-
-<para> All that said, we upgraded a few hundred GB from 7.2 to 7.4
-with about 30 minutes actual downtime (versus 48 hours for a dump /
-restore cycle) and no data loss.
-</para>
-</answer>
-
-<answer> <para> That represents a sufficiently ugly set of
-<quote>hackery</quote> that the developers are exceedingly reluctant
-to let it anywhere near to the production code. If someone were
-interested in <quote>productionizing</quote> this, it would probably
-make sense to do so based on the &slony1; 1.0 branch, with the express
-plan of <emphasis>not</emphasis> trying to keep much in the way of
-forwards compatibility or long term maintainability of replicas.
-</para>
-
-<para> You should only head down this road if you are sufficiently
-comfortable with &postgres; and &slony1; that you are prepared to hack
-pretty heavily with the code. </para> </answer>
-</qandaentry>
-
-<qandaentry>
-<question> <para> I had a network <quote>glitch</quote> that led to my
-using <xref linkend="stmtfailover"/> to fail over to an alternate node.
-The failure wasn't a disk problem that would corrupt databases; why do
-I need to rebuild the failed node from scratch? </para></question>
-
-<answer><para> The action of <xref linkend="stmtfailover"/> is to
-<emphasis>abandon</emphasis> the failed node so that no more &slony1;
-activity goes to or from that node. As soon as that takes place, the
-failed node will progressively fall further and further out of sync.
-</para></answer>
-
-<answer><para> The <emphasis>big</emphasis> problem with trying to
-recover the failed node is that it may contain updates that never made
-it out of the origin. If they get retried, on the new origin, you may
-find that you have conflicting updates. In any case, you do have a
-sort of <quote>logical</quote> corruption of the data even if there
-never was a disk failure making it <quote>physical.</quote>
-</para></answer>
-
-<answer><para> As discusssed in <xref linkend="failover"/>, using <xref
-linkend="stmtfailover"/> should be considered a <emphasis>last
-resort</emphasis> as it implies that you are abandoning the origin
-node as being corrupted. </para></answer>
-</qandaentry>
-
-
-<qandaentry> <question><para> After notification of a subscription on
-<emphasis>another</emphasis> node, replication falls over on one of
-the subscribers, with the following error message:</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> This is then followed by a series of failed syncs as the <xref
-linkend="slon"/> shuts down:</para>
-
-<screen>
-DEBUG2 remoteListenThread_1: queue event 1,4897517 SYNC
-DEBUG2 remoteListenThread_1: queue event 1,4897518 SYNC
-DEBUG2 remoteListenThread_1: queue event 1,4897519 SYNC
-DEBUG2 remoteListenThread_1: queue event 1,4897520 SYNC
-DEBUG2 remoteWorker_event: ignore new events due to shutdown
-DEBUG2 remoteListenThread_1: queue event 1,4897521 SYNC
-DEBUG2 remoteWorker_event: ignore new events due to shutdown
-DEBUG2 remoteListenThread_1: queue event 1,4897522 SYNC
-DEBUG2 remoteWorker_event: ignore new events due to shutdown
-DEBUG2 remoteListenThread_1: queue event 1,4897523 SYNC
-</screen>
-
-</question>
-
-<answer><para> If you see a &lslon; shutting down with
-<emphasis>ignore new events due to shutdown</emphasis> log entries,
-you typically need to step back in the log to
-<emphasis>before</emphasis> they started failing to see indication of
-the root cause of the problem. </para></answer>
-
-<answer><para> In this particular case, the problem was that some of
-the <xref linkend="stmtstorepath"/> commands had not yet made it to
-node 4 before the <xref linkend="stmtsubscribeset"/> command
-propagated. </para>
-
-<para>This demonstrates yet another example of the need to not do
-things in a rush; you need to be sure things are working right
-<emphasis>before</emphasis> making further configuration changes.
-</para></answer>
-
-</qandaentry>
-
-<qandaentry>
-
-<question><para>I just used <xref linkend="stmtmoveset"/> to move the
-origin to a new node. Unfortunately, some subscribers are still
-pointing to the former origin node, so I can't take it out of service
-for maintenance without stopping them from getting updates. What do I
-do? </para></question>
-
-<answer><para> You need to use <xref linkend="stmtsubscribeset"/> to
-alter the subscriptions for those nodes to have them subscribe to a
-provider that <emphasis>will</emphasis> be sticking around during the
-maintenance.</para>
-
-<warning> <para> What you <emphasis>don't</emphasis> do is to <xref
-linkend="stmtunsubscribeset"/>; that would require reloading all data
-for the nodes from scratch later.
-
-</para></warning>
-</answer>
-</qandaentry>
-
-<qandaentry>
-<question><para> After notification of a subscription on
-<emphasis>another</emphasis> node, replication falls over, starting
-with the following error message:</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> This is then followed by a series of failed syncs as the <xref
-linkend="slon"/> shuts down:
-
-<screen>
-DEBUG2 remoteListenThread_1: queue event 1,4897517 SYNC
-DEBUG2 remoteListenThread_1: queue event 1,4897518 SYNC
-DEBUG2 remoteListenThread_1: queue event 1,4897519 SYNC
-DEBUG2 remoteListenThread_1: queue event 1,4897520 SYNC
-DEBUG2 remoteWorker_event: ignore new events due to shutdown
-DEBUG2 remoteListenThread_1: queue event 1,4897521 SYNC
-DEBUG2 remoteWorker_event: ignore new events due to shutdown
-DEBUG2 remoteListenThread_1: queue event 1,4897522 SYNC
-DEBUG2 remoteWorker_event: ignore new events due to shutdown
-DEBUG2 remoteListenThread_1: queue event 1,4897523 SYNC
-</screen>
-
-</para></question>
-
-<answer><para> If you see a &lslon; shutting down with
-<emphasis>ignore new events due to shutdown</emphasis> log entries,
-you'll typically have to step back to <emphasis>before</emphasis> they
-started failing to see indication of the root cause of the problem.
-
-</para></answer>
-
-<answer><para> In this particular case, the problem was that some of
-the <xref linkend="stmtstorepath"/> commands had not yet made it to
-node 4 before the <xref linkend="stmtsubscribeset"/> command
-propagated. </para>
-
-<para>This is yet another example of the need to not do things too
-terribly quickly; you need to be sure things are working right
-<emphasis>before</emphasis> making further configuration changes.
-</para></answer>
-
-</qandaentry>
-
-<qandaentry>
-<question> <para> Is the ordering of tables in a set significant?</para>
-</question>
-<answer> <para> Most of the time, it isn't. You might imagine it of
-some value to order the tables in some particular way in order that
-<quote>parent</quote> entries would make it in before their <quote>children</quote>
-in some foreign key relationship; that <emphasis>isn't</emphasis> the case since
-foreign key constraint triggers are turned off on subscriber nodes.
-</para>
-</answer>
-
-<answer> <para>(Jan Wieck comments:) The order of table ID's is only
-significant during a <xref linkend="stmtlockset"/> in preparation of
-switchover. If that order is different from the order in which an
-application is acquiring its locks, it can lead to deadlocks that
-abort either the application or <application>slon</application>.
-</para>
-</answer>
-
-<answer><para> (David Parker) I ran into one other case where the
-ordering of tables in the set was significant: in the presence of
-inherited tables. If a child table appears before its parent in a set,
-then the initial subscription will end up deleting that child table
-after it has possibly already received data, because the
-<command>copy_set</command> logic does a <command>delete</command>,
-not a <command>delete only</command>, so the delete of the parent will
-delete the new rows in the child as well.
-</para>
-</answer>
-</qandaentry>
-
-<qandaentry>
-
-<question><para> If you have a <xref linkend="slonik"/> script
-something like this, it will hang on you and never complete, because
-you can't have <command>wait for event</command> inside a
-<command>try</command> block. A <command>try</command> block is
-executed as one transaction, and the event that you are waiting for
-can never arrive inside the scope of the transaction.</para>
-
-<programlisting>
-try {
- echo 'Moving set 1 to node 3';
- lock set (id=1, origin=1);
- echo 'Set locked';
- wait for event (origin = 1, confirmed = 3);
- echo 'Moving set';
- move set (id=1, old origin=1, new origin=3);
- echo 'Set moved - waiting for event to be confirmed by node 3';
- wait for event (origin = 1, confirmed = 3);
- echo 'Confirmed';
-} on error {
- echo 'Could not move set for cluster foo';
- unlock set (id=1, origin=1);
- exit -1;
-}
-</programlisting></question>
-
-<answer><para> You must not invoke <xref linkend="stmtwaitevent"/>
-inside a <quote>try</quote> block.</para></answer>
-
-</qandaentry>
-
-<qandaentry>
-<question><para>Slony-I: cannot add table to currently subscribed set 1</para>
-
-<para> I tried to add a table to a set, and got the following message:
-
-<screen>
- Slony-I: cannot add table to currently subscribed set 1
-</screen></para></question>
-
-<answer><para> You cannot add tables to sets that already have
-subscribers.</para>
-
-<para>The workaround to this is to create <emphasis>ANOTHER</emphasis>
-set, add the new tables to that new set, subscribe the same nodes
-subscribing to "set 1" to the new set, and then merge the sets
-together.</para>
-</answer></qandaentry>
-
-<qandaentry>
-<question><para>
-ERROR: duplicate key violates unique constraint "sl_table-pkey"</para>
-
-<para>I tried setting up a second replication set, and got the following error:
-
-<screen>
-stdin:9: Could not create subscription set 2 for oxrslive!
-stdin:11: PGRES_FATAL_ERROR select "_oxrslive".setAddTable(2, 1, 'public.replic_test', 'replic_test__Slony-I_oxrslive_rowID_key', 'Table public.replic_test without primary key'); - ERROR: duplicate key violates unique constraint "sl_table-pkey"
-CONTEXT: PL/pgSQL function "setaddtable_int" line 71 at SQL statement
-</screen></para></question>
-
-<answer><para> The table IDs used in <xref linkend="stmtsetaddtable"/>
-are required to be unique <emphasis>ACROSS ALL SETS</emphasis>. Thus,
-you can't restart numbering at 1 for a second set; if you are
-numbering them consecutively, a subsequent set has to start with IDs
-after where the previous set(s) left off.</para> </answer>
-</qandaentry>
-
-<qandaentry>
-<question><para> One of my nodes fell over (&lslon; / postmaster was
-down) and nobody noticed for several days. Now, when the &lslon; for
-that node starts up, it runs for about five minutes, then terminates,
-with the error message: <command>ERROR: remoteListenThread_%d: timeout
-for event selection</command> What's wrong, and what do I do? </para>
-</question>
-
-<answer><para> The problem is that the listener thread (in
-<filename>src/slon/remote_listener.c</filename>) timed out when trying
-to determine what events were outstanding for that node. By default,
-the query will run for five minutes; if there were many days worth of
-outstanding events, this might take too long.
- </para> </answer>
-
-<answer><para> On versions of &slony1; before 1.1.7, 1.2.7, and 1.3, one answer would be to increase the timeout in
-<filename>src/slon/remote_listener.c</filename>, recompile &lslon;, and retry. </para> </answer>
-
-<answer><para> Another would be to treat the node as having failed,
-and use the &lslonik; command <xref linkend="stmtdropnode"/> to drop the
-node, and recreate it. If the database is heavily updated, it may
-well be cheaper to do this than it is to find a way to let it catch
-up. </para> </answer>
-
-<answer><para> In newer versions of &slony1;, there is a new
-configuration parameter called <xref
-linkend="slon-config-remote-listen-timeout"/>; you'd alter the config
-file to increase the timeout, and try again. Of course, as mentioned
-above, it could be faster to drop the node and recreate it than to let
-it catch up across a week's worth of updates... </para> </answer>
-
-</qandaentry>
-
-</qandadiv>
-<qandadiv id="faqperformance"> <title> &slony1; FAQ: Performance Issues </title>
-
-<qandaentry id="longtxnsareevil">
-
-<question><para> Replication has been slowing down, I'm seeing
-<command> FETCH 100 FROM LOG </command> queries running for a long
-time, <xref linkend="table.sl-log-1"/> is growing, and performance is,
-well, generally getting steadily worse. </para>
-</question>
-
-<answer> <para> There are actually a number of possible causes for
-this sort of thing. There is a question involving similar pathology
-where the problem is that <link linkend="pglistenerfull">
-&pglistener; grows because it is not vacuumed. </link>
-</para>
-
-<para> Another <quote> proximate cause </quote> for this growth is for
-there to be a connection connected to the node that sits <command>
-IDLE IN TRANSACTION </command> for a very long time. </para>
-
-<para> That open transaction will have multiple negative effects, all
-of which will adversely affect performance:</para>
-
-<itemizedlist>
-
-<listitem><para> Vacuums on all tables, including &pglistener;, will
-not clear out dead tuples from before the start of the idle
-transaction. </para> </listitem>
-
-<listitem><para> The cleanup thread will be unable to clean out
-entries in <xref linkend="table.sl-log-1"/> and <xref
-linkend="table.sl-seqlog"/>, with the result that these tables will
-grow, ceaselessly, until the transaction is closed. </para>
-</listitem>
-</itemizedlist>
-</answer>
-
-<answer> <para> You can monitor for this condition inside the database
-only if the &postgres; <filename> postgresql.conf </filename>
-parameter <envar>stats_command_string</envar> is set to true. If that
-is set, then you may submit the query <command> select * from
-pg_stat_activity where current_query like '%IDLE% in transaction';
-</command> which will find relevant activity. </para> </answer>
-
-<answer> <para> You should also be able to search for <quote> idle in
-transaction </quote> in the process table to find processes that are
-thus holding on to an ancient transaction. </para> </answer>
-
-<answer> <para> It is also possible (though rarer) for the problem to
-be a transaction that is, for some other reason, being held open for a
-very long time. The <envar> query_start </envar> time in <envar>
-pg_stat_activity </envar> may show you some query that has been
-running way too long. </para> </answer>
-
-<answer> <para> There are plans for &postgres; to have a timeout
-parameter, <envar> open_idle_transaction_timeout </envar>, which would
-cause old transactions to time out after some period of disuse. Buggy
-connection pool logic is a common culprit for this sort of thing.
-There are plans for <productname> <link linkend="pgpool"> pgpool
-</link> </productname> to provide a better alternative, eventually,
-where connections would be shared inside a connection pool implemented
-in C. You may have some more or less buggy connection pool in your
-Java or PHP application; if a small set of <emphasis> real </emphasis>
-connections are held in <productname>pgpool</productname>, that will
-hide from the database the fact that the application imagines that
-numerous of them are left idle in transaction for hours at a time.
-</para> </answer>
-
-</qandaentry>
-
-<qandaentry id="faq17">
-<question><para>After dropping a node, <xref linkend="table.sl-log-1"/>
-isn't getting purged out anymore.</para></question>
-
-<answer><para> This is a common scenario in versions before 1.0.5, as
-the <quote>clean up</quote> that takes place when purging the node
-does not include purging out old entries from the &slony1; table,
-<xref linkend="table.sl-confirm"/>, for the recently departed
-node.</para>
-
-<para> The node is no longer around to update confirmations of what
-syncs have been applied on it, and therefore the cleanup thread that
-purges log entries thinks that it can't safely delete entries newer
-than the final <xref linkend="table.sl-confirm"/> entry, which rather
-curtails the ability to purge out old logs.</para>
-
-<para>Diagnosis: Run the following query to see if there are any
-<quote>phantom/obsolete/blocking</quote> <xref
-linkend="table.sl-confirm"/> entries:
-
-<screen>
-oxrsbar=# select * 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);
- con_origin | con_received | con_seqno | con_timestamp
-------------+--------------+-----------+----------------------------
- 4 | 501 | 83999 | 2004-11-09 19:57:08.195969
- 1 | 2 | 3345790 | 2004-11-14 10:33:43.850265
- 2 | 501 | 102718 | 2004-11-14 10:33:47.702086
- 501 | 2 | 6577 | 2004-11-14 10:34:45.717003
- 4 | 5 | 83999 | 2004-11-14 21:11:11.111686
- 4 | 3 | 83999 | 2004-11-24 16:32:39.020194
-(6 rows)
-</screen></para>
-
-<para>In version 1.0.5, the <xref linkend="stmtdropnode"/> function
-purges out entries in <xref linkend="table.sl-confirm"/> for the
-departing node. In earlier versions, this needs to be done manually.
-Supposing the node number is 3, then the query would be:
-
-<screen>
-delete from _namespace.sl_confirm where con_origin = 3 or con_received = 3;
-</screen></para>
-
-<para>Alternatively, to go after <quote>all phantoms,</quote> you could use
-<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>General <quote>due diligence</quote> dictates starting with a
-<command>BEGIN</command>, looking at the contents of
-<xref linkend="table.sl-confirm"/> before, ensuring that only the expected
-records are purged, and then, only after that, confirming the change
-with a <command>COMMIT</command>. If you delete confirm entries for
-the wrong node, that could ruin your whole day.</para>
-
-<para>You'll need to run this on each node that remains...</para>
-
-<para>Note that as of 1.0.5, this is no longer an issue at all, as it
-purges unneeded entries from <xref linkend="table.sl-confirm"/> in two
-places:
-
-<itemizedlist>
-<listitem><para> At the time a node is dropped</para></listitem>
-
-<listitem><para> At the start of each
-<function>cleanupEvent</function> run, which is the event in which old
-data is purged from <xref linkend="table.sl-log-1"/> and <xref
-linkend="table.sl-seqlog"/></para></listitem> </itemizedlist></para>
-</answer>
-</qandaentry>
-
-<qandaentry>
-
-<question><para>The <application>slon</application> spent the weekend out of
-commission [for some reason], and it's taking a long time to get a
-sync through.</para></question>
-
-<answer><para> You might want to take a look at the <xref
-linkend="table.sl-log-1"/>/<xref linkend="table.sl-log-2"/> tables, and
-do a summary to see if there are any really enormous &slony1;
-transactions in there. Up until at least 1.0.2, there needs to be a
-&lslon; connected to the origin in order for
-<command>SYNC</command> events to be generated.</para>
-
-<para>If none are being generated, then all of the updates until the
-next one is generated will collect into one rather enormous &slony1;
-transaction.</para>
-
-<para>Conclusion: Even if there is not going to be a subscriber
-around, you <emphasis>really</emphasis> want to have a
-<application>slon</application> running to service the origin
-node.</para>
-
-<para>&slony1; 1.1 provides a stored procedure that allows
-<command>SYNC</command> counts to be updated on the origin based on a
-<application>cron</application> job even if there is no <xref
-linkend="slon"/> daemon running.</para> </answer></qandaentry>
-
-<qandaentry id="PGLISTENERFULL">
-<question><para>Some nodes start consistently falling behind</para>
-
-<para>I have been running &slony1; on a node for a while, and am
-seeing system performance suffering.</para>
-
-<para>I'm seeing long running queries of the form:
-<screen>
- fetch 100 from LOG;
-</screen></para></question>
-
-<answer><para> This can be characteristic of &pglistener; (which is
-the table containing <command>NOTIFY</command> data) having plenty of
-dead tuples in it. That makes <command>NOTIFY</command> events take a
-long time, and causes the affected node to gradually fall further and
-further behind.</para>
-
-<para>You quite likely need to do a <command>VACUUM FULL</command> on
-&pglistener;, to vigorously clean it out, and need to vacuum
-&pglistener; really frequently. Once every five minutes would likely
-be AOK.</para>
-
-<para> Slon daemons already vacuum a bunch of tables, and
-<filename>cleanup_thread.c</filename> contains a list of tables that
-are frequently vacuumed automatically. In &slony1; 1.0.2,
-&pglistener; is not included. In 1.0.5 and later, it is regularly
-vacuumed, so this should cease to be a direct issue. In version 1.2,
-&pglistener; will only be used when a node is only receiving events
-periodically, which means that the issue should mostly go away even in
-the presence of evil long running transactions...</para>
-
-<para>There is, however, still a scenario where this will still
-<quote>bite.</quote> Under MVCC, vacuums cannot delete tuples that
-were made <quote>obsolete</quote> at any time after the start time of
-the eldest transaction that is still open. Long running transactions
-will cause trouble, and should be avoided, even on subscriber
-nodes.</para> </answer></qandaentry>
-
-<qandaentry> <question> <para> I have submitted a <xref
-linkend="stmtmoveset"/> / <xref linkend="stmtddlscript"/> request, and
-it seems to be stuck on one of my nodes. &slony1; logs aren't
-displaying any errors or warnings </para> </question>
-
-<answer> <para> Is it possible that you are running
-<application>pg_autovacuum</application>, and it has taken out locks
-on some tables in the replication set? That would somewhat-invisibly
-block &slony1; from performing operations that require <link
-linkend="locking"> acquisition of exclusive locks. </link> </para>
-
-<para> You might check for these sorts of locks using the following
-query: <command> select l.*, c.relname from pg_locks l, pg_class c
-where c.oid = l.relation ; </command> A
-<envar>ShareUpdateExclusiveLock</envar> lock will block the &slony1;
-operations that need their own exclusive locks, which are likely
-queued up, marked as not being granted. </para>
-</answer> </qandaentry>
-
-<qandaentry>
-
-<question><para> I'm noticing in the logs that a &lslon; is frequently
-switching in and out of <quote>polling</quote> mode as it is
-frequently reporting <quote>LISTEN - switch from polling mode to use
-LISTEN</quote> and <quote>UNLISTEN - switch into polling
-mode</quote>. </para> </question>
-
-<answer><para> The thresholds for switching between these modes are
-controlled by the configuration parameters <xref
-linkend="slon-config-sync-interval"/> and <xref
-linkend="slon-config-sync-interval-timeout"/>; if the timeout value
-(which defaults to 10000, implying 10s) is kept low, that makes it
-easy for the &lslon; to decide to return to <quote>listening</quote>
-mode. You may want to increase the value of the timeout
-parameter. </para>
-</answer>
-</qandaentry>
-
-
-</qandadiv>
-<qandadiv id="faqbugs"> <title> &slony1; FAQ: &slony1; Bugs in Elder Versions </title>
-<qandaentry>
-<question><para>The &lslon; processes servicing my
-subscribers are growing to enormous size, challenging system resources
-both in terms of swap space as well as moving towards breaking past
-the 2GB maximum process size on my system. </para>
-
-<para> By the way, the data that I am replicating includes some rather
-large records. We have records that are tens of megabytes in size.
-Perhaps that is somehow relevant? </para> </question>
-
-<answer> <para> Yes, those very large records are at the root of the
-problem. The problem is that &lslon; normally draws in
-about 100 records at a time when a subscriber is processing the query
-which loads data from the provider. Thus, if the average record size
-is 10MB, this will draw in 1000MB of data which is then transformed
-into <command>INSERT</command> or <command>UPDATE</command>
-statements, in the &lslon; process' memory.</para>
-
-<para> That obviously leads to &lslon; growing to a
-fairly tremendous size. </para>
-
-<para> The number of records that are fetched is controlled by the
-value <envar> SLON_DATA_FETCH_SIZE </envar>, which is defined in the
-file <filename>src/slon/slon.h</filename>. The relevant extract of
-this is shown below. </para>
-
-<programlisting>
-#ifdef SLON_CHECK_CMDTUPLES
-#define SLON_COMMANDS_PER_LINE 1
-#define SLON_DATA_FETCH_SIZE 100
-#define SLON_WORKLINES_PER_HELPER (SLON_DATA_FETCH_SIZE * 4)
-#else
-#define SLON_COMMANDS_PER_LINE 10
-#define SLON_DATA_FETCH_SIZE 10
-#define SLON_WORKLINES_PER_HELPER (SLON_DATA_FETCH_SIZE * 50)
-#endif
-</programlisting>
-
-<para> If you are experiencing this problem, you might modify the
-definition of <envar> SLON_DATA_FETCH_SIZE </envar>, perhaps reducing
-by a factor of 10, and recompile &lslon;. There are two
-definitions as <envar> SLON_CHECK_CMDTUPLES</envar> allows doing some
-extra monitoring to ensure that subscribers have not fallen out of
-SYNC with the provider. By default, this option is turned off, so the
-default modification to make is to change the second definition of
-<envar> SLON_DATA_FETCH_SIZE </envar> from 10 to 1. </para> </answer>
-
-<answer><para> In version 1.2, configuration values <xref
-linkend="slon-config-max-rowsize"/> and <xref
-linkend="slon-config-max-largemem"/> are associated with a new
-algorithm that changes the logic as follows. Rather than fetching 100
-rows worth of data at a time:</para>
-
-<itemizedlist>
-
-<listitem><para> The <command>fetch from LOG</command> query will draw
-in 500 rows at a time where the size of the attributes does not exceed
-<xref linkend="slon-config-max-rowsize"/>. With default values, this
-restricts this aspect of memory consumption to about 8MB. </para>
-</listitem>
-
-<listitem><para> Tuples with larger attributes are loaded until
-aggregate size exceeds the parameter <xref
-linkend="slon-config-max-largemem"/>. By default, this restricts
-consumption of this sort to about 5MB. This value is not a strict
-upper bound; if you have a tuple with attributes 50MB in size, it
-forcibly <emphasis>must</emphasis> be loaded into memory. There is no
-way around that. But &lslon; at least won't be trying
-to load in 100 such records at a time, chewing up 10GB of memory by
-the time it's done. </para> </listitem>
-</itemizedlist>
-
-<para> This should alleviate problems people have been experiencing
-when they sporadically have series' of very large tuples. </para>
-</answer>
-</qandaentry>
-
-<qandaentry id="faqunicode"> <question> <para> I am trying to replicate
-<envar>UNICODE</envar> data from &postgres; 8.0 to &postgres; 8.1, and
-am experiencing problems. </para>
-</question>
-
-<answer> <para> &postgres; 8.1 is quite a lot more strict about what
-UTF-8 mappings of Unicode characters it accepts as compared to version
-8.0.</para>
-
-<para> If you intend to use &slony1; to update an older database to 8.1, and
-might have invalid UTF-8 values, you may be for an unpleasant
-surprise.</para>
-
-<para> Let us suppose we have a database running 8.0, encoding in UTF-8.
-That database will accept the sequence <command>'\060\242'</command> as UTF-8 compliant,
-even though it is really not. </para>
-
-<para> If you replicate into a &postgres; 8.1 instance, it will complain
-about this, either at subscribe time, where &slony1; will complain
-about detecting an invalid Unicode sequence during the COPY of the
-data, which will prevent the subscription from proceeding, or, upon
-adding data, later, where this will hang up replication fairly much
-irretrievably. (You could hack on the contents of sl_log_1, but
-that quickly gets <emphasis>really</emphasis> unattractive...)</para>
-
-<para>There have been discussions as to what might be done about this. No
-compelling strategy has yet emerged, as all are unattractive. </para>
-
-<para>If you are using Unicode with &postgres; 8.0, you run a
-considerable risk of corrupting data. </para>
-
-<para> If you use replication for a one-time conversion, there is a risk of
-failure due to the issues mentioned earlier; if that happens, it
-appears likely that the best answer is to fix the data on the 8.0
-system, and retry. </para>
-
-<para> In view of the risks, running replication between versions seems to be
-something you should not keep running any longer than is necessary to
-migrate to 8.1. </para>
-
-<para> For more details, see the <ulink url=
-"http://archives.postgresql.org/pgsql-hackers/2005-12/msg00181.php">
-discussion on postgresql-hackers mailing list. </ulink>. </para>
-</answer>
-</qandaentry>
-
-<qandaentry>
-<question> <para> I am running &slony1; 1.1 and have a 4+ node setup
-where there are two subscription sets, 1 and 2, that do not share any
-nodes. I am discovering that confirmations for set 1 never get to the
-nodes subscribing to set 2, and that confirmations for set 2 never get
-to nodes subscribing to set 1. As a result, <xref
-linkend="table.sl-log-1"/> grows and grows and is never purged. This
-was reported as &slony1; <ulink
-url="http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1485">
-bug 1485 </ulink>.
-</para>
-</question>
-
-<answer><para> Apparently the code for
-<function>RebuildListenEntries()</function> does not suffice for this
-case.</para>
-
-<para> <function> RebuildListenEntries()</function> will be replaced
-in &slony1; version 1.2 with an algorithm that covers this case. </para>
-
-<para> In the interim, you'll want to manually add some <xref
-linkend="table.sl-listen"/> entries using <xref
-linkend="stmtstorelisten"/> or <function>storeListen()</function>,
-based on the (apparently not as obsolete as we thought) principles
-described in <xref linkend="listenpaths"/>.
-
-</para></answer>
-</qandaentry>
-
-<qandaentry>
-<question> <para> I am finding some multibyte columns (Unicode, Big5)
-are being truncated a bit, clipping off the last character. Why?
-</para> </question>
-
-<answer> <para> This was a bug present until a little after &slony1;
-version 1.1.0; the way in which columns were being captured by the
-<function>logtrigger()</function> function could clip off the last
-byte of a column represented in a multibyte format. Check to see that
-your version of <filename>src/backend/slony1_funcs.c</filename> is
-1.34 or better; the patch was introduced in CVS version 1.34 of that
-file. </para> </answer>
-</qandaentry>
-
-<qandaentry id="sequenceset"><question><para> <ulink url=
-"http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1226">
-Bug #1226 </ulink> indicates an error condition that can come up if
-you have a replication set that consists solely of sequences. </para>
-</question>
-
-<answer> <para> The short answer is that having a replication set
-consisting only of sequences is not a <link linkend="bestpractices">
-best practice.</link> </para>
-</answer>
-
-<answer>
-<para> The problem with a sequence-only set comes up only if you have
-a case where the only subscriptions that are active for a particular
-subscriber to a particular provider are for
-<quote>sequence-only</quote> sets. If a node gets into that state,
-replication will fail, as the query that looks for data from <xref
-linkend="table.sl-log-1"/> has no tables to find, and the query will be
-malformed, and fail. If a replication set <emphasis>with</emphasis>
-tables is added back to the mix, everything will work out fine; it
-just <emphasis>seems</emphasis> scary.
-</para>
-
-<para> This problem should be resolved some time after &slony1;
-1.1.0.</para>
-</answer>
-</qandaentry>
-
-<qandaentry>
-<question><para>I need to drop a table from a replication set</para></question>
-<answer><para>
-This can be accomplished several ways, not all equally desirable ;-).
-
-<itemizedlist>
-
-<listitem><para> You could drop the whole replication set, and
-recreate it with just the tables that you need. Alas, that means
-recopying a whole lot of data, and kills the usability of the cluster
-on the rest of the set while that's happening.</para></listitem>
-
-<listitem><para> If you are running 1.0.5 or later, there is the
-command SET DROP TABLE, which will "do the trick."</para></listitem>
-
-<listitem><para> If you are still using 1.0.1 or 1.0.2, the
-<emphasis>essential functionality of <xref linkend="stmtsetdroptable"/>
-involves the functionality in <function>droptable_int()</function>.
-You can fiddle this by hand by finding the table ID for the table you
-want to get rid of, which you can find in <xref
-linkend="table.sl-table"/>, and then run the following three queries,
-on each host:</emphasis>
-
-<programlisting>
- select _slonyschema.alterTableRestore(40);
- select _slonyschema.tableDropKey(40);
- delete from _slonyschema.sl_table where tab_id = 40;
-</programlisting></para>
-
-<para>The schema will obviously depend on how you defined the &slony1;
-cluster. The table ID, in this case, 40, will need to change to the
-ID of the table you want to have go away.</para>
-
-<para> You'll have to run these three queries on all of the nodes,
-preferably firstly on the origin node, so that the dropping of this
-propagates properly. Implementing this via a <xref linkend="slonik"/>
-statement with a new &slony1; event would do that. Submitting the
-three queries using <xref linkend="stmtddlscript"/> could do that.
-Also possible would be to connect to each database and submit the
-queries by hand.</para></listitem> </itemizedlist></para>
-</answer>
-</qandaentry>
-
-<qandaentry>
-<question><para>I need to drop a sequence from a replication set</para></question>
-
-<answer><para></para><para>If you are running 1.0.5 or later, there is
-a <xref linkend="stmtsetdropsequence"/> command in Slonik to allow you
-to do this, parallelling <xref linkend="stmtsetdroptable"/>.</para>
-
-<para>If you are running 1.0.2 or earlier, the process is a bit more manual.</para>
-
-<para>Supposing I want to get rid of the two sequences listed below,
-<envar>whois_cachemgmt_seq</envar> and
-<envar>epp_whoi_cach_seq_</envar>, we start by needing the
-<envar>seq_id</envar> values.
-
-<screen>
-oxrsorg=# select * from _oxrsorg.sl_sequence where seq_id in (93,59);
- seq_id | seq_reloid | seq_set | seq_comment
---------+------------+---------+-------------------------------------
- 93 | 107451516 | 1 | Sequence public.whois_cachemgmt_seq
- 59 | 107451860 | 1 | Sequence public.epp_whoi_cach_seq_
-(2 rows)
-</screen></para>
-
-<para>The data that needs to be deleted to stop Slony from continuing to
-replicate these are thus:
-
-<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>Those two queries could be submitted to all of the nodes via
-&funddlscript; / <xref
-linkend="stmtddlscript"/>, thus eliminating the sequence everywhere
-<quote>at once.</quote> Or they may be applied by hand to each of the
-nodes.</para>
-
-<para>Similarly to <xref linkend="stmtsetdroptable"/>, this is
-implemented &slony1; version 1.0.5 as <xref
-linkend="stmtsetdropsequence"/>.</para></answer></qandaentry>
-
-</qandadiv>
-
-<qandadiv id="faqobsolete"> <title> &slony1; FAQ: Hopefully Obsolete Issues </title>
-
-<qandaentry>
-<question><para> &lslon; does not restart after
-crash</para>
-
-<para> After an immediate stop of &postgres; (simulation of system
-crash) in &pglistener; a tuple with <command>
-relname='_${cluster_name}_Restart'</command> exists. slon doesn't
-start because it thinks another process is serving the cluster on this
-node. What can I do? The tuples can't be dropped from this
-relation.</para>
-
-<para> The logs claim that <blockquote><para>Another slon daemon is
-serving this node already</para></blockquote></para></question>
-
-<answer><para> The problem is that the system table &pglistener;, used
-by &postgres; to manage event notifications, contains some entries
-that are pointing to backends that no longer exist. The new <xref
-linkend="slon"/> instance connects to the database, and is convinced,
-by the presence of these entries, that an old
-<application>slon</application> is still servicing this &slony1;
-node.</para>
-
-<para> The <quote>trash</quote> in that table needs to be thrown
-away.</para>
-
-<para>It's handy to keep a slonik script similar to the following to
-run in such cases:
-
-<programlisting>
-twcsds004[/opt/twcsds004/OXRS/slony-scripts]$ cat restart_org.slonik
-cluster name = oxrsorg ;
-node 1 admin conninfo = 'host=32.85.68.220 dbname=oxrsorg user=postgres port=5532';
-node 2 admin conninfo = 'host=32.85.68.216 dbname=oxrsorg user=postgres port=5532';
-node 3 admin conninfo = 'host=32.85.68.244 dbname=oxrsorg user=postgres port=5532';
-node 4 admin conninfo = 'host=10.28.103.132 dbname=oxrsorg user=postgres port=5532';
-restart node 1;
-restart node 2;
-restart node 3;
-restart node 4;
-</programlisting></para>
-
-<para> <xref linkend="stmtrestartnode"/> cleans up dead notifications
-so that you can restart the node.</para>
-
-<para>As of version 1.0.5, the startup process of slon looks for this
-condition, and automatically cleans it up.</para>
-
-<para> As of version 8.1 of &postgres;, the functions that manipulate
-&pglistener; do not support this usage, so for &slony1; versions after
-1.1.2 (<emphasis>e.g. - </emphasis> 1.1.5), this
-<quote>interlock</quote> behaviour is handled via a new table, and the
-issue should be transparently <quote>gone.</quote> </para>
-
-</answer></qandaentry>
-
-<qandaentry><question><para> I tried the following query which did not work:</para>
-
-<programlisting>
-sdb=# explain select query_start, current_query from pg_locks join
-pg_stat_activity on pid = procpid where granted = true and transaction
-in (select transaction from pg_locks where granted = false);
-
-ERROR: could not find hash function for hash operator 716373
-</programlisting>
-
-<para> It appears the &slony1; <function>xxid</function> functions are
-claiming to be capable of hashing, but cannot actually do so.</para>
-
-
-<para> What's up? </para>
-
-</question>
-
-<answer><para> &slony1; defined an XXID data type and operators on
-that type in order to allow manipulation of transaction IDs that are
-used to group together updates that are associated with the same
-transaction.</para>
-
-<para> Operators were not available for &postgres; 7.3 and earlier
-versions; in order to support version 7.3, custom functions had to be
-added. The <function>=</function> operator was marked as supporting
-hashing, but for that to work properly, the join operator must appear
-in a hash index operator class. That was not defined, and as a
-result, queries (like the one above) that decide to use hash joins
-will fail. </para> </answer>
-
-<answer> <para> This has <emphasis> not </emphasis> been considered a
-<quote>release-critical</quote> bug, as &slony1; does not internally
-generate queries likely to use hash joins. This problem shouldn't
-injure &slony1;'s ability to continue replicating. </para> </answer>
-
-<answer> <para> Future releases of &slony1; (<emphasis>e.g.</emphasis>
-1.0.6, 1.1) will omit the <command>HASHES</command> indicator, so that
-</para> </answer>
-
-<answer> <para> Supposing you wish to repair an existing instance, so
-that your own queries will not run afoul of this problem, you may do
-so as follows: </para>
-
-<programlisting>
-/* cbbrowne@[local]/dba2 slony_test1=*/ \x
-Expanded display is on.
-/* cbbrowne@[local]/dba2 slony_test1=*/ select * from pg_operator where oprname = '='
-and oprnamespace = (select oid from pg_namespace where nspname = 'public');
--[ RECORD 1 ]+-------------
-oprname | =
-oprnamespace | 2200
-oprowner | 1
-oprkind | b
-oprcanhash | t
-oprleft | 82122344
-oprright | 82122344
-oprresult | 16
-oprcom | 82122365
-oprnegate | 82122363
-oprlsortop | 82122362
-oprrsortop | 82122362
-oprltcmpop | 82122362
-oprgtcmpop | 82122360
-oprcode | "_T1".xxideq
-oprrest | eqsel
-oprjoin | eqjoinsel
-
-/* cbbrowne@[local]/dba2 slony_test1=*/ update pg_operator set oprcanhash = 'f' where
-oprname = '=' and oprnamespace = 2200 ;
-UPDATE 1
-</programlisting>
-</answer>
-
-</qandaentry>
-<qandaentry> <question><para> I can do a <command>pg_dump</command>
-and load the data back in much faster than the <command>SUBSCRIBE
-SET</command> runs. Why is that? </para></question>
-
-<answer><para> &slony1; depends on there being an already existant
-index on the primary key, and leaves all indexes alone whilst using
-the &postgres; <command>COPY</command> command to load the data.
-Further hurting performance, the <command>COPY SET</command> event (an
-event that the subscription process generates) starts by deleting the
-contents of tables, which leaves the table full of dead tuples.
-</para>
-
-<para> When you use <command>pg_dump</command> to dump the contents of
-a database, and then load that, creation of indexes is deferred until
-the very end. It is <emphasis>much</emphasis> more efficient to
-create indexes against the entire table, at the end, than it is to
-build up the index incrementally as each row is added to the
-table.</para></answer>
-
-<answer><para> If you can drop unnecessary indices while the
-<command>COPY</command> takes place, that will improve performance
-quite a bit. If you can <command>TRUNCATE</command> tables that
-contain data that is about to be eliminated, that will improve
-performance <emphasis>a lot.</emphasis> </para></answer>
-
-<answer><para> &slony1; version 1.1.5 and later versions should handle
-this automatically; it <quote>thumps</quote> on the indexes in the
-&postgres; catalog to hide them, in much the same way triggers are
-hidden, and then <quote>fixes</quote> the index pointers and reindexes
-the table. </para> </answer>
-</qandaentry>
-
-<qandaentry id="dupkey">
-<question><para>Replication Fails - Unique Constraint Violation</para>
-
-<para>Replication has been running for a while, successfully, when a
-node encounters a <quote>glitch,</quote> and replication logs are filled with
-repetitions of the following:
-
-<screen>
-DEBUG2 remoteWorkerThread_1: syncing set 2 with 5 table(s) from provider 1
-DEBUG2 remoteWorkerThread_1: syncing set 1 with 41 table(s) from provider 1
-DEBUG2 remoteWorkerThread_1: syncing set 5 with 1 table(s) from provider 1
-DEBUG2 remoteWorkerThread_1: syncing set 3 with 1 table(s) from provider 1
-DEBUG2 remoteHelperThread_1_1: 0.135 seconds delay for first row
-DEBUG2 remoteHelperThread_1_1: 0.343 seconds until close cursor
-ERROR remoteWorkerThread_1: "insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '34', '35090538', 'D', '_rserv_ts=''9275244''');
-delete from only public.epp_domain_host where _rserv_ts='9275244';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '34', '35090539', 'D', '_rserv_ts=''9275245''');
-delete from only public.epp_domain_host where _rserv_ts='9275245';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '26', '35090540', 'D', '_rserv_ts=''24240590''');
-delete from only public.epp_domain_contact where _rserv_ts='24240590';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '26', '35090541', 'D', '_rserv_ts=''24240591''');
-delete from only public.epp_domain_contact where _rserv_ts='24240591';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '26', '35090542', 'D', '_rserv_ts=''24240589''');
-delete from only public.epp_domain_contact where _rserv_ts='24240589';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '11', '35090543', 'D', '_rserv_ts=''36968002''');
-delete from only public.epp_domain_status where _rserv_ts='36968002';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '11', '35090544', 'D', '_rserv_ts=''36968003''');
-delete from only public.epp_domain_status where _rserv_ts='36968003';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '24', '35090549', 'I', '(contact_id,status,reason,_rserv_ts) values (''6972897'',''64'','''',''31044208'')');
-insert into public.contact_status (contact_id,status,reason,_rserv_ts) values ('6972897','64','','31044208');insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '24', '35090550', 'D', '_rserv_ts=''18139332''');
-delete from only public.contact_status where _rserv_ts='18139332';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '24', '35090551', 'D', '_rserv_ts=''18139333''');
-delete from only public.contact_status where _rserv_ts='18139333';" ERROR: duplicate key violates unique constraint "contact_status_pkey"
- - qualification was:
-ERROR remoteWorkerThread_1: SYNC aborted
-</screen></para>
-
-<para>The transaction rolls back, and
-&slony1; tries again, and again, and again.
-The problem is with one of the <emphasis>last</emphasis> SQL
-statements, the one with <command>log_cmdtype = 'I'</command>. That
-isn't quite obvious; what takes place is that
-&slony1; groups 10 update queries together
-to diminish the number of network round trips.</para></question>
-
-<answer><para> A <emphasis>certain</emphasis> cause for this has been
-difficult to arrive at.</para>
-
-<para>By the time we notice that there is a problem, the seemingly
-missed delete transaction has been cleaned out of <xref
-linkend="table.sl-log-1"/>, so there appears to be no recovery
-possible. What has seemed necessary, at this point, is to drop the
-replication set (or even the node), and restart replication from
-scratch on that node.</para>
-
-<para>In &slony1; 1.0.5, the handling of purges of <xref
-linkend="table.sl-log-1"/> became more conservative, refusing to purge
-entries that haven't been successfully synced for at least 10 minutes
-on all nodes. It was not certain that that would prevent the
-<quote>glitch</quote> from taking place, but it seemed plausible that
-it might leave enough <xref linkend="table.sl-log-1"/> data to be able
-to do something about recovering from the condition or at least
-diagnosing it more exactly. And perhaps the problem was that <xref
-linkend="table.sl-log-1"/> was being purged too aggressively, and this
-would resolve the issue completely.</para>
-
-<para> It is a shame to have to reconstruct a large replication node
-for this; if you discover that this problem recurs, it may be an idea
-to break replication down into multiple sets in order to diminish the
-work involved in restarting replication. If only one set has broken,
-you may only need to unsubscribe/drop and resubscribe the one set.
-</para>
-
-<para> In one case we found two lines in the SQL error message in the
-log file that contained <emphasis> identical </emphasis> insertions
-into <xref linkend="table.sl-log-1"/>. This <emphasis> ought
-</emphasis> to be impossible as is a primary key on <xref
-linkend="table.sl-log-1"/>. The latest (somewhat) punctured theory
-that comes from <emphasis>that</emphasis> was that perhaps this PK
-index has been corrupted (representing a &postgres; bug), and that
-perhaps the problem might be alleviated by running the query:</para>
-
-<programlisting>
-# reindex table _slonyschema.sl_log_1;
-</programlisting>
-
-<para> On at least one occasion, this has resolved the problem, so it
-is worth trying this.</para>
-</answer>
-
-<answer> <para> This problem has been found to represent a &postgres;
-bug as opposed to one in &slony1;. Version 7.4.8 was released with
-two resolutions to race conditions that should resolve the issue.
-Thus, if you are running a version of &postgres; earlier than 7.4.8,
-you should consider upgrading to resolve this.
-</para>
-</answer>
-</qandaentry>
-<qandaentry> <question><para>I started doing a backup using
-<application>pg_dump</application>, and suddenly Slony
-stops</para></question>
-
-<answer><para>Ouch. What happens here is a conflict between:
-<itemizedlist>
-
-<listitem><para> <application>pg_dump</application>, which has taken
-out an <command>AccessShareLock</command> on all of the tables in the
-database, including the &slony1; ones, and</para></listitem>
-
-<listitem><para> A &slony1; sync event, which wants to grab a
-<command>AccessExclusiveLock</command> on the table <xref
-linkend="table.sl-event"/>.</para></listitem> </itemizedlist></para>
-
-<para>The initial query that will be blocked is thus:
-
-<screen>
-select "_slonyschema".createEvent('_slonyschema, 'SYNC', NULL);
-</screen></para>
-
-<para>(You can see this in <envar>pg_stat_activity</envar>, if you
-have query display turned on in
-<filename>postgresql.conf</filename>)</para>
-
-<para>The actual query combination that is causing the lock is from
-the function <function>Slony_I_ClusterStatus()</function>, found in
-<filename>slony1_funcs.c</filename>, and is localized in the code that
-does:
-
-<programlisting>
- LOCK TABLE %s.sl_event;
- INSERT INTO %s.sl_event (...stuff...)
- SELECT currval('%s.sl_event_seq');
-</programlisting></para>
-
-<para>The <command>LOCK</command> statement will sit there and wait
-until <command>pg_dump</command> (or whatever else has pretty much any
-kind of access lock on <xref linkend="table.sl-event"/>)
-completes.</para>
-
-<para>Every subsequent query submitted that touches
-<xref linkend="table.sl-event"/> will block behind the
-<function>createEvent</function> call.</para>
-
-<para>There are a number of possible answers to this:
-<itemizedlist>
-
-<listitem><para> Have <application>pg_dump</application> specify the
-schema dumped using <option>--schema=whatever</option>, and don't try
-dumping the cluster's schema.</para></listitem>
-
-<listitem><para> It would be nice to add an
-<option>--exclude-schema</option> option to
-<application>pg_dump</application> to exclude the &slony1; cluster
-schema. Maybe in 8.2...</para></listitem>
-
-<listitem><para>Note that 1.0.5 uses a more precise lock that is less
-exclusive that alleviates this problem.</para></listitem>
-</itemizedlist></para>
-</answer></qandaentry>
-
-</qandadiv>
-
-<qandadiv id="faqoddities"> <title> &slony1; FAQ: Oddities and Heavy Slony-I Hacking </title>
-<qandaentry><question><para> What happens with rules and triggers on
-&slony1;-replicated tables?</para>
-</question>
-
-<answer><para> Firstly, let's look at how it is handled
-<emphasis>absent</emphasis> of the special handling of the <xref
-linkend="stmtstoretrigger"/> Slonik command. </para>
-
-<para> The function <xref
-linkend="function.altertableforreplication-integer"/> prepares each
-table for replication.</para>
-
-<itemizedlist>
-
-<listitem><para> On the origin node, this involves adding a trigger
-that uses the <xref linkend="function.logtrigger"/> function to the
-table.</para>
-
-<para> That trigger initiates the action of logging all updates to the
-table to &slony1; <xref linkend="table.sl-log-1"/>
-tables.</para></listitem>
-
-<listitem><para> On a subscriber node, this involves disabling
-triggers and rules, then adding in the trigger that denies write
-access using the <function>denyAccess()</function> function to
-replicated tables.</para>
-
-<para> Up until 1.1 (and perhaps onwards), the
-<quote>disabling</quote> is done by modifying the
-<envar>pg_trigger</envar> or <envar>pg_rewrite</envar>
-<envar>tgrelid</envar> to point to the OID of the <quote>primary
-key</quote> index on the table rather than to the table
-itself.</para></listitem>
-
-</itemizedlist>
-
-<para> A somewhat unfortunate side-effect is that this handling of the
-rules and triggers somewhat <quote>tramples</quote> on them. The
-rules and triggers are still there, but are no longer properly tied to
-their tables. If you do a <command>pg_dump</command> on the
-<quote>subscriber</quote> node, it won't find the rules and triggers
-because it does not expect them to be associated with an index.</para>
-
-</answer>
-
-<answer> <para> Now, consider how <xref linkend="stmtstoretrigger"/>
-enters into things.</para>
-
-<para> Simply put, this command causes
-&slony1; to restore the trigger using
-<function>alterTableRestore(table id)</function>, which restores the
-table's OID into the <envar>pg_trigger</envar> or
-<envar>pg_rewrite</envar> <envar>tgrelid</envar> column on the
-affected node.</para></answer>
-
-<answer><para> This implies that if you plan to draw backups from a
-subscriber node, you will need to draw the schema from the origin
-node. It is straightforward to do this: </para>
-
-<screen>
-% pg_dump -h originnode.example.info -p 5432 --schema-only --schema=public ourdb > schema_backup.sql
-% pg_dump -h subscribernode.example.info -p 5432 --data-only --schema=public ourdb > data_backup.sql
-</screen>
-
-</answer>
-</qandaentry>
-
-<qandaentry> <question> <para> I was trying to request <xref
-linkend="stmtddlscript"/> or <xref linkend="stmtmoveset"/>, and found
-messages as follows on one of the subscribers:</para>
-
-<screen>
-NOTICE: Slony-I: multiple instances of trigger defrazzle on table frobozz
-NOTICE: Slony-I: multiple instances of trigger derez on table tron
-ERROR: Slony-I: Unable to disable triggers
-</screen>
-</question>
-
-<answer> <para> The trouble would seem to be that you have added
-triggers on tables whose names conflict with triggers that were hidden
-by &slony1;. </para>
-
-<para> &slony1; hides triggers (save for those <quote>unhidden</quote>
-via <xref linkend="stmtstoretrigger"/>) by repointing them to the
-primary key of the table. In the case of foreign key triggers, or
-other triggers used to do data validation, it should be quite
-unnecessary to run them on a subscriber, as equivalent triggers should
-have been invoked on the origin node. In contrast, triggers that do
-some form of <quote>cache invalidation</quote> are ones you might want
-to have run on a subscriber.</para>
-
-<para> The <emphasis>Right Way</emphasis> to handle such triggers is
-normally to use <xref linkend="stmtstoretrigger"/>, which tells
-&slony1; that a trigger should not get deactivated. </para> </answer>
-
-<answer> <para> But some intrepid DBA might take matters into their
-own hands and install a trigger by hand on a subscriber, and the above
-condition generally has that as the cause. What to do? What to do?
-</para>
-
-<para> The answer is normally fairly simple: Drop out the
-<quote>extra</quote> trigger on the subscriber before the event that
-tries to restore them runs. Ideally, if the DBA is particularly
-intrepid, and aware of this issue, that should take place
-<emphasis>before</emphasis> there is ever a chance for the error
-message to appear. </para>
-
-<para> If the DBA is not that intrepid, the answer is to connect to
-the offending node and drop the <quote>visible</quote> version of the
-trigger using the <acronym>SQL</acronym> <command>DROP
-TRIGGER</command> command. That should allow the event to proceed.
-If the event was <xref linkend="stmtddlscript"/>, then the
-<quote>not-so-intrepid</quote> DBA may need to add the trigger back,
-by hand, or, if they are wise, they should consider activating it
-using <xref linkend="stmtstoretrigger"/>.</para>
-</answer>
-</qandaentry>
-
-<qandaentry id="neededexecddl">
-
-<question> <para> Behaviour - all the subscriber nodes start to fall
-behind the origin, and all the logs on the subscriber nodes have the
-following error message repeating in them (when I encountered it,
-there was a nice long SQL statement above each entry):</para>
-
-<screen>
-ERROR remoteWorkerThread_1: helper 1 finished with error
-ERROR remoteWorkerThread_1: SYNC aborted
-</screen>
-</question>
-
-<answer> <para> Cause: you have likely issued <command>alter
-table</command> statements directly on the databases instead of using
-the slonik <xref linkend="stmtddlscript"/> command.</para>
-
-<para>The solution is to rebuild the trigger on the affected table and
-fix the entries in <xref linkend="table.sl-log-1"/> by hand.</para>
-
-<itemizedlist>
-
-<listitem><para> You'll need to identify from either the slon logs, or
-the &postgres; database logs exactly which statement it is that is
-causing the error.</para></listitem>
-
-<listitem><para> You need to fix the Slony-defined triggers on the
-table in question. This is done with the following procedure.</para>
-
-<screen>
-BEGIN;
-LOCK TABLE table_name;
-SELECT _oxrsorg.altertablerestore(tab_id);--tab_id is _slony_schema.sl_table.tab_id
-SELECT _oxrsorg.altertableforreplication(tab_id);--tab_id is _slony_schema.sl_table.tab_id
-COMMIT;
-</screen>
-
-<para>You then need to find the rows in <xref
-linkend="table.sl-log-1"/> that have bad
-entries and fix them. You may
-want to take down the slon daemons for all nodes except the master;
-that way, if you make a mistake, it won't immediately propagate
-through to the subscribers.</para>
-
-<para> Here is an example:</para>
-
-<screen>
-BEGIN;
-
-LOCK TABLE customer_account;
-
-SELECT _app1.altertablerestore(31);
-SELECT _app1.altertableforreplication(31);
-COMMIT;
-
-BEGIN;
-LOCK TABLE txn_log;
-
-SELECT _app1.altertablerestore(41);
-SELECT _app1.altertableforreplication(41);
-
-COMMIT;
-
---fixing customer_account, which had an attempt to insert a "" into a timestamp with timezone.
-BEGIN;
-
-update _app1.sl_log_1 SET log_cmddata = 'balance=''60684.00'' where pkey=''49''' where log_actionseq = '67796036';
-update _app1.sl_log_1 SET log_cmddata = 'balance=''60690.00'' where pkey=''49''' where log_actionseq = '67796194';
-update _app1.sl_log_1 SET log_cmddata = 'balance=''60684.00'' where pkey=''49''' where log_actionseq = '67795881';
-update _app1.sl_log_1 SET log_cmddata = 'balance=''1852.00'' where pkey=''57''' where log_actionseq = '67796403';
-update _app1.sl_log_1 SET log_cmddata = 'balance=''87906.00'' where pkey=''8''' where log_actionseq = '68352967';
-update _app1.sl_log_1 SET log_cmddata = 'balance=''125180.00'' where pkey=''60''' where log_actionseq = '68386951';
-update _app1.sl_log_1 SET log_cmddata = 'balance=''125198.00'' where pkey=''60''' where log_actionseq = '68387055';
-update _app1.sl_log_1 SET log_cmddata = 'balance=''125174.00'' where pkey=''60''' where log_actionseq = '68386682';
-update _app1.sl_log_1 SET log_cmddata = 'balance=''125186.00'' where pkey=''60''' where log_actionseq = '68386992';
-update _app1.sl_log_1 SET log_cmddata = 'balance=''125192.00'' where pkey=''60''' where log_actionseq = '68387029';
-
-</screen>
-</listitem>
-
-</itemizedlist>
-</answer>
-
-</qandaentry>
-
-<qandaentry>
-
-<question><para> Node #1 was dropped via <xref
-linkend="stmtdropnode"/>, and the &lslon; one of the
-other nodes is repeatedly failing with the error message:</para>
-
-<screen>
-ERROR remoteWorkerThread_3: "begin transaction; set transaction isolation level
- serializable; lock table "_mailermailer".sl_config_lock; select "_mailermailer"
-.storeListen_int(2, 1, 3); notify "_mailermailer_Event"; notify "_mailermailer_C
-onfirm"; insert into "_mailermailer".sl_event (ev_origin, ev_seqno, ev_times
-tamp, ev_minxid, ev_maxxid, ev_xip, ev_type , ev_data1, ev_data2, ev_data3
- ) values ('3', '2215', '2005-02-18 10:30:42.529048', '3286814', '3286815', ''
-, 'STORE_LISTEN', '2', '1', '3'); insert into "_mailermailer".sl_confirm
-(con_origin, con_received, con_seqno, con_timestamp) values (3, 2, '2215', CU
-RRENT_TIMESTAMP); commit transaction;" PGRES_FATAL_ERROR ERROR: insert or updat
-e on table "sl_listen" violates foreign key constraint "sl_listen-sl_path-ref"
-DETAIL: Key (li_provider,li_receiver)=(1,3) is not present in table "sl_path".
-DEBUG1 syncThread: thread done
-</screen>
-
-<para> Evidently, a <xref linkend="stmtstorelisten"/> request hadn't
-propagated yet before node 1 was dropped. </para></question>
-
-<answer id="eventsurgery"><para> This points to a case where you'll
-need to do <quote>event surgery</quote> on one or more of the nodes.
-A <command>STORE_LISTEN</command> event remains outstanding that wants
-to add a listen path that <emphasis>cannot</emphasis> be created
-because node 1 and all paths pointing to node 1 have gone away.</para>
-
-<para> Let's assume, for exposition purposes, that the remaining nodes
-are #2 and #3, and that the above error is being reported on node
-#3.</para>
-
-<para> That implies that the event is stored on node #2, as it
-wouldn't be on node #3 if it had not already been processed
-successfully. The easiest way to cope with this situation is to
-delete the offending <xref linkend="table.sl-event"/> entry on node #2.
-You'll connect to node #2's database, and search for the
-<command>STORE_LISTEN</command> event:</para>
-
-<para> <command> select * from sl_event where ev_type =
-'STORE_LISTEN';</command></para>
-
-<para> There may be several entries, only some of which need to be
-purged. </para>
-
-<screen>
--# begin; -- Don't straight delete them; open a transaction so you can respond to OOPS
-BEGIN;
--# delete from sl_event where ev_type = 'STORE_LISTEN' and
--# (ev_data1 = '1' or ev_data2 = '1' or ev_data3 = '1');
-DELETE 3
--# -- Seems OK...
--# commit;
-COMMIT
-</screen>
-
-<para> The next time the <application>slon</application> for node 3
-starts up, it will no longer find the <quote>offensive</quote>
-<command>STORE_LISTEN</command> events, and replication can continue.
-(You may then run into some other problem where an old stored event is
-referring to no-longer-existant configuration...) </para></answer>
-
-</qandaentry>
-</qandadiv>
-
-</qandaset>
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Dernière modifications
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+<qandaset>
+<indexterm><primary>Questions Fréquemment Posées à propos de &slony1;</primary></indexterm>
+
+<qandadiv id="faqcompiling"><title> &slony1; FAQ: Monter et Installer &slony1; </title>
+
+<qandaentry>
+
+<question><para> J'utilise <productname> Frotznik Freenix
+4.5</productname>, avec son <acronym>FFPM</acronym> (Frotznik Freenix
+Package Manager) gestionnaire des paquetage système. L'arrivée de
+<acronym>FFPM</acronym> c'est l'introduction des paquetages pour &postgres; 7.4.7, lequel je suis actuellement
+entrain d'utiliser pour ma base de données, mais qui n'inclut pas encore les paquetages &slony1.
+Comment puis-je rajouter &slony1; à cette configuration? </para>
+</question>
+
+
+<answer><para> <productname>Frotznik Freenix</productname> c'est nouveau pour moi,
+alors il est un peu dangereux, pour donner des réponses définitives vraiment concise et rapides. </para>
+
+<para> Les réponses différent légèrement t entre les diverses combinaisons de versions entre
+&postgres; et &slony1; Il est légérement plus faciles, dans les versions récentes, de faire face à ce genre de question
+que dans 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.
+(Si vous devez d' <emphasis> utilisez </emphasis> le &postgres; compiler
+est un autre problème; vous n'avez probablement pas besoin...) </para>
+
+<itemizedlist>
+
+<listitem><para> &slony1; la version 1.0.5 et ultérieur nécessite avoir complètement
+configuré &postgres; ayant les sources installées, afin de recompiler
+&slony1;.</para>
+
+<para> <emphasis>Si tout va bien </emphasis> vous pouvez refaire la configuration,
+ceci contre la configuration utilisée nativement par la paquetage d'origine, en utilisant la
+version de &postgres; en utilisant la commande
+<command> pg_config --configure</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 totale de &postgres; en sources, mais qui,
+au lieu de cela, se réfère à l'endroit où &postgres; ses librairies,
+les binaires, la configuration, ainsi que <command> les fichiers #include </command> sont déjà installés.
+</para> </listitem>
+
+<listitem><para> &postgres; 8.0 et supérieur est généralement plus facile voire idéal
+car comprenant déjà une <quote>installation par défaut</quote> incluant la totalité des fichiers d'inclusion
+<command> #include </command>. </para>
+
+<para> Si vous utilisez les versions antérieur de&postgres;, vous êtes sensé avoir trouvé
+toutes les sources et de les installer, si le paquetage d'installation ne l'a pas fait pour vous <quote> sur le serveur,
+les fichiers d'inclusions<command>#include</command></quote>, peuvent être réinstaller via la commande
+<command> make install-all-headers </command>.</para>
+</listitem>
+
+</itemizedlist>
+
+<para> En effet, le <quote>cas dérangeant </quote> est un scénario où
+vous utilisez une version de &slony1; antérieur à 1.1 avec une
+<quote>vieille</quote> version de &postgres;, dans ce cas vous pouvez comptez devoir compiler &postgres;
+à partir de zéro afin d'avoir tout les pré requis de &slony1; Recompile sera un passage obligé même si
+vous utilisez un version<quote>paquetée</quote> de &postgres;.</para>
+
+<para> Si vous employez une version récente de &postgres; et une version récente de &slony1;,
+alors les dependences peuvent être assez petits, et vous ne pouvez pas avoir besoin
+complémentaire des sources &postgres;. Ces dispositions devraient soulager la mise en production de
+paquetage de &slony1; de sorte que vous pourriez même pouvoir espérer éviter la compilations
+de &slony1;.</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.
+ This is the path to postgres.h. Please specify the includeserverdir with
+ --with-pgincludeserverdir=<dir>
+</screen>
+</para></question>
+
+<answer><para> Vous exécutez certainement une version &postgres; 7.4
+ou ultérieur, où les en-têtes de serveur ne sont pas installé par défaut,
+il vous suffi dans ce cas de lancer juste
+une commande <command>make install</command> de &postgres;.</para>
+
+<para> Vous avez besoin d'installer les en-têtes de serveur lors d'installation de &postgres;
+via la commande <command>make install-all-headers</command>.
+
+</para> </answer> </qandaentry>
+
+<qandaentry id="threadsafety">
+
+<question><para> &slony1; semble se compiler correctement; maintenant, lorsque j'exécute un
+&lslon;, certain évènement démarrent autour, mais la réplication ne se met pas
+route.</para>
+
+<para> Slony logs might look like the following:
+
+<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,
+ ev_data1, ev_data2,
+ 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>
+
+<para> Parfois il peut se manifester de manières suivante ...
+
+<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>
+
+<answer><para>Sur AIX et Solaris (et probablement sur d'autre OS), les deux
+&slony1; <emphasis>et &postgres;</emphasis> doivent être compilés avec l'
+<option>--enable-thread-safety</option> 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 (threadsafe) et libpq
+(non-threadsafe) utilisent des emplacement de mémoire différente pour le code erreur, ainsi en
+laissant la requête échouer.</para>
+
+<para>Des problèmes de ce genre sur AIX et sur Solaris, surviennent avec des régularités surprenantes.
+; l'erreur devrais prendre quelque choses ressemblant à un code <quote>objet ou à un code d'audit</quote> qui sont compilé
+make sure that <emphasis>ALL</emphasis> of the necessary components have been
+et linké avec l'option <option>--enable-thread-safety</option>.</para>
+
+<para>Pour le moment, je me concentre sur le problème de
+<envar>LD_LIBRARY_PATH</envar> si c'est défini, sur Solaris, pour pointer sur les
+librairies depuis une version ancienne de &postgres; afin de recompiler. Cela signifie que même si
+la base <emphasis>a été</emphasis> compilée avec l'
+<option>--enable-thread-safety</option>, et que
+<application>slon</application> a été recompilé à nouveau, avec l'édition de lien dynamique de
+<application>slon</application> pointant sur un
+<quote>ancienne mauvaise version de thread-unsafe,</quote> et alors slon n'a pas fonctionné. Ceci n'était pas clair
+que c'était le cas, jusqu'à ce que je rexécute <command>ldd</command>
+à nouveau <application>slon</application>.</para> </answer>
+
+<answer><para> A noter que la version 7.4.2 de libpq, sur Solaris exige, un nouveau patch
+de <link linkend="threadpatch"> </link> ; Le 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 de<xref
+linkend="stmtupdatefunctions"/>. Lors d'exécution de<xref
+linkend="stmtupdatefunctions"/>, mon
+<application>postmaster</application> plante dessus avec un Signal 11.
+Le fichier log ne contient aucune erreur, relatives à
+&postgres; les logs indiquent que, yes indeed, the postmaster fell
+over.</para>
+
+<para> En scrutant le fichier core avec un débuguer, 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>
+
+<answer> <para> Désagréablement l'ancienne versions de &postgres; 8.1 avait un problème
+où lorsque vous aviez besoin de redéfinir une fonction (comme , say,
+<function>upgradeSchema(text)</function>), et que après, dans la même session de transaction
+, vous exécutiez la même fonction, le
+<application>postmaster</application> tombait en erreur, et que la
+transaction ne pouvait se valider. </para>
+
+<para> La commande &lslonik; <xref linkend="stmtupdatefunctions"/>
+fonctionne de cette manière; dans la même transaction, essayez 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> Notifier au pro cesses &lslon; le fait de changement de la 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
+lié à un plantage. </para>
+
+<para> Plusieurs contournements sont à envisager. </para>
+
+</answer>
+
+<answer> <para> La réponse privilégiée serais de dire migrer &postgres; en
+version 8.1.4 ou supérieur. Les changements mineurs du noyau n'entraîne pas de
+reconstruction de la base; ceci devrait simplement exiger d'installer un noyau 8.1.x
+en redémarrant les <application>postmaster</application> avec cette nouvelle version. </para>
+</answer>
+
+<answer><para> Si cette solution ne convient pas, il est possible d'effectuer une série de transaction <quote>à la main</quote>,
+l'équivalent de ce que &lslonik; aurait fait pour cette migration. </para>
+
+<itemizedlist>
+<listitem><para> Prendre <filename>slony1_funcs.sql</filename> et faire trois remplacement 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 littérale de &slony1; comme <quote>1.2.10</quote> </para> </listitem>
+<listitem><para> Remplacer <quote>@NAMESPACE@</quote> avec <quote>double-quoted</quote> nom du cluster, comme "_MyCluster" </para> </listitem>
+</itemizedlist>
+</listitem>
+<listitem><para> Recharger cet<quote>remis à niveau</quote> de jeux de fonctions dans la base.</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 celle de 1.2.7. </para> </listitem>
+<listitem><para> Rechargement total des processes &lslon; sera 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>
+
+<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 :
+
+<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>
+
+<para> Ceci arrive avec &postgres; 8.2.5, ce qui est certainement un peu plus récent que
+7.3. </para>
+</question>
+
+<answer> <para> <application>configure</application> est à la recherche de ce directif
+en compilant un petit programme requis, pour lequel il est appelé, et
+vérifie la compilation se passe bien. Avec la ligne de commande <command>gcc</command>
+il utilise <command>-lpq</command> pour chercher la librairie. </para>
+
+
+<para> Malheureusement, ce paquetage fait défaut depuis le lien symbolique, de
+<filename>/usr/lib64/libpq.so</filename> à
+<filename>libpq.so.5.0</filename>; c'est pourquoi il plante sur 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 est absent et qui a manqué à l'appel.
+</para>
+
+<para> Eventuellement il faudra remonter ces informations vers ceux qui gèrent le paquetage
+<filename>postgresql-libs.x86_64</filename>. </para>
+</answer>
+
+<answer> <para> Notez que ce même symptôme peut être révélateur des problèmes semblables de ce genre
+de 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 log généré,
+ <filename>config.log</filename>. Cherchez par la bas, et regarder quel est le souci <emphasis>récemment</emphasis> rencontré.
+Ceci sera bénéfique, pour trouver la racine de l'épineux problème.</para>
+</answer>
+
+</qandaentry>
+
+</qandadiv>
+
+<qandadiv id="faqconnections"> <title> &slony1; FAQ: Problèmes relatifs aux connections</title>
+<qandaentry>
+
+<question><para>Je cherche le nom de<envar>_clustername</envar>, et
+il est introuvable.</para></question>
+
+<answer><para> Si le DNS sont erronés, alors l'instance &lslon;
+ne pourra pas se connecter aux noeuds.</para>
+
+<para>Ceci mène aux fait que les noeuds seront introuvables.</para>
+
+<para>Revérifier la configuration des connexions. D'ailleurs depuis <xref
+linkend="slon"/> le linkage avec libpq, vous devrez avoir le mot de passe généré
+ dans <filename> $HOME/.pgpass</filename>, partiellement reporté dans bonne/mauvais authentification ici.</para>
+</answer>
+</qandaentry>
+
+<qandaentry id="morethansuper">
+<question> <para> J'ai crée 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 l'interrogation 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>
+
+<para> Malheureusement, je suis tombé en 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>
+
+<para> Celà a continué de se planter, à plusieurs reprise, juqsqu'à ce que
+<application>slon</application> se connecte comme
+<command>postgres</command> le faisait.</para>
+</question>
+
+<answer><para> Le problème est assez évident en soi; la permission sur la table de système est ignorée, <envar>pg_class</envar>.</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> En version 8.1 et supérieur, 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,dans le log, j'obtiens le message
+suivant :
+
+<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>
+
+<answer> <para> Il y a évidemment un certain nombre de vieilles transactions bloquantes,
+de &slony1; restant depuis le traitement des synchros. Vous devriez jeter un coup d'oeil
+à pg_locks to see what's up:</para>
+
+<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>
+
+<para>See? 127314921 est en effet plus vieux que 127314958, et il est toujours en cours d'exécution.</para>
+
+<para> Un long traitement G/LA, s'emballe durant une interrogation
+<application>RT3</application>, avec
+<application>pg_dump</application>, toute les transaction semblent s'exécuter pour une période interminable.
+Jusqu'à ce que elles soient complétées ou bien interrompu, on verra alors le message d'erreur suivant:
+<quote> data copy
+for set 1 failed - sleep 60 seconds </quote>.</para>
+
+
+<para>D'ailleurs, s'il y a plus d'une base de données sur le cluster du &postgres;
+, et que la charge se déporte sur une autre base, ce qui mène à procéder aux<quote>transactions plus tôt que XID
+quoi que</quote> s'avérant encore en marche. Le fait est que la base de donnée dissociée
+sur le cluster n'est pas pertinente; &slony1; attendra
+jusqu'à ce que ces vieilles transactions se terminent.</para>
+</answer>
+</qandaentry>
+
+
+<qandaentry>
+<question><para>Même chose que ce qui précède. Ce que j'ai oublié de mentionner, aussi bien,
+était que j'essayais d'ajouter
+<emphasis>DEUX</emphasis> abonnés, concurremment.</para></question>
+
+<answer><para> Cela ne peut marcher: &slony1; ne peut employer la commande
+<command>COPY</command> de manière concurrente. voir
+<filename>src/slon/remote_worker.c</filename>, la fonction
+<function>copy_set()</function></para>
+
+<screen>
+$ ps -aef | egrep '[2]605100'
+postgres 2605100 205018 0 18:53:43 pts/3 3:13 postgres: postgres sampledb localhost COPY
+</screen>
+
+<para>Ceci s'avère justement être une transaction de <command>COPY</command>
+impliqué en installant l'abonnement pour un des noeuds. Tout a l'air bien;
+le système s'occupe de configurer le premier abonné; il ne veut 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 (peut-être malheureusement)comme conséquence que vous ne pouvez pas peupler
+deux esclaves concurremment pour un simple fournisseur. Vous devez souscrire un et un seul abonné à la fois,
+une fois qu'il a accompli l'abonnement,(copyant le contenu des table et autre) peut s'occuper de débuter l'enregistrement
+du deuxième.</para></answer>
+</qandaentry>
+
+<qandaentry id="missingoids"> <question> <para> Nous somme souciés par quelques choses
+car ne pouvant envisager de désinstaller entièrement une réplication du cluster slony
+entre un maître et un esclave.</para>
+
+<warning> <para><emphasis>ASSUREZ-VOUS QUE VOUS ARRÊTEZ L'EXECUTION DE VOS APPLICATIONS
+SUR VOTRE BASE DE DONNEES MAITRE, LORS DE L'ELIMINATION D'UN MEMBRE DU
+CLUSTER</emphasis>, or at least re-cycle all your open connections
+after the event! </para></warning>
+
+<para> Les connexions <quote>se renouvellent</quote> ou se rapportent à OIDs qui sont
+tuées lors du lancement du script de désinstallation. Et vous obtiendrez
+un bon nombre d'erreurs en conséquence…
+</para>
+
+</question>
+
+<answer><para> Il y a deux sections notables de
+&postgres; qui sont la mise en cache des plans d'interrogation et les OIDs:</para>
+<itemizedlist>
+<listitem><para> Préparer la requête</para></listitem>
+<listitem><para> Les fonctions pl/pgSQL </para></listitem>
+</itemizedlist>
+
+<para> En particulier le problème n'est pas que sous &slony1; en un;
+se produirait quand de telles modifications importantes sont apportées aux fondements de base
+de données. Il n'est pas imaginable que cela mène à perdre des données, mais de se voir confronté
+à une vague d'erreur relatives à OID.
+</para></answer>
+
+<answer><para> Le problème arrive lorsque vous utilisez une sorte de
+<quote>pool de connexion</quote> qui essaie de les reconnecter à la fin.
+Si vous remettez l'application en route après ceci, des nouvelles connexions
+sont générées avec un <emphasis>nouveau</emphasis>plan d'interrogation, et qui
+font disparaître les erreurs. Si votre pool de connexion tue les sessions, et en recrée de nouvelle,
+alors ces nouvelles session auront de <emphasis>nouveau</emphasis> plan d'exécution, et
+que les erreurs vont disparaître. </para></answer>
+
+En notre code nous laissons tomber le raccordement sur n'importe quelle
+erreur nous ne peut pas tracer à un état prévu. Ceci réutiliserait par la
+suite tous les raccordements sur de tels problèmes inattendus après juste une
+erreur par raccordement. Naturellement si l'erreur apprête car une violation de
+contrainte qui est un état identifié, ce won' ; l'aide de t l'un ou l'autre, et
+si le problème est persistant, les raccordements maintiendra réutiliser qui
+ laisseront tomber l'effet de la mise en commun, dans le dernier cas que
+ le code de mise en commun pourrait également annoncer un Admin. pour jeter
+ un coup d'oeil…
+
+<answer> <para> Dans notre code nous éliminons toutes connexions ayant des erreurs inattendues dans
+le contexte. Ceci dit, les convexions devront être rétablis à la fin de chaque telle erreur
+inattendues, à raison d'une erreur par connexion. Naturellement si l'erreur remonte une violation de contrainte,
+qui est une condition reconnue, ne peut aider la situation, et si le problème persiste, les connexions sont restaurées,
+qui aura pour effet de casser l'effet de pool, dans ce dernier cas, l'administrateur aura à jeter
+un coup d'oeil sur le code. </para> </answer>
+
+</qandaentry>
+
+<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>
+
+<para> Les deux <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 remis à zéro.
+Quel est le souci?
+</para> </question>
+
+<answer><para> Ceci est un cas symptomatique et similaire au précèdent,
+relatif à la suppression de réplication : s'il y a des connexions établies, s'attardant à utiliser des plan d'exécutions
+basés sur des vieilles fonctions stockées, donne par conséquence une écriture dans
+ <envar>sl_log_1</envar> </para>
+
+<para> La fermeture des vieilles et l'ouverture des nouvelles connexions, résous ce problème.</para> </answer>
+
+<answer> <para> En d'autre terme, la présence d'un ordre dans la liste d'attente de &postgres;
+pour implémenter des dépendances, aura pour effet de descendre les plans d'exécution, lorsque cette dépendance
+joue sur l'objet qui change. </para> </answer>
+</qandaentry>
+
+<qandaentry>
+<question><para>J'ai pointé un noeud de souscription à un fournisseur différent, et il a cessé
+la réplication.</para></question>
+
+<answer><para>
+Nous rappelons que ceci arrive lorsque nous souhaitons initialiser un noeud où
+nous avons la configuration suivante:
+
+<itemizedlist>
+<listitem><para> Node 1 - fournisseur</para></listitem>
+<listitem><para> Node 2 - s'enregistrer au noeud 1 - le noeud que nous avons réinitialisé</para></listitem>
+<listitem><para> Node 3 - s'enregistrer au noeud 3 - le noeud qui doit répliquer</para></listitem>
+</itemizedlist></para>
+
+<para>L'abonnement pour le noeud 3 a changé dans le sens d'avoir
+le noeud 3 comme fournisseur, et on a fait<xref linkend="stmtdropset"/> /<xref
+linkend="stmtsubscribeset"/> pour le noeud 2 pour qu'il soit rechargé.</para>
+
+<para>Malencontreusement, la réplication a été arrêtée soudainement sur le noeud 3.</para>
+
+<para>Le problème était qu'il n'y avait pas un ensemble approprié de
+<quote>ports d'écoute</quote> dans <xref linkend="table.sl-listen"/> pour permettre aux évènements
+depuis le noeud 1 de se propager sur le 3. Les événements vont se reporter aux noeuds 2 et bloquent ainsi
+derrière l'évènement <xref linkend="stmtsubscribeset"/> que le noeud 2 est en train de traiter.</para>
+
+<para>Le port d'écoute a lâché le script suivant de slonik où le noeud 3 aurait dû, en passant par le noeud 2
+de l'ajouter directement en ports d'écoute entre les deux noeuds 1 et 3.
+
+<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';
+ node 4 admin conninfo='host=10.28.103.132 dbname=oxrslive user=postgres port=5432';
+try {
+ store listen (origin = 1, receiver = 3, provider = 1);
+ 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>
+
+<para>Juste après que ce script a été terminé, les événements de <command>SYNC</command> ont commencé à
+propager encore sur le noeud 3.
+
+Ceci précise deux principes:
+<itemizedlist>
+
+Si vous avez des noeuds multiples, et des abonnés en cascade,
+vous devez faire attention en repeuplant les entrés <xref
+linkend="stmtstorelisten"/>, et en modifiant leur structures de l'<quote>arbre</quote>de changement
+de réplication.</para></listitem>
+
+<listitem><para> La version 1.1 fourni des meilleurs outils pour gérer ce cas.</para>
+</listitem>
+
+</itemizedlist></para>
+
+<para>Les problèmes relatifs aux <quote>chemins d'écoute</quote> sont discutés
+plus bas au <xref linkend="listenpaths"/> </para></answer>
+</qandaentry>
+
+<qandaentry id="multipleslonconnections">
+
+<question><para> En redémarrant &lslon;, j'obtiens
+le message suivant <quote>FATAL</quote> 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
+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
+2006-03-29 16:01:34 UTC CONFIG main: local node id = 1
+2006-03-29 16:01:34 UTC DEBUG2 main: main process started
+2006-03-29 16:01:34 UTC CONFIG main: launching sched_start_mainloop
+2006-03-29 16:01:34 UTC CONFIG main: loading current cluster configuration
+2006-03-29 16:01:34 UTC CONFIG storeSet: set_id=1 set_origin=1 set_comment='test set'
+2006-03-29 16:01:34 UTC DEBUG2 sched_wakeup_node(): no_id=1 (0 threads + worker signaled)
+2006-03-29 16:01:34 UTC DEBUG2 main: last local event sequence = 7
+2006-03-29 16:01:34 UTC CONFIG main: configuration complete - starting threads
+2006-03-29 16:01:34 UTC DEBUG1 localListenThread: thread starts
+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>
+
+</question>
+
+<answer><para> La table <envar>sl_nodelock</envar> est utilisée comme un
+<quote>enclencheur</quote>pour prévenir que les deux process &lslon; essaient de prendre
+la gestion du même noeud en même temps. Le &lslon; essais d'insérer
+un enregistrement dans la table; seulement il peut le faire avec succès que
+si il est le seul à gérer le noeud. </para></answer>
+
+<answer><para> Ce message d'erreur est typiquement un signe que vous avez démarrez
+un second process &lslon; pour un noeud donné. Le &lslon;pose la question évidente qui est :
+ <quote>Avez vous déjà un a slon démarré pour gérer ce noeud?</quote> </para></answer>
+
+Vous supposant éprouver une certaine sorte de panne de réseau, le raccordement
+entre le & ; lslon ; et la base de données peut échouer, et le & ; lslon ; peut
+figurer ceci dehors longtemps avant le & ; postgres ; exemple il était relié fait.
+Le résultat est qu'il y aura un certain nombre de les raccordements à vide sont partis sur
+le serveur de base de données, qui won' ; t soit fermé jusqu'aux temps morts de TCP/IP complets,
+qui semble prendre normalement environ deux heures. Pour cette période de deux heures, le & ; lslon ;
+essayera de se relier, à plusieurs reprises, et recevra le message mortel ci-dessus, plus d'et au-dessus de.
+
+<answer><para> Vous supposant éprouver une certaine sorte de panne de réseau,
+les connections entre &lslon; et la base de données peuvent échouer, et &lslon;
+peut avertir cela bien avant l'instance de &postgres; il était connecté pour ce faire.
+La conséquence en est qu'un certain nombre de connexion pré-établie vont s'ouvrir su la base de données
+et qui ne vont pas se terminer jusqu'à ce que le timeout de TCP/IP arrive à échéance, chose qui n'arrive que
+tous les 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 réputé Fatl. </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 mourantes.
+Malheureusement , puisque le problème a eu lieu dans couche de gestion de réseau,ni &postgres; ni &slony1;
+a le moyen direct de détecter ceci. </para>
+
+<para> Vous pouvez <emphasis>la plupart</emphasis> des cas éviter ceci en s'assurant
+que le process &lslon; est hébergé quelque part près 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
+seraient susceptibles d'être assez sérieux pour menacer le serveur entier. </para></answer>
+</qandaentry>
+
+
+<qandaentry>
+<question><para> Quand est-ce que je peux arrêter les process &lslon;?</para></question>
+
+<answer><para> Généralement ce n'est pas un grand compromis pour arrêter les processes &lslon;
+Chacun d'eux est un <quote>simplement</quote> un client de &postgres;,
+gérant chacun un noeud, qui engendre des fils pour gérer et recevoir des évènements
+depuis d'autre noeud. </para>
+
+<para>L'<quote>évènement d'écoute</quote> des serveurs n'est pas un travail sorcier; ils n'ont
+rien à faire que de temps en temps de tester le noeud distant pour déterminer si sur le noeud en question,
+il y a des tâches à faire. Si vous tuer le process &lslon; sa surveillance sera fermée, qui doit avoir peu
+ou pas du tout d'impact sur rien peut-être. Les éventements générés pour un &lslon; en arrêt reprendront
+lors de son redémarrage.</para>
+
+<para> La<quote>gestion des noeuds</quote> est un peu plus intéressant;
+ la plupart du temps , vous pouvez prévoir, sur un abonné, pour son fil
+ d'exécuter l'évènement<command>SYNC</command>. Si vous arrêtez
+le &lslon; durant un évènement, la transaction va échouer, et s'annuler, alors lorsque the &lslon;
+redémarre, il aura de reprendre l'évènement pour l'exécuter.</para>
+
+<para> L'unique situation où cela peut arriver est
+ <emphasis>particulièrement</emphasis> <quote>l'arrêt de coeur</quote> si
+l'évènement qui vient de s'achever était un traitement de longue durée comme,
+<command>COPY_SET</command> pour une large réplication.</para>
+
+<para>L'autre chose qui <emphasis>pourrait</emphasis> causer l'ennui est
+si &lslon; travaille sur un noeud distant auxquels il est connecté;
+vous pouvez découvrir que les sessions de la base de données sont laissées <command>disponible en transaction</command>.
+Ceci peut normalement 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'y aller pas à la main pour leur mettre fin dans &postgres;
+backends.</para>
+
+ Il y a un autre cas qui pourrait causer l'ennui ; quand & ; lslon ;
+ la gestion du noeud d'origine ne fonctionne pas, événement de synchro
+ ne fonctionne pas contre ce noeud. Si & ; lslon ; les séjours vers le bas
+ pendant une période prolongée, et quelque chose aiment isn' ; fonctionnement
+ de t, vous pourriez être laissé avec une grande synchro au processus quand il
+ vient support. Mais c'est seulement un souci si ce & ; lslon ; est vers le bas
+ pendant une période prolongée ; le fermant pour uns seconde shouldn' ; cause
+ de t tout grand problème.
+
+
+<para> Il y a un autre cas qui pourrait causer l'ennui; quand
+&lslon; administrant son noeud d'attachement n'est pas en cours d'exécution
+,aucun évènement <command>SYNC</command> s'exécute sur ce même serveur. Si le &lslon;
+ arrêté pour une longue durée, et que quelques chose du genre <xref linkend="gensync"/> n'est pas encours,
+vous pouvez vous retrouvez avec <emphasis>un énorme<command>SYNC</command></emphasis> à effectuer
+lorsque vous vous apprêtez à réaliser une sauvegarde. Ceci est vrai seulement si &lslon; est en arrêt pendant une période
+assez longue; alors que un arrêt de quelques seconds ne génère pas de problème.</para> </answer>
+</qandaentry>
+
+<qandaentry>
+<question><para> Y a-t-il des risques pour ce faire ? Quels en sont les avantages ?</para></question>
+
+<answer><para> En bref, si votre <command>COPY_SET</command> prend environ 18h pour s'exécuter
+finalement, ce n'est pas un grand sacrifice d'arrêter quelques moments un &lslon;
+ou peut-être même durant un cycle<emphasis>all</emphasis> de &lslon;s. </para> </answer>
+</qandaentry>
+
+</qandadiv>
+
+<qandadiv id="faqconfiguration"> <title> &slony1; FAQ: Problèmes de configuration </title>
+<qandaentry>
+<question><para>Slonik tombe en erreur - ne peut pas charger les librairies &postgres; -
+<command>PGRES_FATAL_ERROR load '$libdir/xxid';</command></para>
+
+<para> Lorsque j'exécute un simple script de configuration, j'obtiens un message similaire à
+:
+
+<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>
+
+<answer><para> Evidemment, vous n'avez pas accès à la librairie
+<filename>xxid.so</filename> dans le répertoire <envar>$libdir</envar>
+où l'instance &postgres; est en usage. Notez que le composant &slony1;doit être installé sur le noyau du &postgres;
+pour <emphasis>chacun des noeud</emphasis> et pas seulement sur le noeud d'origine.</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;
+vous même, sur une machine où il y a plusieurs noyau de
+&postgres; <quote>se trouvant autour,</quote> il est possible
+que les binaires slon ou lslonik demande de charger une librairie qui n'est pas accessible
+actuellement dans les répertoires du noyau de &postgres; gérant le cluster.</para>
+
+<para>Court et concis: Ceci indique un besoin de <quote>auditer</quote>
+quel mode d'installation de &postgres; et de &slony1; vous avez en place sur vos machines.
+Malheureusement,n'importe quelle incompatibilité peut faire remonter ce genre
+de soucis. Voir aussi<link linkend="threadsafety">
+sécurité des thread </link> à propos de la gestion des thread sur Solaris.
+...</para>
+
+<para> La situation sera plus simple si vous aviez un seul noyau de &postgres; installé par serveur
+dans ce cas il n'y aura pas d' <quote>incompatibilité
+de chemins</quote> dans lequel les composants de &slony1; sont installés.</para>
+Si vous avez une installation multiple,
+vous devrez vous assurez de la compatibilité de la bonne
+versions de &slony1; associé à la bonne version du noyau de
+&postgres;. </para> </answer></qandaentry>
+
+<qandaentry>
+<question> <para>J'essai de créer un cluster dont le nom contient un "-".
+Cela ne marche pas!.</para></question>
+
+<answer><para> &slony1; Utilise les même règles de nommage que &postgres;
+alors confirmation, il ne faudra pas utiliser un "-"
+dans le nom.</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>
+
+<qandaentry>
+<question><para>La commande ps affiche le mot de passe en claire</para>
+
+<para> Si je lance une commande <command>ps</command>, tout le monde,
+peut voir le mot de passe qui a été fourni à la ligne de commande.</para></question>
+
+<answer> <para>Conservez vous mot de passe en dehors de la configuration Slony, en les mettant dans
+des fichiers <filename>$(HOME)/.pgpass.</filename></para>
+</answer></qandaentry>
+
+<qandaentry>
+<question><para>Sommaire de questions posées sur namespace
+
+<programlisting>
+set add table (set id = 1, origin = 1, id = 27,
+ full qualified name = 'nspace.some_table',
+ key = 'key_on_whatever',
+ comment = 'Table some_table in namespace nspace with a candidate primary key');
+</programlisting></para></question>
+
+<answer><para> Si vous avez <command> key =
+'nspace.key_on_whatever'</command> la demande
+<emphasis>echoura</emphasis>.</para>
+</answer></qandaentry>
+
+<qandaentry>
+<question> <para> La réplication a été retardée, et il semble que les interrogations pour restituer des données
+depuis <xref linkend="table.sl-log-1"/>/<xref
+linkend="table.sl-log-2"/> prennent beaucoup de temps en indiquant quelques demande de
+<command>SYNC</command>s. </para>
+</question>
+
+<answer> <para> Jusqu'à la version 1.1.1, la table <xref
+linkend="table.sl-log-1"/>/<xref linkend="table.sl-log-2"/>,possédait seulement un index, et si plusieurs jeu de réplication
+se mettaient en route en même temps, quelques colonnes dans l'indexe n'était pas très discriminent pour la manière d'accès.
+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 un indexe.
+</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 s'avère un peu dangereuse, est-ce vrai ?
+Aurai-je à la recréer en dehors de la réplication ?</para>
+</question>
+
+<answer><para> Affirmatif, c'est un scénario qui fonctionne proprement. &slony1; fait un usage intensif de
+clef primaire, mais actuellement c'est ainsi et on espère une gestion intégrée et transparente prochainement</para>.
+
+<para> Supposez que vous souhaiter renommer une colonne, comme dans uns script sql, on utiliserais 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 manière
+<emphasis>transparente</emphasis> de effectuer la mise à jour dans clef primaire qui contient la colonne en question.
+Le résultat est que ce genre de changement s'effectue simultanément sur les différents composants, du 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
+en étant sur que le bon changement s'applique aux bons noeuds.</para>
+
+<para> Pour la clarté des choses, tant que la modification commence par la partie répliquée et bien avant les abonnés,
+il n'y aura pas de cassure irrémédiable. Se retrouver avec quelques évènements de
+<command>SYNC</command> qui n'incluent pas la table sur laquelle il y a la modification, n'est pas un problème car ils vont se dérouler
+sans difficulté... Par contre si le changement est signalé d'abord par un abonné, alors
+point that the first update to the table is drawn in by a subscriber,
+<emphasis>ce</emphasis> sera le point de départ pour que
+<command>SYNC</command> tombe en erreur, puisque le fournisseur indiquera une
+<quote>nouvelle</quote> colonne alors que l'abonné connait toujours
+ses <quote>anciens</quote> formats. En appliquant la modification à postériori chez l'abonné, la commande
+<command>SYNC</command>, peut retrouver le
+<quote>nouveau</quote> nom de colonne et fonctionner sans plantage .
+</para> </answer></qandaentry>
+
+<qandaentry id="v72upgrade">
+<question> <para> J'ai un &postgres; version 7.2 que je souhaite
+<emphasis>vraiment, vraiment</emphasis> employer avec &slony1; Que faut-il faire pour une migration en
+version 8.2 ? Quel est l'implication pour récupérer &slony1; afin de les exploiter ensemble?</para>
+</question>
+
+<answer> <para> Voici l'écrit d'un certain Rod Taylor sur le sujet ...
+</para>
+
+<para> Voici ce dont approximativement vous avez besoin:</para>
+<itemizedlist>
+<listitem><para>Prendre les formulaire 7.3 et de mes copier en 7.2 -- ou bien de
+ mettre en dur 7.3 dans vos formulaire </para></listitem>
+<listitem><para>Supprimer toute trace de schémas dans le code sql de vos formulaires.
+ Sommairement je remplace "." par "-". </para></listitem>
+<listitem><para> Le bloc de travail relatif aux models de données XID ainsi qu’aux fonctions.
+ Par exemple, Slony crée des CASTs pour the xid en xxid et vice versa -- mais
+ la 7.2 ne peut pas crée de nouveau casts et dans ce cas vous êtes obligé de le modifier à la main.
+ Je rappelle la création d'une classe d'opérateur ainsi que l'édition de certaines fonctions. </para></listitem>
+<listitem><para>sl_log_1 aura de grave problème de performance quelque soit le volume de données.
+ Ceci exige qu'un certain nombre d'indexe 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 travailler en séquence. 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 implémenter la 7.2 de manière artisanale
+du moins, forcer slony à travailler sans les schémas dans la nouvelle version versions de &postgres;
+ainsi le dialogue entre les deux peut être établi.
+</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 majeur partie), et démarrer la migration
+de 7.2 à 7.4 sur les différentes machines en utilisant un Slony standard.
+Ceci permettant de s'assurer sur la fiabilité d'un catalogue système qui avait subi des changement manuels.
+</para>
+
+<para> Tout cela pour dire, que nous migrons quelque centaine de GO de données,
+de 7.2 a 7.4 en espace de 30 minutes. (contre 48 heures auparavant annoncées myeneant un dump et
+restore) sans pertes de données.
+</para>
+</answer>
+
+<answer> <para> Ceci vous dresse un éventail assez laid qualifié de
+<quote>bidouille</quote> qu'il faut admettre entrer dans le périmètre de production.
+Si quelqu'un est intéressé pour le transformer en
+<quote>tâche de production</quote>, il y aura un sens dans ce cas de 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> Vous devriez seulement adapter cette solution que si vous êtes à l'aise avec
+&postgres; et &slony1; et que de mettre la main au code ne vous fait pas peur. </para> </answer>
+</qandaentry>
+
+<qandaentry>
+<question> <para> J'avais un réseau <quote>pas performant</quote> qui m'obligeais à utiliser
+ <xref linkend="stmtfailover"/> un basculement 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 depuis le début, le noeud planté ? </para></question>
+
+<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>
+
+<answer><para> L'<emphasis>énorme</emphasis> problème afin de restaurer le serveur planté,
+est qu'il peut contenir des mises à jours qui n'ont pas eu le temps de se propager endors.
+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é en <xref linkend="failover"/>, utiliser <xref
+linkend="stmtfailover"/> revient à accepter comme <emphasis>dernier
+ressort</emphasis> tant qu'il implique d'abandonner le noeud 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>
+
+<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 d'<xref
+linkend="slon"/> arrêt: de syncs:</para>
+
+<screen>
+DEBUG2 remoteListenThread_1: queue event 1,4897517 SYNC
+DEBUG2 remoteListenThread_1: queue event 1,4897518 SYNC
+DEBUG2 remoteListenThread_1: queue event 1,4897519 SYNC
+DEBUG2 remoteListenThread_1: queue event 1,4897520 SYNC
+DEBUG2 remoteWorker_event: ignore new events due to shutdown
+DEBUG2 remoteListenThread_1: queue event 1,4897521 SYNC
+DEBUG2 remoteWorker_event: ignore new events due to shutdown
+DEBUG2 remoteListenThread_1: queue event 1,4897522 SYNC
+DEBUG2 remoteWorker_event: ignore new events due to shutdown
+DEBUG2 remoteListenThread_1: queue event 1,4897523 SYNC
+</screen>
+
+</question>
+
+<answer><para> Si vous regardez les journaux de &lslon; à l'arrêt avec des erreurs due à cet effet
+<emphasis>d'arrêt</emphasis>, vous auriez besoin de revenir en arrière en ignorant une partie de
+ces journalisation,
+<emphasis>en attendant</emphasis> après le redémarrage du serveur en erreur de trouver la cause d'origine.</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
+de <xref linkend="stmtsubscribeset"/> command</para>
+
+<para>Ceci démontre encore un autre exemple où l'approximatif ne devra pas prendre le dessus,
+et que on doit avec assurance vérifier le bon fonctionnement des choses
+<emphasis>avant</emphasis> de suggérer un changement de la configuration.
+</para></answer>
+
+</qandaentry>
+
+<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.
+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, que leurs fournisseur <emphasis>sera</emphasis> indisponible durant une période maintenance.</para>
+
+<warning> <para> Que vous avez <emphasis>omis</emphasis> de faire <xref
+linkend="stmtunsubscribeset"/>; pour que vous soyez obligé de recommencer à rafraîchir les noeuds depuis le début.
+
+</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 erreur, et commençant des messages d'erreurs
+avec :</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> Ceci est suivi plus tard par une série d'erreur de syncs puisque le <xref
+linkend="slon"/> est à l'arrêt:
+
+<screen>
+DEBUG2 remoteListenThread_1: queue event 1,4897517 SYNC
+DEBUG2 remoteListenThread_1: queue event 1,4897518 SYNC
+DEBUG2 remoteListenThread_1: queue event 1,4897519 SYNC
+DEBUG2 remoteListenThread_1: queue event 1,4897520 SYNC
+DEBUG2 remoteWorker_event: ignore new events due to shutdown
+DEBUG2 remoteListenThread_1: queue event 1,4897521 SYNC
+DEBUG2 remoteWorker_event: ignore new events due to shutdown
+DEBUG2 remoteListenThread_1: queue event 1,4897522 SYNC
+DEBUG2 remoteWorker_event: ignore new events due to shutdown
+DEBUG2 remoteListenThread_1: queue event 1,4897523 SYNC
+</screen>
+
+</para></question>
+
+<answer><para> Si lors d'un arrêt, vous voyez dans le journal d'un &lslon;
+<emphasis>des nouveaux évènements ignorés dus à l'arrêt</emphasis> ,
+c'est le cas parlant où il faut revenir une étape en arrière
+<emphasis>avant</emphasis> l'arrêt pour voir l'origine de l'erreur.
+</para></answer>
+
+<answer><para> Dans ce cas particulier, le problème était que certain
+ <xref linkend="stmtstorepath"/> commandes n'ont pas été transmises aux noeud 4 avant <xref linkend="stmtsubscribeset"/>
+ la commande soit propagée. </para>
+
+<para>C'est encore un exemple où il ne faut pas hâtivement modifier les choses
+;vous devrez avec certitude, constater le disfonctionnement
+<emphasis>avant</emphasis> de faire de nouveau changement de configuration.
+</para></answer>
+
+</qandaentry>
+
+<qandaentry>
+<question> <para> Est-ce que dans une configuration globale, l'ordre dans lequel, on traite les tables
+est important ?</para>
+</question>
+<answer> <para> La plupart de temps il ne l'est pas. Vous devrez adapter un ordre selon lequel
+les tables <quote>maîtres</quote> sont mises à jour avant celles de <quote>détails</quote>
+en fonction de la relation de clef étrangère qui les relie; ceci ne sera <emphasis>pas exigé</emphasis> si sur le noeud 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 mortels et par conséquent faire tomber l'application ou bien
+<application>slon</application>.
+</para>
+<answer><para> (David Parker) Dans un autre cas, j'ai lancé l'opération où l'ordre des
+tables avait une importance : en présence des tables avec les contraintes d'intégrité référentielles.
+Si une table détail se présente avant celle de maître, alors le serveur abonné, supprime son
+contenu, avant qu'elle soit à nouveau rafraîchie, car la logique de la commande
+<command>copy_set</command> vaut que <command>delete</command>,
+ne soit pas un <command>delete only</command>, or la suppression des données de la table maître, impose bien la suppression de celle
+de détail.
+</para>
+</answer></answer>
+
+</qandaentry>
+
+<qandaentry>
+
+<question><para> Si votre script <xref linkend="slonik"/> ressemble à quelque chose comme le suivant,
+il peut tomber en erreur et ne jamais se terminer, car vous n'avez pas
+<command>wait pour ev la mise à jour à nouveau. Bien sûr Of course, as mentioned
+above, it could be faster to drop the node and recreate it than to let
+ent</command> à l'intérieur d'un bloc de
+<command>try</command>. Un bloc de <command>try</command> est exécuté comme une seule et même transaction,
+et l'évènement pour lequel vous êtes en attente, peut jamais avoir lieu
+dans le scope de la transaction.</para>
+
+<programlisting>
+try {
+ echo 'Moving set 1 to node 3';
+ lock set (id=1, origin=1);
+ echo 'Set locked';
+ wait for event (origin = 1, confirmed = 3);
+ echo 'Moving set';
+ move set (id=1, old origin=1, new origin=3);
+ echo 'Set moved - waiting for event to be confirmed by node 3';
+ wait for event (origin = 1, confirmed = 3);
+ echo 'Confirmed';
+} on error {
+ echo 'Could not move set for cluster foo';
+ unlock set (id=1, origin=1);
+ exit -1;
+}
+</programlisting></question>
+
+<answer><para> Vous ne devez pas invoquer<xref linkend="stmtwaitevent"/>
+à l'intérieur d'un bloc de<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
+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.
+</para>
+
+<para>Le contournement est de créer un <emphasis>AUTRE</emphasis>
+jeu de table, d'y rajouter la table souhaitée, brancher les serveurs abonnés au "jeu 1" sur le nouveau qu'on vient de créer,et en suite de
+fusionner les 2 jeux ensemble.</para>
+</answer></qandaentry>
+
+<qandaentry>
+<question><para>
+ERROR: duplicate key violates unique constraint "sl_table-pkey"</para>
+
+<para>En essayant de monter un deuxième jeu de réplication, j'ai ce message :I tried setting up a second replication set, and got the following error:
+
+<screen>
+stdin:9: Could not create subscription set 2 for oxrslive!
+stdin:11: PGRES_FATAL_ERROR select "_oxrslive".setAddTable(2, 1, 'public.replic_test', 'replic_test__Slony-I_oxrslive_rowID_key', 'Table public.replic_test without primary key'); - ERROR: duplicate key violates unique constraint "sl_table-pkey"
+CONTEXT: PL/pgSQL function "setaddtable_int" line 71 at SQL statement
+</screen></para></question>
+
+<answer><para> Les identifaiants des tables utilisées dans <xref linkend="stmtsetaddtable"/>
+demande d'être unique <emphasis>A TRAVERS TOUT LE JEU</emphasis>. Thus,
+you can't restart numbering at 1 for a second set; if you are
+numbering them consecutively, a subsequent set has to start with IDs
+after where the previous set(s) left off.</para> </answer>
+</qandaentry>
+
+<qandaentry>
+<question><para> L'un de mes serveurs tombe en erreur sur (&lslon; / postmaster was
+down) et dont aucune notification depuis plusieurs jours.Maintenant lorsque &lslon; sur ce noeud démarre,
+ll tourne durant cinq minutes, puis s'arrête,
+avec l'erreur suivante : <command>ERROR: remoteListenThread_%d: timeout
+for event selection</command> What's wrong, and what do I do? </para>
+</question>
+
+<answer><para> Le problème est que le port d'écoute de ce processus (dans
+<filename>src/slon/remote_listener.c</filename>) arrive à une expiration de temps, lors il tente
+de déterminer quels est l'évènement à reprendre sur ce noeud.Par défaut
+le délai d'expiration de cette interrogation est de 5 minutes; si la reprise contient plus d'évènement,
+cela prendra beaucoup plus de temp.
+ </para> </answer>
+
+<answer><para> La réponse à cette question pour les versions de &slony1; antérieur à 1.1.7, 1.2.7, et à 1.3, serait de dire
+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.
+</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>
+
+</qandaentry>
+
+</qandadiv>
+<qandadiv id="faqperformance"> <title> &slony1; FAQ: Performance Issues </title>
+
+<qandaentry id="longtxnsareevil">
+
+
+<question><para> Replication has been slowing down, I'm seeing
+<command> FETCH 100 FROM LOG </command> queries running for a long
+time, <xref linkend="table.sl-log-1"/> is growing, and performance is,
+well, generally getting steadily worse. </para>
+</question>
+
+<answer> <para> Les causes de ce genre de choses sont multiples.
+Il y a une question évoquée par ce genre de pathologie, où le problème d'augmentation du volume dans
+ <link linkend="pglistenerfull">
+&pglistener; est dû au fait que la purge via vaccume n'est pas exécutée.</link>
+</para>
+
+<para> Par rapprochement <quote> on peut avancer </quote>, pour cette augmentation de volume,
+est que une session existante sur le serveur rend le noeud
+ <command>
+IDLE IN TRANSACTION </command> pour une durée infinie. </para>
+
+<para> La session ouverte peut avoir des effets négatifs,
+entraînant 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 tuplets pour les transactions qui sont ouvertes et disponible, car elle
+viennent de démarrer. </para> </listitem>
+
+<listitem><para> Le nettoyage des processus ne pourra pas se faire
+sur les entrées dans <xref linkend="table.sl-log-1"/> et <xref
+linkend="table.sl-seqlog"/>, qui entraîne par conséquence, une croissance
+de volume tant que les transactions persistent. </para>
+</listitem>
+</itemizedlist>
+</answer>
+
+<answer> <para> Vous pouvez surveiller, dans la base, ces conditions que si
+dans le fichier d'initialisation 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 :
+<command> select * from pg_stat_activity where current_query like '%IDLE% in transaction';
+</command> dont le résultat vous donnent les activités relatives. </para> </answer>
+
+<answer> <para> Vous devrez également être capable de rechercher
+les <quote> idle in transaction </quote> dans la table des processes
+ceux qui détiennent encore des transactions actives.
+ </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.
+La table <envar> query_start </envar> time in <envar>
+pg_stat_activity </envar> vous présentra les longues requêtes qui sont dans cet état. </para> </answer>
+
+<answer> <para> Il est prévue que &postgres; aie un paramètre d'expiration de
+délai, <envar> open_idle_transaction_timeout </envar>, qui permettrais
+de venir à bout des transactions dont le temps arrivent à échéance.
+
+Le concept de connexion par pool, engendre ce genre de situation d'erreur.
+Il est prévu des amélioration où <productname> <link linkend="pgpool"> pgpool
+</link> </productname> devrait présenter des meilleurs alternatifs afin de mieux gérer les connexion partagée à
+travers la notion de 'pool'.
+Cela devrez faire diminuer les bugs rencontré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,
+que en réalité les connexions de l'application reste dans un statut
+disponible et en activité, pour de<para>J'avis lancé I have been running &slony1; on a node for a while, and am
+s heures durant.
+</para> </answer>
+
+</qandaentry>
+
+<qandaentry id="faq17">
+<question><para>Après une suppression de noeud, le fichier journal <xref linkend="table.sl-log-1"/>
+n'est plus purgé.</para></question>
+
+<answer><para> Ceci est un scénario commun dans les versions d'avant 1.0.5, comme
+le <quote>nettoyage</quote> du prend effet en oubliant les entrées des
+ tables &slony1; <xref linkend="table.sl-confirm"/>, pour le serveur qui vient de disparaître.</para>
+
+<para> Le noeud ne s'occupe plus de mettre à jour des confirmations, comme quoi
+syncs vient de s'effectuer sur ce serveur, car il estime qu'il ne peut sans risque supprimer les entrées plus récentes
+que la dernière <xref linkend="table.sl-confirm"/> entrée, qui plutôt
+limite la capacité de purge des anciens fichiers journaux.</para>
+
+<para>Diagnostics: Exécuter les requêtes suivantes pour voir si il y a
+un résidus d'entrées en état de <quote>fantôme/obsolète/bloqué</quote> <xref
+linkend="table.sl-confirm"/>:
+
+<screen>
+oxrsbar=# select * 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);
+ con_origin | con_received | con_seqno | con_timestamp
+------------+--------------+-----------+----------------------------
+ 4 | 501 | 83999 | 2004-11-09 19:57:08.195969
+ 1 | 2 | 3345790 | 2004-11-14 10:33:43.850265
+ 2 | 501 | 102718 | 2004-11-14 10:33:47.702086
+ 501 | 2 | 6577 | 2004-11-14 10:34:45.717003
+ 4 | 5 | 83999 | 2004-11-14 21:11:11.111686
+ 4 | 3 | 83999 | 2004-11-24 16:32:39.020194
+(6 rows)
+</screen></para>
+
+<para>En 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, cposés par quelques tables du groupe de réplication ? Cela bloquerait invisiblement That would somewhat-invisibly
+eci demande une exécution manuelle.
+Supposons que l'identifiant du noeud soit 3, alors la requête sera 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
+<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>, voir le contenu de<command>SYNC</command> de se mettre à jour à l'origine, via le planificateur to be updated on the origin based on a
+
+<xref linkend="table.sl-confirm"/> avant, <question><para>Quelque noeud commencent à prendre du retard Some nodes start consistently falling behind</para>
+en veillant à ce que seul les bons enregistrements
+sont purgés, et puis, seulement après avoir vérifier cette suppression, valider l'opération par une <command>COMMIT</command>. Si
+vous supprimer par erreur les données d'un autre noeud, votre journée est perdu 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>A noter que dans 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 endroits :
+
+<itemizedlist>
+<listitem><para> Lorsque un noeud est supprimé</para></listitem>
+
+<listitem><para> Au démarrage de chaque lancement de
+<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>
+</answer>
+</qandaentry>
+
+<qandaentry>
+
+<question><para>Le <application>slon</application> se dépense un week-end entier hors de la
+commission [for some reason], et il prend énormément de temps pour exécuter un
+sync.</para></question>
+
+<answer><para> Vous pourriez jeter un coup d'oeil, sur les tables <xref
+linkend="table.sl-log-1"/>/<xref linkend="table.sl-log-2"/>,
+et voir brièvement si il y a réellement un énorme &slony1;
+encours d'exécution. Jusqu'au au moins la version 1.0.2, il faut qu'il y ait un
+&lslon; connecté pour que <command>SYNC</command> soit encours.</para>
+
+<para>Si cet évènement n'est pas généré, alors toute la mise à jour, et celle-ci jusqu'au prochain évènement va se faire
+à travers un énorme transaction &slony1;.</para>
+
+<para>Conclusion: Même si il n'y a pas d'abonné en cause,
+vous avez <emphasis>vraiment</emphasis> besoin d'un
+<application>slon</application> en fonctionnement pour entretenir le noeud source.</para>
+
+<para>&slony1; 1.1 fournit une procédure stockée qui permet aux comptes Synchros 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>
+
+<para>J'avais lancé, depuis un moment, &slony1; sur un noeud, et je vois que la machine est à
+genoux.</para>
+
+<para>Je vois des instructions en cours comme :
+<screen>
+ fetch 100 from LOG;
+</screen></para></question>
+
+<answer><para> Ceci peut être un exemple type de &pglistener; (la table qui contient les données de
+<command>NOTIFY</command>)avec en abondance, des données obsolètes des tuplets mortes.
+
+
+Ce qui fait que l'évènement <command>NOTIFY</command> prend du temps,
+et cause le ralentissement de plus en plus fort du noeud affecté.</para>
+
+<para>Vous avez probablement besoin d'effectuer un <command>VACUUM FULL</command> sur
+&pglistener;, pour le nettoyer vigoureusement, et besoin de purger
+&pglistener; vraiment fréquemment. Une planification tous les cinq minutes fera l'affaire.</para>
+
+<para> Le démon Slon fait déjà une purge d'un groupe de table,et
+<filename>cleanup_thread.c</filename> contient une liste de tables à nettoyer fréquemment de manière automatique.
+Dans &slony1; 1.0.2,&pglistener; ceci n'est pas inclus. Dans 1.0.5 et supérieur, il est purgé régulièrement,
+du coup ce problème n'a plus le lieu d'être. Dans la version 1.2,
+&pglistener; sera 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>Il y a, cependant, toujours un scénario où ceci peut
+<quote>mordre toujours.</quote> Sous MVCC, vacuums ne peut pas supprimer des tuplets 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 un serveur abonné.</para> </answer></qandaentry>
+
+<qandaentry> <question> <para> J'ai soumis un requête <xref
+linkend="stmtmoveset"/> / <xref linkend="stmtddlscript"/>, et
+elle semble être coincée, sur mon serveur. Les journaux de &slony1; ne mon<listitem><para> La <command>restitution depuis LOG</command> procède à lire query will draw
+trent
+pas d'qui est défini dans le fichier which is defined in the
+erreurs ni d'avertissement </para> </question>
+
+<answer> <para> Il est possible que vous soyez en train d'exécuter
+<application>pg_autovacuum</application>, et qu'l soit tombait sur des verrous
+posés par des tables dans le groupe de réplication ? Ceci voudra dire que de manière silencieuse
+ock &slony1; est bloqué d'effectuer des opérations qui exigent l'acquisition des <link
+linkend="locking"> exclusifs. </link> </para>
+
+
+<para> Vous pourriez vérifier 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 verrous
+<envar>ShareUpdateExclusiveLock</envar> va bloquer les opérations de &slony1;
+qui nécessitent leurs propres verrous exclusifs, qui sont probablement en attentes,
+marqués comme n'étant pas garantis. </para>
+</answer> </qandaentry>
+
+<qandaentry>
+
+<question><para> Je remarque que dans les journaux d'un &lslon; l'état commute fréquent
+entre le <quote>vote</quote> démarré et arrêt.
+reporté fréquemment <quote>LISTEN - switch from polling mode to use
+LISTEN</quote> et <quote>UNLISTEN - switch into polling
+mode</quote>. </para> </question>
+
+Les seuils pour commuter entre ces modes sont commandés par le linkend= le " slon-config-synchro-intervalle "/>
+de <xref de paramètres de configuration et le linkend= le " slon-config-synchro-intervalle-temps mort "/>
+de <xref ; si la valeur du dépassement de durée (qui se transfère sur 10000, impliquant 10s) est le bas gardé,
+qui le rend facile pour le &lslon ; pour décider de retourner au mode de <quote>listening</quote>.
+Vous pouvez vouloir augmenter la valeur du paramètre de temps imparti
+
+<answer><para> Les seuils pour commuter entre ces modes sont commandés par
+le paramètres de configuration <xref
+linkend="slon-config-sync-interval"/> et celui de <xref
+linkend="slon-config-sync-interval-timeout"/>; si la valeur du temps d'expiration
+(par défaut étant à 10000, impliquant 10s) est maintenu bas, facilite la situation pour que
+&lslon; décide de retourner à l'état <quote>listening</quote>.
+Vous devriez augmenter cette valeur d'expiration de temps. </para>
+</answer>
+</qandaentry>
+
+
+</qandadiv>
+<qandadiv id="faqbugs"> <title> &slony1; FAQ: &slony1; Bugs dans les versions anciennes</title>
+<qandaentry>
+<question><para>Le process &lslon; processes entretenant mes abonnés devient énorme en taille
+, mettant en danger la ressource du système en terme de swap ainsi que le risque d'attendre la taille limite
+de 2GB par processe . </para>
+
+<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 mega octets.Peut-être ceci n'est pas approprié ? </para> </question>
+
+<answer> <para> Oui, ces enregistrements volumineux sont à la racine du problème.
+L'explication vient du fait que &lslon; normalement procède par paquet de
+ 100 enregistrement à la fois, lorsqu'un abonné fait des interrogation depuis le fournisseur.
+Ainsi si la taille moyenne des enregistrements est de
+is 10MB, ceci entraîne des données atteignant 1000MB qui sont en attente de
+ <command>INSERT</command> ou de <command>UPDATE</command>
+à procéder par le processe &lslon;.</para>
+
+<para> Cela mène évidemment à &lslon; d'atteindre des tailles gigantesques. </para>
+
+<para> Nombre d'enregistrement restitués par la valeur <envar> SLON_DTA_FETCH_SIZE </envar>,
+défini par le fichier <filename>src/slon/slon.h</filename>. La partie extraite appropriée à ce paramètre est :
+</para>
+
+<programlisting>
+#ifdef SLON_CHECK_CMDTUPLES
+#define SLON_COMMANDS_PER_LINE 1
+#define SLON_DATA_FETCH_SIZE 100
+#define SLON_WORKLINES_PER_HELPER (SLON_DATA_FETCH_SIZE * 4)
+#else
+#define SLON_COMMANDS_PER_LINE 10
+#define SLON_DATA_FETCH_SIZE 10
+#define SLON_WORKLINES_PER_HELPER (SLON_DATA_FETCH_SIZE * 50)
+#endif
+</programlisting>
+
+<para> Si vous rencontrez ce problème, vous devriez définir
+ <envar> SLON_DATA_FETCH_SIZE </envar>, peut-être réduit par un facteur de 10
+ 10, et de recompiler ensuite &lslon;. Il y a deux
+définitions dont <envar> SLON_CHECK_CMDTUPLES</envar> qui laisse faire une certaine surveillance
+supplémentaire pour s'assurer que le abonnés ne sont pas tombé hors de la
+SYNC en regard du fournisseur. Par défaut, cette option est désactivée, ainsi il faudra prendre la deuxième option,
+afin de modifier la valeur par defeuillé, il faudra changer
+<envar> SLON_DATA_FETCH_SIZE </envar> pour remplacer 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 nouveau 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 une valeur par défaut, ceci limitera
+ce phénomène de consommation de mémoire à la hauteur de 8MB. </para>
+</listitem>
+
+
+<listitem><para> Les tuplets sont lus jusqu'à ce que la taille n'excède pas
+le paramètre <xreflinkend="slon-config-max-largemem"/>. Par défaut, cette restriction
+ne consommera pas environ 5MB. Cette valeur n'est pas un seil de limitation stricte;
+si vous avez des tuplets dont la taille est de 50MB, il <emphasis>doit</emphasis> de manière forcée,
+être charger en mémoire. Il n'est pas question de négliger 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 sporadiquement,
+des séries de tuplets 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 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>
+
+<para> Si vous êtes emmener à utiliser &slony1; pour migrer depuis une plus vieille version à celle 8.1,
+et que au passage vous devrez faire une conversion depuis le format UTF-8, vous auriez une surprise déplaisante.</para>
+
+<para> Permettez de supposer 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> en conformité avec UTF-8,
+même si il ne peut vraiment pas. </para>
+
+<para> Si vous répliquez dans des instance de &postgres; en version 8.1, il va se plaindre de cela,
+, à la fois lors d'enregistrement d'un abonné, où &slony1; va râler
+à propos des codes caractères invalides qu'il vient de rencontrer durant la COPY des données,
+qui empêcherait que l'enregistrement se fasse, ou, empêchant de rajouter les données,plutard,
+lorsqu'il se reproduira, la réplication tombera en erreur sans possibilité de reprise.
+(Vous pouvez tricher sur le contenu de sl_log_1, mais assez rapidement
+cela deviendra <emphasis>vraiment</emphasis> inintéressante...)</para>
+
+<para>Il y a déjà eu une discutions 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>
+
+<para> Si votre réplication a pour but de convertir une fois pour toutes vos données,
+il y a le risque évoqué; 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> A propos des risques encourus, exécuter la réplication en mettant en jeu des versions différentes,
+semble être non pérennene à maintenir et qu'une migration vers 8.1 s'imposera. </para>
+
+<para> Pour plus d'information, voir la discutions<ulink url=
+"http://archives.postgresql.org/pgsql-hackers/2005-12/msg00181.php">
+sur le groupe de discutions postgresql-hackers. </ulink>. </para>
+</answer>
+</qandaentry>
+
+<qandaentry>
+<question> <para> J'utilise &slony1; 1.1 avec 4+ nouds dans le jeu où il y a deux jeux d'abonnements,
+ 1 et 2, qui ne partagent pas d'autre noeuds. Je découvre que la confirmation pour le jeu 1
+n'arrivent jamais pour le noeud souscrivant au jeu 2, et inversement, celles du jeu 2 n'arrivent pas non plus
+au noeud souscrivant au jeu 1. En conséquence, <xref
+linkend="table.sl-log-1"/> crois et grossi et n'est jamais purgée. Ceci est mentionné
+comme &slony1; <ulink
+url="http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1485">
+bug 1485 </ulink>.
+</para>
+</question>
+
+<answer><para> Apparemment le code pour
+<function>RebuildListenEntries()</function> ne suffit pas pour ce cas.</para>
+
+<para> <function> RebuildListenEntries()</function> sera rectifié dans &slony1; en version 1.2
+avec un algorithme couvrant ce cas. </para>
+<para>
+Dans l'intérim, vous voudrez ajouter manuellement quelques entrées <xref linkend="table.sl-listen"/> utilisant <xref
+linkend="stmtstorelisten"/> ou <function>storeListen()</function>,
+basé sur les (apparemment pas aussi désuet que nous avons pensé) principes décrits dans <xref linkend="listenpaths"/>.
+
+</para></answer>
+</qandaentry>
+
+<qandaentry>
+<question> <para> Je trouve que quelques colonnes de multibyte (Unicode, Big5) sont tronqués un peu, avec outre les derniers caractères truncés. Pourquoi?
+</para> </question>
+
+<answer> <para> C'était un bug présent jusqu'à la version 1.1.0 de &slony1; ; la manière dont des colonnes étaient capturées par la fonction <function>logtrigger()</function> qui coupait outre les derniers byte d'une colonne représentée dans un format de multibyte. Vérifiez pour voir que votre version de <filename>src/backend/slony1_funcs.c</filename> est bien 1.34 ou suppérieur; le e 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">
+Bug #1226 </ulink> indique une condition d'erreur qui peut survenir si
+vous faites placer une réplique composée seulement d'ordres.
+</para>
+</question>
+
+<answer> <para> Une brève réponse serait de dire qu'une réplication composée seulement d'ordre, n'est pas une bonne pratique <link linkend="bestpractices">
+.</link> </para>
+</answer>
+
+<answer>
+<para> Le problème avec un ensemble d'ordre seulement si vous avez un cas pour lequel les seuls abonnements qui sont en activité pour un abonné particulier vis à vis d'un fournisseur particulier, sont pour les jeux <quote>sequence-only</quote>. Si un noeud entre dans cet état,
+la réplique échouera, étant donnée la requête qui collectera les données depuis <xref
+linkend="table.sl-log-1"/> n'aura plus de tables à trouver et par conséquence la requête tombera en erreur. S'un jeu de réplication de nouveau <emphasis>avec</emphasis>
+des tables reapparît, tout va fonctionner correctement; il
+ <emphasis>paraîtra</emphasis> tout simplement effrayant.
+</para>
+
+<para> Ce problème devrait être résolu un certaine temps 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>
+<answer><para>
+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 tue l'intérêt du cluster sur lequel cela se produit.</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 employez toujours 1.0.1 ou 1.0.2, l'
+<emphasis>essentiel de la fonctionnalité de <xref linkend="stmtsetdroptable"/>
+impliquant <function>droptable_int()</function> est présent.
+Vous pouvez feuilleter cela à la main en trouvant l'identification de la table à supprimer, et que vous pouvez trouver dedans<xref
+linkend="table.sl-table"/>, et après lancer les trois requêtes suivantes sur chaque noeud :</emphasis>
+
+<programlisting>
+ select _slonyschema.alterTableRestore(40);
+ select _slonyschema.tableDropKey(40);
+ delete from _slonyschema.sl_table where tab_id = 40;
+</programlisting></para>
+
+<para>Le schéma dépendra évidemment de la façon dont vous avez défini le cluster &slony1;. L'identifiant de la table, dans cet exemple, 40, sera à vous de remplacer par celui que vous voulez vous en 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 réplique de ses propagations soit correcte.
+Implémenter ceci à travers un ordre de <xref linkend="slonik"/>
+avec un nouveau &slony1; pourra se faire. La soumission des trois requêtes utilisant <xref linkend="stmtddlscript"/> peut le faire aussi.
+Également il sera 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 un ordre 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érieur, il y a 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érieur, l'opération sera un peu plus manuel.</para>
+
+<para>À supposer que je veux me débarrasser des deux ordres énumérés ci-dessous,<envar>whois_cachemgmt_seq</envar> and
+<envar>epp_whoi_cach_seq_</envar>, we start by needing the
+<envar>seq_id</envar> values.
+
+<screen>
+oxrsorg=# select * from _oxrsorg.sl_sequence where seq_id in (93,59);
+ seq_id | seq_reloid | seq_set | seq_comment
+--------+------------+---------+-------------------------------------
+ 93 | 107451516 | 1 | Sequence public.whois_cachemgmt_seq
+ 59 | 107451860 | 1 | Sequence public.epp_whoi_cach_seq_
+(2 rows)
+</screen></para>
+
+<para>Les données à supprimer, afin d'éviter que soit propager, nécessite l'arrêt de Slony :
+
+<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 l'ordre partout en
+<quote>même temps.</quote> Ou bien appliquer à la main à chacun des noeuds.</para>
+
+<para>Similarly to <xref linkend="stmtsetdroptable"/>, this is
+implemented &slony1; version 1.0.5 as <xref
+linkend="stmtsetdropsequence"/>.</para></answer></qandaentry>
+
+</qandadiv>
+
+<qandadiv id="faqobsolete"> <title> &slony1; FAQ: Hopefully Obsolete Issues </title>
+
+<qandaentry>
+<question><para> &lslon; ne se remet pas en marche après un incident</para>
+
+<para> Après un après brutal de &postgres; (en simulant une panne système)
+dans &pglistener; un tuplets existe avec <command>
+relname='_${cluster_name}_Restart'</command>. slon ne démarre pas car
+il considère qu’une autre processe sert le cluster sur ce noeud. Que puis-je faire?
+Le tuplet ne peut pas être supprimé dans la relation.</para>
+
+<para> Le journal prétend que <blockquote><para>un autre slon en tâche de fond
+sert ce noeud déjà</para></blockquote></para></question>
+
+<answer><para> Le problème est que la table système &pglistener;, utilisée par
+&postgres; à gérer l'évènement de notification, contiens quelques entrées pointant vers le central,
+n'existent plus. La nouvelle instance de <xref
+linkend="slon"/> se connecte à la base, et elle est convaincue, par 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>
+
+<para> Le <quote>détritus</quote> dans cette table doit être nettoyer.</para>
+
+<para>Il sera utile de maintenir un script manuel pour ce genre de situation:
+
+<programlisting>
+twcsds004[/opt/twcsds004/OXRS/slony-scripts]$ cat restart_org.slonik
+cluster name = oxrsorg ;
+node 1 admin conninfo = 'host=32.85.68.220 dbname=oxrsorg user=postgres port=5532';
+node 2 admin conninfo = 'host=32.85.68.216 dbname=oxrsorg user=postgres port=5532';
+node 3 admin conninfo = 'host=32.85.68.244 dbname=oxrsorg user=postgres port=5532';
+node 4 admin conninfo = 'host=10.28.103.132 dbname=oxrsorg user=postgres port=5532';
+restart node 1;
+restart node 2;
+restart node 3;
+restart node 4;
+</programlisting></para>
+
+<para> <xref linkend="stmtrestartnode"/> nettoie les notifications mortes
+pour en suite redémarrer le noeud.</para>
+
+<para>Comme en version 1.0.5, au démarrage de slon, les processes cherche ce genre de données obsolètes et les nettoient
+le cas échéant.</para>
+
+<para> Comme en version 8.1 de &postgres;, la fonction manipulant
+&pglistener; ne supporte pas cet usage, alors pour la version de &slony1; après
+1.1.2 (<emphasis>e.g. - </emphasis> 1.1.5), ce
+<quote>couplage</quote> est manipulé par l'intermédiaire d'une autre table, et l'issu de la situation est
+rendu un peu plus transparent. <quote>.</quote> </para>
+
+</answer></qandaentry>
+
+<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
+pg_stat_activity on pid = procpid where granted = true and transaction
+in (select transaction from pg_locks where granted = false);
+
+ERROR: could not find hash function for hash operator 716373
+</programlisting>
+
+<para> Il semble que &slony1; <function>xxid</function> les fonctions vont être
+dôtées de brouillage(hashing), qu'elles n'ont pas actuellement.</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
+ce type afin de permettre la manipulation des IDs de transaction qui sont employés
+pour grouper ensemble, les mises à jour qui sont associées à la même transaction.
+</para>
+
+<para> Opérateurs qui n'étaient pas disponible pour &postgres; version
+7.3 et inférieur; afin de le rendre opérationnelle en 7.3, les fonctions spécifiques
+doivent être ajoutées. L'opérateur <function>=</function>
+a été marqué comme soutenant
+le hachage, mais pour que celui-ci travaille correctement, l'opérateur de jointure doit
+apparaître dans une classe d'opérateur d'index haché. Cela n'a pas été défini,
+et en conséquence, les requêtes (comme celle ci-dessus) qui décident d'employer
+le hash-joins échoueront. </para> </answer>
+
+<answer> <para> Ceci <emphasis> n'a pas </emphasis>
+été considéré comme bug <quote>release-critical</quote>, comme &slony1 ;
+ne produit probablement pas des intérrogations intérnes employant des hash-join. Ce problème ne devrait
+pas entacher &slony1 ; devant la capacité qu'il a de gérer la réplication. </para> </answer>
+
+<answer> <para> La nouvelle version de &slony1; (<emphasis>e.g.</emphasis>
+1.0.6, 1.1) omettra l'indicateur <command>HASHES</command>, donc ceci
+</para> </answer>
+
+<answer> <para> Supposons que vous souhaitez 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
+Expanded display is on.
+/* cbbrowne@[local]/dba2 slony_test1=*/ select * from pg_operator where oprname = '='
+and oprnamespace = (select oid from pg_namespace where nspname = 'public');
+-[ RECORD 1 ]+-------------
+oprname | =
+oprnamespace | 2200
+oprowner | 1
+oprkind | b
+oprcanhash | t
+oprleft | 82122344
+oprright | 82122344
+oprresult | 16
+oprcom | 82122365
+oprnegate | 82122363
+oprlsortop | 82122362
+oprrsortop | 82122362
+oprltcmpop | 82122362
+oprgtcmpop | 82122360
+oprcode | "_T1".xxideq
+oprrest | eqsel
+oprjoin | eqjoinsel
+
+/* cbbrowne@[local]/dba2 slony_test1=*/ update pg_operator set oprcanhash = 'f' where
+oprname = '=' and oprnamespace = 2200 ;
+UPDATE 1
+</programlisting>
+</answer>
+
+</qandaentry>
+<qandaentry> <question><para> Je peux faire un <command>pg_dump</command>
+et chargez les données en les sauvegardant, beaucoup plus rapidement que si <command>SUBSCRIBE
+SET</command> les exécutait lui-même. Pourquoi c'est ainsi? </para></question>
+
+<answer><para> &slony1; dépend des index, supposons qu'il soit sur un clef primaire, dont les feuilles se trouvant isolées (sans branches), en utilisant la commande
+ &postgres; <command>COPY</command> les données sont lues rapidement.
+Alors que 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é par le souscripteur) dans la mesure où l'opération dans ce cas démarre par d'abord une suppression des contenus des tables, et rien que cela laisse des tuplets 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. Ceci est <emphasis>beaucoup</emphasis> plus performant des reconstruire les indexes sur une table entièrement re-importée, plutôt que de refaire les indexes à la volet lorsque les enregistrement sont rajoutés un à un à la table.</para></answer>
+
+<answer><para> Si d'emblée, 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<command>TRUNCATER</command> les tables dont le contenu devra disparaître, les performance vont augmenter d'<emphasis>avantage.</emphasis> </para></answer>
+
+<answer><para> &slony1; en version 1.1.5 et supérieur, fait cela automatiquement; il <quote>cogne</quote> sur les indexes dans le catalogue de &postgres; afin de les inhiber, de plus, de la même façon il désactive les déclencheurs, tout en les <quote>réactivant</quote> à la fin sans oublier de reconstruire les indexes des tables en question. </para> </answer>
+</qandaentry>
+
+<qandaentry id="dupkey">
+<question><para>La réplication échoue - Violation des Constraintes unique</para>
+
+<para>Alors que la Réplication se déroule correctement, depuis un bout de temps, lorsque le noeud rencontre <quote>intempestivement,</quote> des erreurs suivant envoyées dans le journal:
+
+<screen>
+DEBUG2 remoteWorkerThread_1: syncing set 2 with 5 table(s) from provider 1
+DEBUG2 remoteWorkerThread_1: syncing set 1 with 41 table(s) from provider 1
+DEBUG2 remoteWorkerThread_1: syncing set 5 with 1 table(s) from provider 1
+DEBUG2 remoteWorkerThread_1: syncing set 3 with 1 table(s) from provider 1
+DEBUG2 remoteHelperThread_1_1: 0.135 seconds delay for first row
+DEBUG2 remoteHelperThread_1_1: 0.343 seconds until close cursor
+ERROR remoteWorkerThread_1: "insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '34', '35090538', 'D', '_rserv_ts=''9275244''');
+delete from only public.epp_domain_host where _rserv_ts='9275244';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '34', '35090539', 'D', '_rserv_ts=''9275245''');
+delete from only public.epp_domain_host where _rserv_ts='9275245';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '26', '35090540', 'D', '_rserv_ts=''24240590''');
+delete from only public.epp_domain_contact where _rserv_ts='24240590';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '26', '35090541', 'D', '_rserv_ts=''24240591''');
+delete from only public.epp_domain_contact where _rserv_ts='24240591';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '26', '35090542', 'D', '_rserv_ts=''24240589''');
+delete from only public.epp_domain_contact where _rserv_ts='24240589';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '11', '35090543', 'D', '_rserv_ts=''36968002''');
+delete from only public.epp_domain_status where _rserv_ts='36968002';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '11', '35090544', 'D', '_rserv_ts=''36968003''');
+delete from only public.epp_domain_status where _rserv_ts='36968003';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '24', '35090549', 'I', '(contact_id,status,reason,_rserv_ts) values (''6972897'',''64'','''',''31044208'')');
+insert into public.contact_status (contact_id,status,reason,_rserv_ts) values ('6972897','64','','31044208');insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '24', '35090550', 'D', '_rserv_ts=''18139332''');
+delete from only public.contact_status where _rserv_ts='18139332';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '24', '35090551', 'D', '_rserv_ts=''18139333''');
+delete from only public.contact_status where _rserv_ts='18139333';" ERROR: duplicate key violates unique constraint "contact_status_pkey"
+ - qualification was:
+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ère</emphasis> requête SQL
+précisant <command>log_cmdtype = 'I'</command>. Ce n'est pat tout à fait évident; ce qui se passe est que &slony1; regroupe 10 opérations de mise à jour, ensemble, afin de diminuer les aller-retour réseau.</para></question>
+
+<answer><para> Une origine <emphasis>certaine</emphasis> pour ceci est difficile à déterminer.</para>
+
+<para>En même temps, nous notons qu'il y a un problème de transactions manquées concernant les suppressions qui sont déjà nettoyées dans <xref
+linkend="table.sl-log-1"/>, et on constate qu'un recouvrement est impossible. A ce stade, ce qui semble nécessaire, est de supprimer le jeu de réplication (ou même carrément le noeud), est de redémarrer la réplication de début pour le noeud.</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. pour 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 volume 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"/> a été brutalement purgée, donc cette solution permet de résoudre complètement ce genre d'incident.</para>
+
+<para> C'est une honte de reconstruire un réplication volumineuse sur un noeud,
+si vous découvrez que le problème pérciste. La bonne idée serai de diviser la réplication
+en plusieurs morceaux afin de dimin<envar>tgrelid</envar> en les pointant sur l'identifiant OID of the <quote>primary
+key</quote> index on the table rather than to the table
+uer la charge de travail lors de redémarrage de réplication.
+Si un seul jeu est cassé, vous n'auriez qu'à désabonner et supprimer celui-ci.
+</para>
+
+<para> Dans un cas, nous avons trouvé deux lignes dans le journal d'erreur des requêtes sql
+qui sont <emphasis> identique </emphasis> concernant l'insertion dans
+ <xref linkend="table.sl-log-1"/>. Ceci <emphasis> doit
+</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, moins forte, laisserait à penser que cette situation
+viendrait que <emphasis>cette</emphasis> clé serait peut-être corrompue (présence d'un bug de &postgres;), et afin de soulever ce doute,
+on peut exécuter l'ordre suivant:</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>
+</answer>
+
+<answer> <para> Ce problème s'est avéré comme un bug dans &postgres; par opposition à un autre dans &slony1;. La version 7.4.8 avait intégré deux solutions qui permettent de résoudre ce cas. Or si vous avez un noyau de &postgres; antérieur à 7.4.8,
+vous devriez migrer d'abord pour éviter l'erreur.
+</para>
+</answer>
+</qandaentry>
+<qandaentry> <question><para>J'ai commencé à faire une sauvegarde via
+<application>pg_dump</application>, et Slony
+s'arrête soudainement</para></question>
+
+<answer><para>Ouf. Ce qui se passe dans ce cas est à cause d'un conflit entre:
+<itemizedlist>
+
+<listitem><para> <application>pg_dump</application>, qui sort un <command>AccessShareLock</command> pour toutes les tables de la base, y compris celle de &slony1; et</para></listitem>
+
+<listitem><para> Une synchronisation de &slony1; qui veut saisir
+<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 :
+
+<screen>
+select "_slonyschema".createEvent('_slonyschema, 'SYNC', NULL);
+</screen></para>
+
+<para>(vous pouvez voir ceci dans<envar>pg_stat_activity</envar>, si votre paramètre d'affichage des requête est positionné à vrai dans
+<filename>postgresql.conf</filename>)</para>
+
+<para>L'interrogation encours qui cause ce verrous 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;
+ INSERT INTO %s.sl_event (...stuff...)
+ SELECT currval('%s.sl_event_seq');
+</programlisting></para>
+
+<para>Le <command>VERROUS</command> se poste à ce moment et dure jusqu'à ce que
+<command>pg_dump</command> (ou le temps que les verrous bloquent les accès à <xref linkend="table.sl-event"/>)
+se términe.</para>
+
+<para>Chaque lecture touchant
+<xref linkend="table.sl-event"/> sera bloqué derrière les appels à
+<function>createEvent</function>.</para>
+
+<para>Les réponses à cette question sont multiples:
+<itemizedlist>
+
+<listitem><para> Faire spécifier à <application>pg_dump</application> d'exporter le schéma en utilisant l'option <option>--schema=whatever</option>, et ne pas essayer d'exporter le schéma du cluster entièrement.</para></listitem>
+
+<listitem><para> Il sera utile aussi d'ajouter une option
+<option>--exclude-schema</option> à
+<application>pg_dump</application> afin d'exclure le schéma du cluster de &slony1;. A rêver que dans 8.2...</para></listitem>
+
+<listitem><para>Notez que 1.0.5 utilise des verrous plus précis et moins exclusifs qui soulage ce problème.</para></listitem>
+</itemizedlist></para>
+</answer></qandaentry>
+
+</qandadiv>
+
+<qandadiv id="faqoddities"> <title> &slony1; FAQ: Singularité des vulnérabilité dans Slony-I </title>
+<qandaentry><question><para> Que se produit à propos des règles et des déclencheurs pour des tables répliquées par
+&slony1;?</para>
+</question>
+
+<answer><para> Premièrement regardons comment elle est gérée
+<emphasis>l'absence</emphasis> de gestion 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>
+
+<itemizedlist>
+
+<listitem><para> Sur le noeud maître, ceci implique l'ajout d'un déclencheur
+qui utilise la fonction <xref linkend="function.logtrigger"/> à la table.</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></listitem>
+
+<listitem><para> Sur un noeud d'abonné, répliquer une table, revient à désactiver les déclencheurs,
+puis, via un déclencheur, de restreindre 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 avant), le
+<quote>désactivation</quote> est faite en modifiant
+<envar>pg_trigger</envar> ou <envar>pg_rewrite</envar>
+<envar>tgrelid</envar> en pointant l'identifiant OID sur
+la <quote>clé primaire</quote> de l'index du catalogue, plutôt qu'une action directe sur la table
+elle-même.</para></listitem>
+
+</itemizedlist>
+
+<para> Un effet secondaire quelque part malheureu de ces actions sur les règles et les déclencheurs
+donne un effet de les <quote>piétiner</quote>. Dans la mesure où 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 contraintes ni les déclencheur, et surtout il ne s'attend pas
+à les voir associés à un indexe.</para>
+
+</answer>
+
+<answer> <para> Maintenant observer comment <xref linkend="stmtstoretrigger"/>
+entre en jeu.</para>
+
+<para> Mettez simplement cette commande pour que
+&slony1; restore les déclencheurs :
+<function>alterTableRestore(table id)</function>, qui restaure l'identifiant OID
+de la table dans <envar>pg_trigger</envar> ou
+<envar>pg_rewrite</envar> <envar>tgrelid</envar> sur le noeud 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>
+
+<screen>
+% pg_dump -h originnode.example.info -p 5432 --schema-only --schema=public ourdb > schema_backup.sql
+% pg_dump -h subscribernode.example.info -p 5432 --data-only --schema=public ourdb > data_backup.sql
+</screen>
+
+</answer>
+</qandaentry>
+
+<qandaentry> <question> <para> J'essaie de demander <xref
+linkend="stmtddlscript"/> ou <xref linkend="stmtmoveset"/>, et trouves
+les messages suivants sur l'un des abonnés :</para>
+
+<screen>
+NOTICE: Slony-I: multiple instances of trigger defrazzle on table frobozz
+NOTICE: Slony-I: multiple instances of trigger derez on table tron
+ERROR: Slony-I: Unable to disable triggers
+</screen>
+</question>
+
+<answer> <para> La difficulté semble venir du fait que
+vous ajouter un déclencheur à une table dont le nom rentre en conflit,
+avec le déclencheur que &slony1; cache. </para>
+
+<para> &slony1; cache des déclencheurs (sauf ceux marqués comme <quote>unhidden</quote>
+via <xref linkend="stmtstoretrigger"/>) en les attachant à la clé primaire de leur table.
+Dans le cas d'une clef étrangère, d'autre déclencheurs sont rajoutés afin de garantir la cohérence des données.
+Il est complètement inutile des les lancer depuis un abonné, ainsi ces déclencheurs doivent être provoquer
+depuis le noeud d'origine. En revanche, les déclencheurs de type
+<quote>cache invalidation</quote> sont ceux que vous devrez lancer depuis 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 des déclencheurs. </para> </answer>
+
+<answer> <para> Mais il peut y avoir quelques DBA intrépides, qui vont assumer individuellement ce travail on
+installant les déclencheur à la main sur l'abonné, et donc capable de créer ce genre de situation. Que faire?
+</para>
+
+<para> La réponse est assez simple : Retirez le déclencheur
+<quote>spécifique</quote> sur l'abonné avant de dérouler la restauration.
+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, la réponse serait de se connecter au noeud
+offensé, 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 ajouter le trigger à la main,
+ou, s'il y a plus de sagesse, de les réactiver avec
+<xref linkend="stmtstoretrigger"/>.</para>
+</answer>
+</qandaentry>
+
+<qandaentry id="neededexecddl">
+
+<question> <para> Comportement - tous les noeuds d'abonné, ainsi que le noeud maître,
+commence à se planter, crachant 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
+ERROR remoteWorkerThread_1: SYNC aborted
+</screen>
+</question>
+
+<answer> <para> Cause: you have likely issued <command>alter
+table</command> statements directly on the databases instead of using
+the slonik <xref linkend="stmtddlscript"/> command.</para>
+
+<para>La solution consiste à remettre le trigger sur la table affectée,
+et de corriger les données afférentes dans <xref linkend="table.sl-log-1"/> by hand.</para>
+
+<itemizedlist>
+
+<listitem><para> Vous avez besoin d'extraire du journal soit de slon, soit
+du &postgres; l'ordre sql exact qui a causé l'anomalie.</para></listitem>
+
+<listitem><para> Vous avez besoin de corriger le déclencheur Slony-defined dans la table
+en question. Ceci peut se faire à l'aide de la procédure suivante :</para>
+
+<screen>
+BEGIN;
+LOCK TABLE table_name;
+SELECT _oxrsorg.altertablerestore(tab_id);--tab_id is _slony_schema.sl_table.tab_id
+SELECT _oxrsorg.altertableforreplication(tab_id);--tab_id is _slony_schema.sl_table.tab_id
+COMMIT;
+</screen>
+
+<para>Ensuite vous avez besoin de sélectionner les enregistrements dans <xref
+linkend="table.sl-log-1"/> qui sont incohérent pour les corriger. Il faudra ensuite arrêter
+les processes de Slon pour l'ensemble des noeuds excepté celui du maître;
+de cette manière vous évitez que l'erreur se propage immédiatement à travers tous les noeuds.</para>
+
+<para> Voici un exemple:</para>
+
+<screen>
+BEGIN;
+
+LOCK TABLE customer_account;
+
+SELECT _app1.altertablerestore(31);
+SELECT _app1.altertableforreplication(31);
+COMMIT;
+
+BEGIN;
+LOCK TABLE txn_log;
+
+SELECT _app1.altertablerestore(41);
+SELECT _app1.altertableforreplication(41);
+
+COMMIT;
+
+--fixing customer_account, which had an attempt to insert a "" into a timestamp with timezone.
+BEGIN;
+
+update _app1.sl_log_1 SET log_cmddata = 'balance=''60684.00'' where pkey=''49''' where log_actionseq = '67796036';
+update _app1.sl_log_1 SET log_cmddata = 'balance=''60690.00'' where pkey=''49''' where log_actionseq = '67796194';
+update _app1.sl_log_1 SET log_cmddata = 'balance=''60684.00'' where pkey=''49''' where log_actionseq = '67795881';
+update _app1.sl_log_1 SET log_cmddata = 'balance=''1852.00'' where pkey=''57''' where log_actionseq = '67796403';
+update _app1.sl_log_1 SET log_cmddata = 'balance=''87906.00'' where pkey=''8''' where log_actionseq = '68352967';
+update _app1.sl_log_1 SET log_cmddata = 'balance=''125180.00'' where pkey=''60''' where log_actionseq = '68386951';
+update _app1.sl_log_1 SET log_cmddata = 'balance=''125198.00'' where pkey=''60''' where log_actionseq = '68387055';
+update _app1.sl_log_1 SET log_cmddata = 'balance=''125174.00'' where pkey=''60''' where log_actionseq = '68386682';
+update _app1.sl_log_1 SET log_cmddata = 'balance=''125186.00'' where pkey=''60''' where log_actionseq = '68386992';
+update _app1.sl_log_1 SET log_cmddata = 'balance=''125192.00'' where pkey=''60''' where log_actionseq = '68387029';
+
+</screen>
+</listitem>
+
+</itemizedlist>
+</answer>
+
+</qandaentry>
+
+<qandaentry>
+
+<question><para> Le noeud numéro 1 a été supprimé via <xref
+linkend="stmtdropnode"/>, et le &lslon; d'un des noeuds fait cracher le message
+d'erreurs suivant:</para>
+
+<screen>
+ERROR remoteWorkerThread_3: "begin transaction; set transaction isolation level
+ serializable; lock table "_mailermailer".sl_config_lock; select "_mailermailer"
+.storeListen_int(2, 1, 3); notify "_mailermailer_Event"; notify "_mailermailer_C
+onfirm"; insert into "_mailermailer".sl_event (ev_origin, ev_seqno, ev_times
+tamp, ev_minxid, ev_maxxid, ev_xip, ev_type , ev_data1, ev_data2, ev_data3
+ ) values ('3', '2215', '2005-02-18 10:30:42.529048', '3286814', '3286815', ''
+, 'STORE_LISTEN', '2', '1', '3'); insert into "_mailermailer".sl_confirm
+(con_origin, con_received, con_seqno, con_timestamp) values (3, 2, '2215', CU
+RRENT_TIMESTAMP); commit transaction;" PGRES_FATAL_ERROR ERROR: insert or updat
+e on table "sl_listen" violates foreign key constraint "sl_listen-sl_path-ref"
+DETAIL: Key (li_provider,li_receiver)=(1,3) is not present in table "sl_path".
+DEBUG1 syncThread: thread done
+</screen>
+
+<para> Evidemment une demande de <xref linkend="stmtstorelisten"/> n'avait pas encore
+été propagé avant que le noeud 1 soit éliminé.</para></question>
+
+<answer id="eventsurgery"><para> Ceci indique le cas où vous avez besoin de
+<quote>opération chirurgicale</quote> sur l'un ou plusieurs noeuds.
+Un évènement<command>STORE_LISTEN</command> demeure sans réponse lorsqu'il veut
+ajouter un port d'écoute qui <emphasis>ne peut pas</emphasis> être satisfait car
+le noeud 1 ainsi que tous les éléments indiquant ce noeud sont disparus.</para>
+
+<para> Supposons que pour la démonstration, les noeuds encore en place
+soient le 2 et le 3, ainsi le rapport d'erreur est remonté au noeud 3.</para>
+
+<para> cela implique que l'évènement se généré sur le noeud 2, comme il ne peut être sur le
+noeud 3, si il n'a pas été traité avec succès. La manière la plus facile à faire face à cette situation,
+est, de supprimer sur le noeud offensé, les données dans <xref linkend="table.sl-event"/> relatives au noeud 2.
+Vous vous connectez à la base du noeud 2, et à l'aide de Sql suivant, de chercher l'évènement
+<command>STORE_LISTEN</command>:</para>
+
+<para> <command> select * from sl_event where ev_type =
+'STORE_LISTEN';</command></para>
+
+<para> L'ordre peut ramener plusieurs lignes, mais ne en supprimer que la partie nécessaire.</para>
+
+<screen>
+-# begin; -- Don't straight delete them; open a transaction so you can respond to OOPS
+BEGIN;
+-# delete from sl_event where ev_type = 'STORE_LISTEN' and
+-# (ev_data1 = '1' or ev_data2 = '1' or ev_data3 = '1');
+DELETE 3
+-# -- Seems OK...
+-# commit;
+COMMIT
+</screen>
+
+<para> La prochaine fois que <application>slon</application> pour le noeud 3 redémarre,
+il ne trouvera plus le <quote>souffrant</quote> évènement
+<command>STORE_LISTEN</command>, et la réplication peur se poursuivre.
+(Vous pouvez par contre voir surgir un vieil évènement enregistré qui ne soit plus en phase
+avec la configuration existante...) </para></answer>
+
+</qandaentry>
+</qandadiv>
+
+</qandaset>
More information about the Trad
mailing list