Andy frum at ar-sd.net
Tue Apr 17 07:51:58 PDT 2007
Well, 

The replication on set 4 does not work. That is 100%. Also after I subscribe
the table, the t4 table is not blocked on db c. 

I tried to subscribe/unsubscribe many times the t4 set without success. I
restarted slony/postres, even the server the same behavior. 


I dropped node 3, dropped the database, recreated the db/schema/node/paths
in the replication. After that I subscribed node 3 to set1 with provider 2.
Replication worked. After that I subscribed node 3 to set 4 provider 1. HERE
IT FAILED. Set 1 also stopped from this point to replicate.


Thank you for help, 
I donno what I miss here, 

Andy.



Here are all the scripts:

cluster name=replic_loco1;
NODE 1 ADMIN CONNINFO = 'dbname=a host=127.0.0.1 user=slony port=5432';
NODE 2 ADMIN CONNINFO = 'dbname=b host=127.0.0.1 user=slony port=5432';
NODE 3 ADMIN CONNINFO = 'dbname=c host=127.0.0.1 user=slony port=5432';

init cluster (id=1, comment='replic_loco Master Node');
store node (id=2, comment='replic_loco Subscriber Node 1');
store node (id=3, comment='replic_loco Subscriber Node 2');



STORE PATH (SERVER=1, CLIENT=2, CONNINFO='dbname=a host=127.0.0.1 user=slony
port=5432');
STORE PATH (SERVER=2, CLIENT=1, CONNINFO='dbname=b host=127.0.0.1 user=slony
port=5432');

STORE PATH (SERVER=1, CLIENT=3, CONNINFO='dbname=a host=127.0.0.1 user=slony
port=5432');
STORE PATH (SERVER=3, CLIENT=1, CONNINFO='dbname=c host=127.0.0.1 user=slony
port=5432');

STORE PATH (SERVER=2, CLIENT=3, CONNINFO='dbname=b host=127.0.0.1 user=slony
port=5432');
STORE PATH (SERVER=3, CLIENT=2, CONNINFO='dbname=c host=127.0.0.1 user=slony
port=5432');



create set (id=1, origin=1, comment='replic_loco SET 1');
set add table (id=1, set id=1, origin=1, fully qualified name='public.t1',
comment='replic_loco table public.t1');

subscribe set (id=1, provider=1, receiver=2, forward=yes); 




create set (id=2, origin=2, comment='replic_loco SET 2');
set add table (id=2, set id=2, origin=2, fully qualified name='public.t2',
comment='replic_loco table public.t2');

subscribe set (id=2, provider=2, receiver=3, forward=yes); 




create set (id=3, origin=1, comment='replic_loco SET 3');
set add table (id=3, set id=3, origin=1, fully qualified name='public.t3',
comment='replic_loco table public.t3');

subscribe set (id=3, provider=1, receiver=2, forward=yes); 


create set (id=4, origin=1, comment='replic_loco SET 4');
set add table (id=4, set id=4, origin=1, fully qualified name='public.t4',
comment='replic_loco table public.t4');

subscribe set (id=4, provider=1, receiver=3, forward=yes); 




> -----Original Message-----
> From: slony1-general-bounces at lists.slony.info 
> [mailto:slony1-general-bounces at lists.slony.info] On Behalf Of 
> Andrew Sullivan
> Sent: Tuesday, April 17, 2007 4:28 PM
> To: Christopher Browne
> Cc: slony1-general at lists.slony.info
> Subject: Re: [Slony1-general] Can this be done with slony?
> 
> On Mon, Apr 16, 2007 at 05:49:27PM -0400, Christopher Browne wrote:
> > And that error message *tends* to indicate that the state 
> of the slon 
> > process is (somehow, not for any particularly well 
> explicable reason) 
> > somewhat deranged as it is not aware of connection information for 
> > node #1.
> 
> My guess in this case is that it has something to do with 
> both the order and speed of the various subscription 
> requests.  (Hmm.  I bet that's at least one clue on how to 
> reproduce this strange bug.)
> 
> A
> 
> --
> Andrew Sullivan  | ajs at crankycanuck.ca
> When my information changes, I alter my conclusions.  What do 
> you do sir?
> 		--attr. John Maynard Keynes
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general
> 
> 



More information about the Slony1-general mailing list