Re: Missing "New Node"

> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin(at)pse-consulting(dot)de]
> Sent: 09 June 2005 11:33
> To: Dave Page
> Cc: Christopher Kings-Lynne; pgadmin-hackers
> Subject: Re: Missing "New Node"
>
>
> Hm, let me think what I might have been thinking those days.
>
> 1) Set/Subscription
> Generally, new <object> on a <object> collection should be
> possible as
> well as <new same obj> on a <object>. If that's missing,
> something's wrong.
> In this case, things might be screwed up, because adding
> subscriptions
> are only possible on sets that are not owned by the current
> node, while
> maintaining sets is only possible on the owning node.
> Currently, own and
> foreign sets/replications (viewed from the current node) aren't
> distinguishable, so we probably should add icons to differentiate.

Sounds reasonable - something definitely ain't right though. For
example, using the databases created by Slony's test_1_pgbench test, if
I browse the slony_test1 database (the origin), and go to
Replication/T1/Replication Sets/Set 1 - pgbench tables, I can
right-click and select New Object->Add [Table|Sequence]. However, if I
right-click the child sequences or Tables collection nodes, I only get
the Refresh option. Istm that I should get Add Sequence/Add Table on
those.

The same applies to the Subscriptions node on the slony_test2 database -
there is no Add Subscription option. There is one on the Set node (as
there is for Tables/Sequences on the origin), however this throws an
exception when selected.

> 2) Nodes
> IIRC In the beginning I explicitely didn't allow "New Node" because a
> new replication node is created implicitely when a db is joined to a
> cluster.
>
> But:
> With pgAdmin, there's a new "administrative node", which
> holds paths to
> the replication nodes being maintained. There should be code
> in "create
> cluster" and "Join Cluster" to create the administrative node as well.

I'd kindof assumed that the 'administrative' node was the origin node.

> pgAdmin needs access to all replication node servers, and
> thus needs to
> store the connection info somewhere as well. This is done
> regarding the
> pgAdmin machine (and all machines with similar connectivity) as
> "administrative node", and the conn info is stored in the sl_path the
> usual way. The sl_node itself won't tell the difference,
> there's just no
> slon process running on it but a pgadmin (or phppgadmin :-).

So how does this work with slonik created clusters (such as I have)? Is
this why I seem to be unable to join existing clusters (the server and
other combos are all blank, even with other nodes running on the local
machine).

I'm still new to slony so may be missing something here of course!

Regards, Dave.