On Tue, March 7, 2006 21:04, Christopher Browne said:
> Jim C. Nasby wrote:
>>On Tue, Mar 07, 2006 at 03:36:57PM +0800, Christopher Kings-Lynne wrote:
>>Wait, are we talking about exclusive locks here? Or do we just aquire
>>shared locks to prevent anyone from running DDL against the objects?
>>
> This is exclusive locks, but let me make it clear, the locking under
> discussion is taking place on the SUBSCRIBER, not on the ORIGIN.
>
> On the subscriber, the rough set of things that are done used to be:
>
> - Check that the 22 tables being replicated are there, and have
> PK/candidate PK
> Then, for each table...
>   - Delete all existing entries from it; if we have subtransactions,
> then try to truncate it (TRUNCATE will take out a pretty exclusive lock)
>   - Copy the data from the source
> endloop
> Alter all 22 tables to add the "denyaccess()" trigger
>
> In 1.2, it changes a bit...
>
> - Check that the 22 tables being replicated are there, and have
> PK/candidate PK.  Lock the table as we go...
> Then, for each table...
>   - Delete all existing entries from it; if we have subtransactions,
> then try to truncate it (TRUNCATE will take out a pretty exclusive lock)
>   - Copy the data from the source
> endloop
> Alter all 22 tables to add the "denyaccess()" trigger.
>
> It sounds to me as though there might be value in having a slon option
> that controls the two bits of "particularly lock-happy" logic so that,
> for people who really know what they are doing, the locking regimen can
> be less, erm, "harsh."
>
> Proposal for alternative: RFC
>
> There is a case to be made that people might want to have access to the
> old data until such time as it gets replaced by new data.  (And if they
> drop a "deadlock bomb" on Slony-I, that's the risk they are taking on...)
>
> 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?

I quite like it ;-) One things that comes to my mind is that
slony should do a vacuum between delete_from(n) and copy_into(n).
Otherwise, the table suddenly grows to twice it's size, and even
more if the long-running subscribe-event fails a few times (We've
had that problem due to network outages).

greetings, Florian Pflug