On Tue, 2005-04-26 at 11:33 -0400, Christopher Browne wrote:
> It's not forcibly necessary that the subscriber's slon be running when
> SUBSCRIBE SET is issued; that generates an event, and puts in the queue
> to be processed, which can take place later.

I've got slon daemons running on both hosts (master and slave) and I've
issued the SUBSCRIBE SET.

It shows up on the master:

2005-04-26 18:09:41 BST DEBUG2 localListenThread: Received event 1,34939
SUBSCRIBE_SET

..and the slave:

2005-04-26 18:10:09 BST DEBUG2 remoteListenThread_1: queue event 1,34939
SUBSCRIBE_SET

> But yes, indeed, it's good to check in the subscriber's slon's logs to
> find the COPY_SET event.

There isn't a COPY_SET event, which is probably the problem. Just plenty
of messages like this:

2005-04-26 18:12:15 BST DEBUG2 remoteWorkerThread_1: SYNC 12413
processing
2005-04-26 18:12:16 BST DEBUG2 remoteWorkerThread_1: syncing set 1 with
4 table(s) from provider 1
2005-04-26 18:12:16 BST DEBUG3 remoteWorkerThread_1: activate helper 1
2005-04-26 18:12:16 BST DEBUG4 remoteWorkerThread_1: waiting for log
data
2005-04-26 18:12:16 BST DEBUG4 remoteHelperThread_1_1: allocate lines
2005-04-26 18:12:16 BST DEBUG4 remoteHelperThread_1_1: have 10 line
buffers
2005-04-26 18:12:16 BST DEBUG2 remoteHelperThread_1_1: 0.003 seconds
delay for first row

> And my first "wild guess" is that perhaps there is only 1 slon running,
> thereby supporting 1 node...

-j
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://gborg.postgresql.org/pipermail/slony1-general/attachments/20050426/037c67b0/attachment.bin