Florian G. Pflug wrote:

> Christopher Browne wrote:
>
>> "Florian G. Pflug" <fgp at phlo.org> writes:
>>
>>> Christopher Browne wrote:
>>>
>>>> - Subscribe set aggressively locks tables on the subscriber to avoid
>>>> failures
>>>
>
>>> Does this mean slony 1.2 will lock more aggressivly, or less so?
>>
>>
>> Moreso, in a few places.
>
> I was hoping that the changes planned for 1.2 would let me read the
> old contents of a table while it in the process of being subscribed.
>
That can't work when we use TRUNCATE to clear out the old contents;
TRUNCATE demands a pretty hefty lock in order to "own" the table
sufficiently to be able to clear it out safely.

> When whe 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
>
>> The notable thing is that when you request SUBSCRIBE SET, it will
>> attempt to lock all of the tables in the set on the subscriber for the
>> duration of the subscription event.
>>
>> I'd call that "more aggressively."
>>
>> What used to happen is that the tables would gradually get locked,
>> piecemeal, as Slony-I got to each one.  You could run into deadlock
>> problems right near the end, which is a real waste.  By locking them
>> up front, any failures will take place before any data is copied, so
>> this minimizes time wastage.
>
> Ok, so it's not the "strength" of the locks that change, but rather
> the time
> of their acquisition.
>
> greetings, Florian Pflug

Yeah, that's pretty much it.

The point of the exercise here is to acquire the locks up front so that
the copy doesn't get half way done and then fail because something was
holding onto a lock that turned into a deadlock.

We've gotten bitten by that a few times, and want to help people avoid it...