Christopher Browne wrote:

>>Currently I know of these differences:
>>storenode with third parameter (new in 1.1 or 1.2?)
> 
> 
> Are you talking about SPOOLNODE?  That's new in 1.1
> 
> There always were the three parameters:
>  - ID (obviously needed!)
>  - Comment
>  - Event Node

I remember having my stuff working on 1.05 with 2 params only.

>>ddlscript (1.1 or 1.2?)
> 
> 
> That was available in 1.0.5, if not earlier.

Good. Are there any more differences to mention?

> Generating sl_listen automatically was/is a good idea.

Yup.
> 
> The thing that you need to think about reasonably hard is what ought to
> be in sl_path.

Agreed.

> The typical "simple scenario" involves there being fairly much symmetric
> paths between all nodes.
> 
> Life gets more complex if you have weird firewalls in your environment
> that lead to asymmetries in the paths, where the path from A to C isn't
> at all similar to the path from B to C.
> 
> It seems to me to be a perfectly fine idea to have a "pseudo node" that
> pgAdmin uses for its own purposes to store configuration data.  But that
> node should NOT be included in the configuration of the cluster proper,
> as, if it hasn't got a slon connected, it won't process events, and will
> prevent cleanup processes from cleaning out tables as they wait for
> events to get to the "pseudo node."

That wass my concern. Dropping the listens for that node (say: disable 
auto generation) would achieve that. Maybe generating listens for 
enabled nodes only (or at enable time?) would be help. Why listen for 
disabled nodes anyway?

You might remember the discussion I've been starting around beginning of 
the year where to store pgadmin's path info. Extending sl_node wasn't a 
good idea, so the pseudo node was implemented. Having its path info 
replicated with the other slony configuration stuff is quite helpful. 
What would you suggest to do now?


Regards,
Andreas