Jim C. Nasby wrote:

>On Tue, Mar 07, 2006 at 03:36:57PM +0800, Christopher Kings-Lynne wrote:
>  
>
>>>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.
>>>      
>>>
>>Which is exactly why pg_dump does the saem thing.
>>    
>>
>
>  
>
No, this is NOT like pg_dump.  pg_dump takes out locks on the data
*provider* that would cause DDL requests to get held back.

The relevant behaviour under discussion is about what happens on the
SUBSCRIBER; the node that is receiving the data.

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

Does anyone see anything particularly horrible about that idea?