Miguel wrote:

> 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?
>
No, happily you are incorrect about that.

The *subscriber* is either partly or entirely locked up (there are some
variations based on time and what version of Slony-I you are running).

But the *provider* doesn't involve those locks.

On the origin, there is a brief table lock required when SET ADD TABLE
is run; that action modifies the table to add the logtrigger trigger and
stored procedure.  But that is just a very brief lock, once,
independently, for each table.  That shouldn't destroy the usability of
the "master node."

>>> 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

If you can suggest where that section of the documentation could be made
clearer, that would be useful, and I'd be more than happy to improve that.