Christopher Browne wrote:

>Miguel wrote:
>
>  
>
>>does slony need exclusive lock for this initial transfer?
>> 
>>
>>    
>>
>It will ultimately need exclusive locks on the subscriber in order to
>complete the copy, as it will be modifying the table schemas a bit.
>
>  
>
I dont mind exclusive lock on the subscribers,  but the master node is 
my production machine,  i cant  stop  the applications during the 
initial transfer.
Reading the docs , in section 10 Locking Issues, you can read

Unfortunately, there are several sorts of Slony-I events that do require 
exclusive locks on PostgreSQL tables, with the result that modifying 
Slony-I configuration can bring back some of those "locking 
irritations." In particular:

[...]
* During the COPY_SET event on a new subscriber
In a sense, this is the least provocative scenario, since, before the 
replication set has been populated, it is pretty reasonable to say that 
the node is "unusable" and that Slony-I could reasonably demand 
exclusive access to the node.
[...]

I understand that during the initial transfer, the cluster is unusable 
by the applications, is this asumption correct?

>>also, if i dont start the slon process, the master node  operate  in 
>>normal "mode" , i mean, slony-i agnostic?
>> 
>>
>>    
>>
>I'm not quite sure what you mean by that.
>
>If you don't start a slon for the node that is the origin for a set, then:
>
>- tuples will build up in sl_log_1 as tables that were added to
>replication sets are modified, and will never be cleaned out.
>- no SYNC events will get issued, thereby preventing event activity from
>propagating.
>
>Maybe you could explain what you think a "normal mode" is, or what
>"Slony-I agnostic" means; we might be able to correct some
>misunderstandings, there...
>
>  
>
with your explanations, all is clear now,
 with agnostic and normal i mean like there isnt any  slony program 
installed, but you are right, the slony overhead is always there, only 
the replication process is stopped, the sl_log_1 will grow a lot,
thanks