On 12/14/2004 10:08 PM, Christopher Browne wrote:
> James Black wrote:
> 
>> Hello, all,
>>
>> Thanks for the help last week; I tracked the problem that I was having 
>> merging sets to a) user error, and b) misconfigured slon daemons.  
>> Adding and merging now works great, but it raises a question about set 
>> ordering.  I was under the impression that ordering the tables in the 
>> set was important, and a misordering would have dreadful 
>> consequences.  Is this the case?  And if so, when adding tables that 
>> have dependencies on tables already in the set, do we need to reorder 
>> the tables?  Is a reordering even possible?
>>
>> Or should I not worry so much?
>>
>> Thanks in advance,
>> jfb
>>
> In theory, it might be of some kind of significance in the handling of 
> foreign key constraints, but those are deactivated on subscriber nodes 
> anyways, so it doesn't matter what order the values come in (at least 
> not as far as a table ordering is concerned).

The order of table ID's is only significant during a LOCK SET in 
preparation of switchover. If that order is different from the order in 
which an application is acquiring its locks, it can lead to deadlocks 
that abort either the application or slonik.


Jan

> 
> If someone can point out a simple example of a "dreadful" consequence, 
> that would be well worth hearing about.
> 
> As for being able to reorder them, no, there's not much of an option of 
> that...
> 
> We're hoping for 1.1 to support naming _nodes_, so that you can largely 
> ignore the node numbers, and give mnemonic identifiers; that points 
> towards numeric identifiers getting less important in and of 
> themselves.  Not that that directly addresses table numbers...
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #