On 10-10-29 10:24 AM, Jason Chen wrote:
> Hi Steve,
>
>  >If you turn up the logging level to debug , what does slon report in
> the log in cases where it doesn't work.   I must be logging some stuff
> even if it then stops/hangs.
>
> I have attached the normal configuration and error configuration master
> node log. Can you take a look and see if there is anything abnormal?
>
>  >slon using the connection settings from the service config to connect
> to its 'local' database that it generates the syncs on.  It sounds like
> slon isn't able to talk to this database.
>
> Is there any log we can check on that since postgresql on the master
> node runs well?
>
> Please also let me know if you need other more information.
>
> Thanks,
> Jason
>

The error log stops after a few minutes.  Does slon just stop writing to 
the file?

As you can see in the normal log file,
the localListener thread sees the STORE NODE event and then the STORE 
PATH event a bit further down.

2010-10-29 15:01:38 UTCDEBUG2 localListenThread: Received event 
1,5000000179 STORE_NODE
2010-10-29 15:01:38 UTCCONFIG storeNode: no_id=2 no_comment='slave'


Once it processes that store node event it then starts the remoteWorker 
and remoteListener threads that actually do stuff

In the error case, if you query the sl_event table on the master you 
should see the STORE NODE and STORE PATH events. (this is worth 
confirming).  The question is why is the slon not getting to this 
events. What event numbers are assigned to them?

In the error case it got as far as 1,5000000081  in the normal case the 
STORE NODE event was 1,5000000180 so if the time from when you started 
slon until when you ran the storeNode is similar in both cases then you 
still have a fair number of events left to process (though processing 
100 SYNC events when no tables are replicated should be pretty fast)