On 9/30/2005 10:53 PM, cbbrowne at ca.afilias.info wrote:
>> Christopher Browne wrote:
>>> This might be called the "too many 1's" release :-)
>>
>> Neither the bug fix for the wrong default value of con_timestamp is in
>> cvs, nor ignoring disabled nodes (which isn't discussed completely so
>> far).
> 
> The *actual* bug relating to the timestamp was, in fact, addressed; it
> wasn't where you reported it to be.
> 
> See CVS logs for src/slon/remote_worker.c, with particular reference to
> revision 1.89.  That is the bug fix.
> 
> As for the "disabled nodes" part, I never saw any response to the
> questions I asked concerning why pgadmin was creating these nodes rather
> than creating additional tables to store administrative information.
> 
> Creating invalid nodes strikes me as the wrong way to do things.

Chris and I talked about it and I didn't like the idea at all. The thing 
is, all those "virtual" nodes would represent are admin stations, no? 
And all those are good for is to store their admin conninfo as sl_path 
entries. Considering the amount of extra care to be take (so that this 
dead info doesn't affect any failover/switchover ... don't we already 
have problems enough there) compared to storing that data in a separate 
table that is automatically propagated ... I suggest separate table.


Jan



> 
> You're evidently looking for some nodes to be treated specially as far as
> sl_listen is concerned; it is by no means obvious that this is anywhere
> near the only place where your intended usage of nodes would require
> modifying functionality.  I would expect implications for sl_event and
> sl_confirm, as well as a need to substantially revise the cleanup thread.
> 
> With that load of uncertainty that has neither been discussed nor thought
> through, there is NO WAY that I'm modifying functionality in the way
> proposed at this point in time.
> 
> It will absolutely NOT happen in the "stable" branch; that would be both
> reckless and risky, which represent the two LAST things that users of
> enterprise replication software want thrust upon them.
> 
>> Is 1.1.1 fixed? If not, we won't be able to support 1.1 with pgadmin.
> 
> Do you mean "Is that the only release of 1.1.1 that there's going to be?"
> 
> If so, the answer is "You bet."
> 
> If some well-documented bug (and what you have outlined is NOT that)
> emerges, that might lead to 1.1.2.  (Though I'd fight to try to get
> 1.1.1.1 :-) if I could!)
> 
> As you mentioned, your notion of ignoring disabled nodes has not yet been
> "discussed completely."  Nothing ought to be implemented on that front
> until the matter has been discussed in considerably more detail.  It
> doesn't make sense to try to implement it until there's a much clearer
> idea of what "it" actually is.
> 
> I don't know that the idea is yet clear enough to make it plausible that
> attendant changes would go into version 1.2, let alone 1.1.
> 
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #