Jan Wieck wrote:
> On 12/21/2005 8:18 PM, Florian G. Pflug wrote:
> 
>> Florian G. Pflug wrote:
>> <snipped my own mail>
>>
>> Can anyone confirm that this is actually a bug? I pretty sure
>> (Did multiple setups of my cluster, and the problem persisted -
>> I used the altperl scripts for setting up the cluster, so I
>> see no way I could have causes this).
>>
>> If it's really I bug, I would at least be worth a note in
>> the docs or in the 1.1.5 release notes - I took me hours to
>> nail down the problem, and it wasn't fun, so preventing
>> others from having to do the same would be a good thing.
> 
> Rebuild listen entries is indeed broken. This is a show stopper for 
> 1.1.5 ... I am working at it.

Is there a reason for not generating all "sensible" sl_listen entries?
I didn't find any documentation on the performance overhead a
sl_listen entry causes.

With "sensible" I mean: Telling node X via sl_listen to ask neighbour-nodes
(Those for which a sl_path entry exists) for events from all other nodes,
apart from those for which the events must have travelled via node X to
reach the neighbour of X in question.

I tried writing an algorithm to do that, but it turned out that isn't quite
as easy as I initially believed, because all "iterative" algorithms
I could think off (Which were all based basically on the idea, that
if X receives events from Y, and Y from Z, then X can receive events from Z
via Y) failed because there is not enough information in sl_listen to figure
out if Y already needs X receive events from Z).

greetings, Florian Pflug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4116 bytes
Desc: S/MIME Cryptographic Signature
Url : http://gborg.postgresql.org/pipermail/slony1-general/attachments/20051223/78941eeb/smime-0001.bin