salman <salmanb at quietcaresystems.com> writes:
>>>> 1) Since node IDs x,y are already in use by the primary master (x) and
>>>> slave (y), the new 8.3.1 node will receive an ID of 'z' (1,2,3 in
>>>> numbers). Is it possible to rename the new node (z) to x?  I was unable
>>>> to find any docs about this.
>>>
>>> I don't know the answer to this one.
>> The answer is unfortunately, still no.  So, your upgraded server
>> will become node 3 and if that's going to be the new master and you
>> want it to be node 1, the only way to do this is tear down
>> replication and reinstall the cluster with different node IDs.
>>
>
> Ugh. So any existing scripts and/or cron jobs would have to be
> modified and tested, again, to make sure they work. I was hoping such
> a base feature would be in there and I just missed it while going
> through the docs page, but I guess not.

I have to object somewhat; the idea of being able to change the
identity of a node in this fashion is NOT any sort of "base feature"
or "basic feature."

The node ID is deeply used throughout the functionality of Slony-I,
and the notion of changing it would require some rather deep changes
that are very much NOT "basic."

The essential problem is that node identity is not merely stored in
one spot (e.g. - the sequence sl_local_node_id); it is stored widely,
with varying levels of indirection, in *most* of the tables in the
Slony-I internal schema.

To change a node identity would require updating widely the contents
of virtually all the tables in the cluster, thus requiring locking
practically the entire state of each node.  But that's the first,
naive view of it.

Going on to the fact that Slony-I is a distributed system takes us a
step further; in order to consistently perform this update would not
only require that we lock down *a* node to substantially rewrite its
configuration; it would require rewriting the configuration of the
WHOLE cluster in a consistent fashion.  We really don't have a way to
do this.

There does now exist a way of renumbering a node, in the form of the
CLONE PREPARE/CLONE FINISH functionality that is coming in v2.0.  But
even in that case, we depend on setting up the new node by copying
data from the state of the new node under its former identity to
establish its new identity.  There is actually not much need to revise
the new node's configuration (see cloneNodeFinish(int4, int4) for
details on how little the change is).

I don't want to go into any sort of "big rant" to parallel the recent
comments on the list, but I do need to point out that the notion of
renumbering nodes _is not basic functionality_.  It represents
something that would be really rather difficult to accomplish.
-- 
(reverse (concatenate 'string "ofni.sesabatadxunil" "@" "enworbbc"))
http://cbbrowne.com/info/sgml.html
The purpose of an undergraduate education at MIT is to give you a case
of post-traumatic stress syndrome that won't wear off for forty years.