Log Message:
-----------
Added another idiosyncracy, namely that you can't have two subscribers
loading data at the same time.

Modified Files:
--------------
    slony1-engine/doc/howto:
        helpitsbroken.txt (r1.1 -> r1.2)

-------------- next part --------------
Index: helpitsbroken.txt
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/howto/helpitsbroken.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -Ldoc/howto/helpitsbroken.txt -Ldoc/howto/helpitsbroken.txt -u -w -r1.1 -r1.2
--- doc/howto/helpitsbroken.txt
+++ doc/howto/helpitsbroken.txt
@@ -7,7 +7,7 @@
 Here are some things other people have stumbled over that might help
 you to "stumble more quickly."
 
-1.  I looked for the _clustername namespace, and it wasn't there!
+1.  I looked for the _clustername namespace, and it wasn't there.
 
 If the DSNs are wrong, then slon instances can't connect to the nodes.
 
@@ -92,3 +92,43 @@
 If you have
    key = 'nspace.key_on_whatever'
 the request will FAIL.
+
+8.  I'm trying to get a slave subscribed, and get the following
+messages in the logs:
+
+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
+
+Oops.  What I forgot to mention, as well, was that I was trying to add
+TWO subscribers, concurrently.
+
+That doesn't work out: Slony-I won't work on the COPY commands
+concurrently.  See src/slon/remote_worker.c, function copy_set()
+
+This has the (perhaps unfortunate) implication that you cannot
+populate two slaves concurrently.  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.
+
+It could also be possible for there to be an old outstanding
+transaction blocking Slony-I from processing the sync.  You might want
+to take a look at pg_locks to see what's up:
+
+
+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)
+
+See?  127314921 is indeed older than 127314958, and it's still running.
+
+$ ps -aef | egrep '[2]605100'
+postgres 2605100  205018   0 18:53:43  pts/3  3:13 postgres: postgres sampledb localhost COPY 
+
+This happens to be a COPY transaction involved in setting up the
+subscription for one of the nodes.