No slon running because script launch slon after create set.

So i launch before and IT WORKS !!! thx master ! thanks you so much

I don't know what it change in slony 2.0.7 and 2.2 but before i could do
this

But now it's ok :)

-----Message d'origine-----
De : Steve Singer [mailto:ssinger at ca.afilias.info] 
Envoyé : mercredi 16 octobre 2013 17:56
À : Sebastien Marchand
Objet : Re: [Slony1-general] Problem slony 2.2 and pg 9.3 double replication

On 10/16/2013 11:52 AM, Sebastien Marchand wrote:
> Yes that's why i will delete all replication 2.0 and migrate 
> postgresql after i rebuild new replication.
>
> when i've my  error  " waiting for event (1,5000000004) to be 
> confirmed on node 110 " in postgresql if i do :
>
> select  * from _repli_local110.sl_path; => 1;110;"dbname=RPP2 
> host=192.168.0.101 port=5432 user=slony
> password=123";10
>
> Why just one line ?? i need two lines !
>
> In my sl_event :
>
> 110;5000000001;"2013-10-16
> 17:50:54.697374+02";"695958:695958:";"STORE_PATH";"1";"110";"dbname=RP
> P2
> host=192.168.0.101 port=5432 user=slony password=123";"10";"";"";"";""
>
> I think there is a problem here... or not

Slonik when it executes the STORE PATH , it will insert a row in sl_path on
each node.

When slon is running it will then replicate the STORE_PATH event from one
node to the other to create the second sl_path row in each node.

Is your slon running?


>
> -----Message d'origine-----
> De : Steve Singer [mailto:ssinger at ca.afilias.info] Envoyé : mercredi 
> 16 octobre 2013 17:02 À : Sebastien Marchand Cc : 
> slony1-general at lists.slony.info Objet : Re: [Slony1-general] Problem 
> slony 2.2 and pg 9.3 double replication
>
> On 10/16/2013 10:57 AM, Sebastien Marchand wrote:
>> I already tried to put in script but no change.
>>
>> Can you tell me where is the line of code that is generating this error ?
>> it's a sql function ?
>>
>> I continue to search i need this to migrate.
>
>
>
> 	slon_mkquery(&query, "select max(ev_seqno) FROM \"_%s\".sl_event"
> 				 " , \"_%s\".sl_node "
> 				 " where ev_origin= "
> 				 "     (select last_value from
> \"_%s\".sl_local_node_id) "
> 				 " AND %s AND sl_node.no_id="
> 				 " ev_origin"
> 				 ,script->clustername, script->clustername,
> 				 script->clustername, event_filter);
>
>
> In slonik.c
>
>
> slonik_get_last_event_id(SlonikStmt * stmt,
> 						 SlonikScript * script,
> 						 const char *event_filter,
> 						 int64 **events)
>
>
> Also, if you are planning on migrating from 2.0 to 2.2 with UPDATE 
> FUNCTIONS you should be aware of bug #320
>
>
>>
>> -----Message d'origine-----
>> De : Steve Singer [mailto:ssinger at ca.afilias.info] Envoyé : mercredi 
>> 16 octobre 2013 16:53 À : Sebastien Marchand Cc : 
>> slony1-general at lists.slony.info Objet : Re: [Slony1-general] Problem 
>> slony 2.2 and pg 9.3 double
> replication
>>
>> On 10/16/2013 10:48 AM, Steve Singer wrote:
>>> On 10/16/2013 10:06 AM, Sebastien Marchand wrote:
>>>>> CLUSTER NAME = repli_local110 ;
>>>>> NODE 101 ADMIN CONNINFO = 'dbname=RPP2 host=192.168.0.101 
>>>>> port=5432 user=slony password=password'; NODE 110 ADMIN CONNINFO =
>>>>> 'dbname=RPP2 host=192.168.0.110 port=5432 user=slony 
>>>>> password=password';
>>>>
>>>> It's the file repli_local110.preamble but for email i copy this 
>>>> file in my script :)
>>>
>>
>> Actually IGNORE what I said below,
>> I hit send way too quickly before reviewing my output.
>>
>> I am NOT yet able to reproduce this, but try pasting your preamble 
>> inline and see if it works.
>>
>> I think I see the line of code that is generating the error you are 
>> seeing but I don't understand how/why it is substituting using 
>> _sloncluster instead of repli_local10;
>>
>>
>>
>>
>>> Sometimes details are important.
>>>
>>> Copy the preamble file inline into your script and it will work 
>>> (like you did in your email)
>>>
>>> I can reproduce your issue with the preamble moved to a different file.
>>>     This is a bug, it shouldn't be hard to fix, thanks for reporting it.
>>>     I suspect the fix will be included in 2.2.1 due in the next few 
>>> weeks (since this has been a busy week for 2.2.0 bugs - ie #318 and
> #320).
>>>
>>>
>>
>