Dave Page wrote:

>
>Why are such actions not performed on the origin node as a matter of
>course (see below before answering that :-) )?
>  
>

Ask Slony's designers :-) Actually, at least storenode() changed its 
requirements; in 1.0.5, it must be called on the subscriber, in 1.1.1 on 
the provider. I hope I didn't overlook more of those.

>  
>
>>>Perhaps for older
>>>versions (well 1.1) we need to just find sets as we connect to any
>>>individual databases, and use your original plan for 1.2 in 
>>>      
>>>
>>which we use
>>    
>>
>>>a separate table as Jan/Chris have suggested?
>>>      
>>>
>>While I'm not particularly fond of doing things in 1.2+ 
>>different from 
>>1.0-1.1, this is certainly not a real problem.
>>What *is* a problem is scanning all servers and databases to find a 
>>suitable connection, this won't work for several reasons:
>>- we might hit a cluster with the same name, which is actually a 
>>different one.
>>- This may take a very long time. I have several remote servers 
>>registered, which aren't accessible until I connect via VPN. It would 
>>take some minutes until all timeouts elapsed.
>>    
>>
>
>I'm not suggesting a full search at connect, just that we populate the
>trees etc only when we do actually connect to an individual database.
>  
>
??? How can we know whether a non-connected server contains a cluster, 
and if that cluster's name  is not just by chance identical to ours?

>
>Which is why you can't use the origin I guess - because you are unlikely
>to be able to access the origin when you need to failover, but need to
>be sure that pgAdmin knows about the most recent configuration before
>doing anything potentially dangerous. Hmmm... Think I see what you mean
>now (at last)!!
>  
>

No, failover must explicitely be executed on all non-failed nodes. In 
the failover case, you can't rely on the replication network to transfer 
those commands, thus direct connection is needed.

As I already pointed out, I've put quite some stress on my 1.2CVS 
yesterday. Apparently, the event queue isn't touched by new nodes until 
a slon process has been running on the new node the first time, thus 
preventing the new node to hold up the queue cleanup process. This makes 
perfectly sense, since until a node did its first cry there's no need to 
feed it, and complain if it doesn't eat. This makes the issue about 
non-active nodes a storm in a teacup, we simply can go on as it's now. 
Having listens generated that will never be listened on remains as 
unaesthetic (and easily fixable), but not a problem.

Regards,
Andreas