Rod Taylor wrote:

>>Thus, if the option, oh, call it "subscriber_lock", which defaults to 1,
>>is set to 0, then some if clauses won't be invoked:
>>
>>if (subscriber_lock) {
>>   lock_table(n);
>>}
>>
>>if (subscriber_lock) {
>>  try_to_truncate_table(n);
>>} else {
>>  just_delete_from(n);
>>}
>>
>>Does that seem like a good idea?
>>    
>>
>
>If you cannot get a lock on the subscriber how are you going to add the
>triggers for disallowing modifications?
>  
>
The difference between the two behaviours is thus:

 - "Exuberant" locking demands all of the locks up front, and locks out
all other users completely until the subscription is processed.

 - The former behaviour, "less exuberant locking", demands locks
incrementally, over time.  Old data remains accessible until the very
end when a complete exclusive lock is demanded in order to add those
triggers.

I'm fine with telling our users: "No, you can't touch the replica until
we're done subscribing," which is the "exuberant" approach.

Others have a problem with that.  Florian Pflug points out an example:

"When we had a few problems with our slony cluster, we had to regularly
reinitialize the whole cluster. That wouldn't have been a problem per se,
because it doesn't matter for us if the data is a few hours, or even a
day old.

But since all tables got locked, even for readers, while the subscription
took place, a reinitialization of the slony cluster was pretty disruptive"