Alan Hodgson wrote:

>On January 24, 2006 01:50 pm, Chris Browne <cbbrowne at acm.org> wrote:
>  
>
>>I haven't heard a *peep* as to issues still outstanding on 1.1.5, so
>>methinks it's time to go 'release-o-matic' on it...  Peter was the
>>last one to gripe about some things, and it has been a whole week
>>since then.
>>
>>    
>>
>
>What exactly was the nature of the listen path problem that wasn't going to 
>be fixed in this version?  Are we going to have to go back to manually 
>specifying dozens of listen entries in order to be able to use PostgreSQL 
>8.1?
>
>  
>
This is documented fairly properly now in the FAQ...

The problem only comes up if you have a configuration with 4+ nodes, and
multiple subscription sets, where those subscription sets do not share
any nodes.

The problem is that, in that case, the listen paths wind up being
somewhat deficient, so that confirmations don't pass properly between
the  disjoint subsets of nodes participating in each replication set.

Thus, you might have set #1, replicating from node 101 to node 102.

And you have set #2, replicating from node 201 to node 202.

Replication works fine with each set; it's just that confirmations don't
make it back, and so sl_log_1 never gets cleaned out :-(.

If you aren't using that sort of "disjoint set" pattern of replication,
then you shouldn't have a problem.

We're always building sets of nodes that are trees; it's not a problem,
with trees.  The problem is when you have a forest of nonintersecting
trees...

>From the FAQ:

*Q: I am running Slony-I 1.1 and have a 4+ node setup where there are
two subscription sets, 1 and 2, that do not share any nodes. I am
discovering that confirmations for set 1 never get to the nodes
subscribing to set 2, and that confirmations for set 2 never get to
nodes subscribing to set 1. As a result, sl_log_1
<http://linuxfinances.info/info/table.sl-log-1.html> grows and grows and
is never purged. This was reported as Slony-I bug 1485
<http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1485>.*

*A: * Apparently the code for |RebuildListenEntries()| does not suffice
for this case.

| RebuildListenEntries()| will be replaced in Slony-I version 1.2 with
an algorithm that covers this case.

In the interim, you'll want to manually add some sl_listen
<http://linuxfinances.info/info/table.sl-listen.html> entries using
STORE LISTEN(7) <http://linuxfinances.info/info/stmtstorelisten.html> or
|storeListen()|, based on the (apparently not as obsolete as we thought)
principles described in Section 8
<http://linuxfinances.info/info/listenpaths.html>.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gborg.postgresql.org/pipermail/slony1-general/attachments/20060124/a078415c/attachment-0001.html