Jan Wieck <JanWieck at Yahoo.com> writes:
> On 11/21/2007 6:35 PM, Jacques Caron wrote:
>> Hi,
>> The following patch adds a new column to sl_table: tab_lock_order,
>> and modifies the order in which tables are locked during all calls
>> that require extensive locking (i.e. all those that call
>> alterTableForReplication or alterTableRestore on a set of tables):
>> they are locked in coalesce(tab_lock_order,0),tab_id order rather
>> than random order or just tab_id order.
>
> This is a very good idea and I certainly appreciate the patch. The
> problem is that as the Postgres main project, the Slony team is rather
> reluctant to accept new functionality into existing stable branches.
>
> I do see how this change is entirely backwards compatible. But we'd
> definitely need a broad consensus on this.

I agree; I think it's an interesting "possible feature," and that it
might be a good one to put in CVS HEAD.

I also think it would be a necessary thing to, *before* adding it,
have an outline of a test case where it allows things to work where,
at present, things are broken.

The downside to it, as I see it, is that it adds a fair bit of
additional complexity when we don't have clear cases (heading back to
the "test case" thing) where it is known to help.

My sense is that this may be fixing a really narrow problem, and it
would be unfortunate to add the fair bit of complexity to the codebase
to solve a truly rare problem.  I may be wrong; that's why "broad
consensus" represents more than just two opinions :-).
-- 
(format nil "~S@~S" "cbbrowne" "cbbrowne.com")
http://www3.sympatico.ca/cbbrowne/nonrdbms.html
"Suppose  you  were  an  idiot.   And  suppose you  were  a  member  of
Congress. But I repeat myself."  -- Mark Twain