Andreas Pflug wrote:

> I'm currently finishing slony support in pgadmin (code as of last week
> was 1.05 only), and need to catch version dependencies now. Could
> please somebody sum up which feature appeared in which version.
> Extracting this from the docs would be really time consuming/error
> prone; at present I got only 1.2 to test.
>
> 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

> ddlscript (1.1 or 1.2?)

That was available in 1.0.5, if not earlier.

> Finally: I found that droplisten is disabled (will always return -1),
> and even if I drop the sl_listen row it will be recreated.
> Auto-creating listens from paths is a fine thing for standard
> situations, but I wonder if this is a good thing in complicated
> replication topologies. In addition, pgAdmin will use a (never active)
> node as "administrative node" to store its path information to all
> nodes, and will never need listens. Hopefully, a node that never pulls
> the events from its providers won't happen to degrade the cluster
> somehow.

Generating sl_listen automatically was/is a good idea.

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

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."