I am having what I think is the same problem described in section 2.3
from http://www.pgadmin.org/docs/1.4/slony/faq.html#id2602106:

=== QUOTE ====================================================
2.3.

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

There is evidently some reasonably 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.

A long running G/L report, a runaway RT3 query, a pg_dump, 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 " data copy for set 1 failed - sleep 60 seconds ".

By the way, if there is more than one database on the PostgreSQL
cluster, and activity is taking place on the OTHER database, that will
lead to there being "transactions earlier than XID whatever" being
found to be still in progress. The fact that it's a separate database
on the cluster is irrelevant; Slony-I will wait until those old
transactions terminate.
=== END QUOTE ===============================================

I am perplexed by the last paragraph above. I may be naive, but why in
the world does Slony wait on transactions that are on other databases
that have no relation to any replicated objects?

We have a schema that has several relatively small tables with lots of
foreign-key relationships. The schema also has a couple of relatively
large history tables that have zero foreign-key relationships. Many
times (but not all the time!), Slony will be unable to SYNC while a
large index is being built on one of these large tables. I repeat that
these large tables are not part of any replication set and have no FKs
to any replicated objects. WHY does Slony wait behind these
transactions?

Thank you.