Christopher Browne wrote:
>>Here is an attempt at integrating my algorithm into slony1.
>>I tried it on one of the nodes of my slony cluster, and
>>it seems to generate correct listen entries, but haven't
>>tested anything else yet.
>>
>>The thing I'm most unsure about is if the logic regarding
>>set-subscriptions is correct. At the moment, I ignore
>>a possible sl_listen entry if there is a subscription
>>with set-origin = li_origin, set-subscriber = li_receiver
>>and set-provider != li_provider. Are there any other
>>special cases to watch out for?
>>
>>The attached file contains two functions - A replacement
>>fro RebuildListenEntries, and a helper calles
>>ReachableFromNode.
> I have been trying the functions out; the results are looking pretty
> good thus far.
Good to hear

> One issue:  The array handling isn't compatible with PG 7.3.
Is it just some syntax, or were there no arrays at all in 7.3?
If it's just some syntax that doesn't work, I'm sure I can
work around that. If arrays are missing completly, well, that
makes a workaround much harder...

> If we adopt this, it means officially declaring that 7.3 is no longer
> supported.
> 
> I don't consider that a forcibly disastrous change; we have been
> debating for quite a while when 7.3 would stop being supported.
There could also be a slony_funcs.v73.sql with the old algorithm
included, and a big, fat note that slony on 7.3 is only intended to
be used for upgrading to a more recent version. For the typical
upgrade, the cluster would only consist of two nodes, so the old
algorithm would work...

> I think I need to write up a function to evaluate sl_listen in order to
> have a proper test...
If you just want to check that every node is reachable, that would be quite
easy - e.g. with
"select sum(1) from @NAMESPACE at .sl_listen group by sl_receiver, sl_origin".
If this doesn't return N*(N-1), with N being the number of nodes, then something
is fishy. Of course, this will only work if the algorihtm is take to be correct,
so it's not really a test of the algorithm...

A real test would probably mean implementing another algorithm that should lead
to the same result, and then comparing those... Which sounds like a lot of work :-(

Anyway, I trust the algorithm itself much more than I trust my subscribed-set-special-case.
This part is what really needs to be checked, IMHO.

greetings, Florian Pflug