Re: Missing "New Node"
От | Andreas Pflug |
---|---|
Тема | Re: Missing "New Node" |
Дата | |
Msg-id | 42A81AE0.8060702@pse-consulting.de обсуждение исходный текст |
Список | pgadmin-hackers |
Dave Page wrote: > > > >>-----Original Message----- >>From: Christopher Kings-Lynne [mailto:chriskl@familyhealth.com.au] >>Sent: 08 June 2005 14:38 >>To: Dave Page >>Subject: Re: Missing "New Node" >> >>Actually, ignore previous email - I just found it :) >> >>Again, it's odd. You have to right and go New Object -> >>Subscription, >>instead of right clicking on 'subscriptions'. Also, under >>New OBject is >> New Replication Set, which seems odd, since that's already on the >>Replication Sets folder. > > > Hi Andreas, > > Can you explain why you cannot add tables/sequences/subscriptions from > their respective collection nodes, but instead have to right-click the > set node? I understand why you cannot add tables/sequences to non-origin > nodes but can't quite get my head round the rest of that code. Or is > this a bug/oversight? 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. 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. 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 :-). I'd certainly like to mark nodes as replication/administration/both nodes. Regards, Andreas
В списке pgadmin-hackers по дате отправления: