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.

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