Thanks Steve,<br><br>Your suggestions were very helpful. I fixed the problem by running the following code snippet directly against the slave right after registering the cluster on the master database. I am guessing there was some mismatch between the two. All fixed. Thanks.<br>
<br>#!/bin/bash<br>/usr/lib/postgresql/8.4/bin/slonik << _EOF_<br>cluster name = $CLUSTER;<br>node 1 admin conninfo = 'dbname=$DB1 host=$H1 user=$U';<br>node 2 admin conninfo = 'dbname=$DB2 host=$H2 user=$U';<br>
subscribe set (id = 1, provider = 1, receiver = 2, forward = yes);"<br>_EOF_<br><br><div class="gmail_quote">2010/4/18 Steve Singer <span dir="ltr"><<a href="mailto:ssinger@ca.afilias.info" target="_blank">ssinger@ca.afilias.info</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
albert wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Steve,<br>
</blockquote><div>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
This is very strange, the error is saying that the big if/else<br>
block in remote_worker.c isn't matching the events even the event<br>
name as printed in the above message looks okay.<br>
<br>
<br>
Well, that sounds interesting...<br>
<br>
Here's part of the log messages from the slony process running against the slave database during step 1, that is... when replication is setup for the first time and data is moved across correctly. Note that the above TODO: messages are also printed and then replication messages are logged and data is moved correctly (My test inserts some random data into the master database, sleeps for a while, then dumps both the slave and master databases and they get diffed)<br>
</blockquote>
<br></div>
This TODO error isn't the cause of your issue, one of the 'if' statements should be an 'else if' but that is causing that log message but it isn't causing a problem other than that.<br>
<br>
Which leads us back to why isn't your slave subscribing.<br>
<br>
Are there any locks open in the database (at the point that you've resubscribed things and are waiting for stuff to replicate?)<br>
<br>
select pg_locks.*, pg_class.relname FROM pg_locks, pg_class where pg_locks.relation=pg_class.oid;<br>
<br>
or something similar can show you that.<br>
<br>
Do you have any transactions that were started before you subscribed the set that haven't committed yet?<div><div></div><div><br>
<br>
<br>
<br>
<br>
<br>
-- <br>
Steve Singer<br>
Afilias Canada<br>
Data Services Developer<br>
416-673-1142<br>
</div></div></blockquote></div><br>