On 8/30/2004 12:49 AM, Ben wrote:

> Both master and slave databases are brand new.... maybe 25 seconds old 
> by the time I start slon. :) So no stale transactions laying around. In 
> fact, they haven't seen any connections at all, save from the slony 
> scripts.
> 
> Might this be because my postgres version is a little behind the times?

After all it is a warning, not an error. Wait for 15 seconds, don't slam 
on the red panic button, and the subscriber slon will try it again. If 
there are no others that slonik's and slon's causing open transactions 
as you say, that'll do just fine.


Jan

> 
> 
> On Aug 29, 2004, at 8:45 PM, Christopher Browne wrote:
> 
>> Ben said:
>>> Hey guys,
>>>
>>> I'm trying to get slony going on my 7.4.2 postgres install on linux,
>>> and I'm running into problems.
>>>
>>> Things seem to be going great until I start up slon on the slave. I 
>>> see
>>> this:
>>>
>>>
>>> WARN   remoteWorker_wakeup: node 1 - no worker thread
>>>
>>>
>>> Then, once I start replication, I see a lot of stuff like this on the
>>> slave:
>>>
>>> WARN   remoteWorkerThread_1: transactions earlier than XID 109105155
>>> are still in progress
>>> WARN   remoteWorkerThread_1: data copy for set 1 failed - sleep 15
>>> seconds
>>>
>>> I've read reports that libpq sometimes needs to be compiled with 
>>> thread
>>> safety turned on, but the same things say that's not the case on 
>>> linux.
>>> So.... thoughts?
>>
>> That sounds somewhat consistent with the "threads issue," except that 
>> yes,
>> that's not a Linux issue.  (It has bitten me on both Solaris and AIX 
>> :-(.)
>>
>> You should take a peek at what transactions are open on the "master" 
>> DB.
>> Perhaps there's a pretty old connection open.
>>
>> I have seen this, restarted the postmaster (forcibly terminating any 
>> O/S
>> connections), and watched the copying proceed.
>>
>> I don't really like that "solution" any more than I like the notion of
>> rebooting systems just because that seems to 'do the trick.'  But at 
>> any
>> rate, take a look at what locks are open by doing "SELECT * FROM
>> PG_LOCKS;"  That may tell you what old process is still hanging around.
>>
>> There's a documentation file where it would be nice to drop docs on 
>> this
>> so that we could, in future, point to "See item #17 on the 'typical
>> problems' list."
>> -- 
>> (reverse (concatenate 'string "ofni.sailifa@" "enworbbc"))
>> <http://dev6.int.libertyrms.info/>
>> Christopher Browne
>> (416) 646 3304 x4124 (land)
> 
> _______________________________________________
> 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 #