On 10/10/2004 1:58 PM, Curtis Zinzilieta wrote:
> 2 boxes setup, labsoft is master, ditto is the backup.  Copy schema
> over to ditto, startup slon
> on ditto and get:
> 
> [postgres at ditto postgres]$ ./slony-demon-host2.sh
> CONFIG main: local node id = 2
> CONFIG main: loading current cluster configuration
> CONFIG storeNode: no_id=1 no_comment='Node 1'
> CONFIG storePath: pa_server=1 pa_client=2 pa_conninfo="dbname=lab
> host=labsoft user=postgres" pa_connretry=10
> CONFIG storeListen: li_origin=1 li_receiver=2 li_provider=1
> CONFIG storeSet: set_id=1 set_origin=1 set_comment='All labsoft tables'
> WARN   remoteWorker_wakeup: node 1 - no worker thread
> CONFIG storeSubscribe: sub_set=1 sub_provider=1 sub_forward='t'
> WARN   remoteWorker_wakeup: node 1 - no worker thread
> CONFIG main: configuration complete - starting threads
> CONFIG enableNode: no_id=1
> ERROR  remoteListenThread_1: timeout for event selection
> ERROR  remoteListenThread_1: timeout for event selection
> ERROR  remoteListenThread_1: timeout for event selection
> ERROR  remoteListenThread_1: timeout for event selection
> ERROR  remoteListenThread_1: timeout for event selection
> ERROR  remoteListenThread_1: timeout for event selection

Timeout for event selection ... hmmm ... that means that the listener 
thread received a NOTIFY, but that it cannot receive a result for the 
pending events on that node within several seconds. Is there some 
locking issue with the sl_event table?


Jan

> CONFIG enableSubscription: sub_set=1
> 
> The WARNS are curious, since there is no connectivity issues between
> the machines
>  (and a test replication of the same DB between two other test computers worked
> fine earlier).  The ERROR lines are concerning, however.  Is this
> indicative of an unrecovered error?
> 
> Then ran the subscribe set script on the master (again, had run
> without error output on
> other systems earlier) and got the following:
> 
> [postgres at labsoft postgres]$ ./lab_slonysetup_start_replication.sh
> <stdin>:18: PGRES_FATAL_ERROR select "_echo8".subscribeSet(1, 1, 2,
> 't');  - ERROR:  Slony-I: set 1 is not active, cannot change provider
> CONTEXT:  PL/pgSQL function "subscribeset" line 41 at perform
> [postgres at labsoft postgres]$
> 
> This looks much more problematic.  What is the indications of where I
> have a problem?  I guess my thought is that I have some issue with my
> schema, even
> though I had run testing with the previous day's backup on different
> computers.  Where
> do I start debugging this, or is everything ok?  I expect I need to
> make some kind of
> corrections here, but don't know where to start.  Havent yet went digging thru
> the sourcecode...
> 
> Thanks,
> 
> -Curtis
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #