[Slony1-general] The 1.1 "listen path problem"

[Christopher Browne]

Alan Hodgson wrote: On January 24, 2006 01:50 pm, Chris Browne <[EMAIL PROTECTED]> 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 grows and grows and is never purged. This was reported as Slony-I bug 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 entries using STORE LISTEN(7) or storeListen(), based on the (apparently not as obsolete as we thought) principles described in Section 8.

_______________________________________________
Slony1-general mailing list
Slony1-general@gborg.postgresql.org
http://gborg.postgresql.org/mailman/listinfo/slony1-general