Oh, OK. Yes, I neglected to mention the platform: Solaris 8 (sparc). I
see from the beta2 notes that this is one of the platforms that requires
the patched libpq. Thanks.

- DAP

-----Original Message-----
From: Jan Wieck [mailto:JanWieck at Yahoo.com] 
Sent: Thursday, June 10, 2004 10:09 AM
To: David Parker
Cc: Slony-I Mailing List
Subject: Re: [Slony1-general] re-post: running slony pgbench sample

On 6/10/2004 9:55 AM, David Parker wrote:

> Hi. I'm reposting this because apparently gborg hadn't actually signed

> me up for the list before. Apologies if it ends up being a duplicate.
> =================================================================
> 
> I think I have things more or less configured, but I still seem to be 
> missing something. When I try to run my second slon process (both 
> databases are in the same cluster), I get the following output:
> 
> CONFIG main: local node id = 2
> CONFIG main: loading current cluster configuration CONFIG storeNode:
> no_id=1 no_comment='Node 1'
> DEBUG2 setNodeLastEvent: no_id=1 event_seq=19 CONFIG storePath:
> pa_server=1 pa_client=2 pa_conninfo="dbname=pgbench1 port=24101"
> 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 
> pgbench tables'
> WARN   remoteWorker_wakeup: node 1 - no worker thread
> DEBUG2 sched_wakeup_node(): no_id=1 (0 threads + worker signaled) 
> CONFIG
> storeSubscribe: sub_set=1 sub_provider=1 sub_forward='t'
> WARN   remoteWorker_wakeup: node 1 - no worker thread
> DEBUG2 sched_wakeup_node(): no_id=1 (0 threads + worker signaled)
> DEBUG2 main: last local event sequence = 10 CONFIG main: configuration

> complete - starting threads
> DEBUG1 localListenThread: thread starts CONFIG enableNode: no_id=1
> DEBUG1 main: running scheduler mainloop
> DEBUG1 remoteWorkerThread_1: thread starts
> DEBUG1 remoteListenThread_1: thread starts
> DEBUG2 remoteListenThread_1: start listening for event origin 1
> DEBUG1 cleanupThread: thread starts
> DEBUG1 syncThread: thread starts
> DEBUG4 remoteWorkerThread_1: update provider configuration
> DEBUG1 remoteListenThread_1: connected to 'dbname=pgbench1 port=24101'
> DEBUG2 remoteListenThread_1: queue event 1,20 ENABLE_SUBSCRIPTION
> DEBUG2 remoteListenThread_1: queue event 1,21 SYNC ....
> DEBUG2 remoteListenThread_1: queue event 1,59 SYNC
> DEBUG2 remoteListenThread_1: queue event 1,60 SYNC
> DEBUG2 remoteWorkerThread_1: Received event 1,20 ENABLE_SUBSCRIPTION
> DEBUG1 copy_set 1
> DEBUG1 remoteWorkerThread_1: connected to provider DB
> DEBUG2 remoteWorkerThread_1: copy table public.accounts
> DEBUG3 remoteWorkerThread_1: table public.accounts does not require 
> Slony-I serial key ERROR  remoteWorkerThread_1: PQputCopyData() - 
> could not receive data from server: Error 0

You are running this on a platform that requires libpq to be built with
--enable-thread-safety (Solaris or AIX?).


Jan

> WARN   remoteWorkerThread_1: data copy for set 1 failed - sleep 15
> seconds
> 
> I suspect that the problem has to do with the first WARN log that
there
> is no worker thread, but I don't know if that's relevant, or how that
> situation can come about.
> 
> Where should I start looking for configuration mistakes? Thanks.
> 
> 
> -  DAP
> ====================================================== 
> David Parker    Tazz Networks    (401) 709-5130
>  
> 
> _______________________________________________
> 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 #