John Moran <johnfrederickmoran at gmail.com> writes:
>
>     Ah! That is not what you originally stated. Your original query was
>     understood to mean to not have _any_ paths. Yes, if you define the path(s)
>     from master to slave(s), then it will work. Although I personally don;t see
>     the benefit, unless you are talking about _many_ slaves.
>
>
> The benefit is that I don't have to maintain paths, nor do I pay any overhead
> for a feature I am absolutely certain I will never use.

There will still be chatter, because, in order for replication logs
(e.g. - tables sl_log_1 and sl_log_2, sl_event, sl_confirm) to get
trimmed, Slony-I requires that events propagate in to/from all nodes.

If you haven't got paths between the subscribers, that's OK - the
chatter (and therefore, overhead) will get communicated via the paths to
the master.

- The chatter will still take place, so confirmations will get through,
  and trimmable tables will get trimmed.

  +1

- The chatter will still take place, so the chatter you imagined you
  were saving yourself from will still take place.

  -1

In other words, while what you're doing is feasible and supportable, it
doesn't save you what you think it's saving.

But the same total number of SYNC and confirmation events still have to
get from each node to every other node, so you're not really eliminating
the chatter.

It's possible that by aggregating the event propagation into the pair of
sets of channels (e.g. - from origin to subscribers, and from
subscribers to origin), there may be *some* savings.  I imagine that:
  a) There should be somewhat fewer DB connections, and
  b) It's possible that event propagation takes place more "in bulk."
     (Though this could be a mirage that I'm imagining.)
-- 
output = ("cbbrowne" "@" "ca.afilias.info")
Christopher Browne
"Bother,"  said Pooh,  "Eeyore, ready  two photon  torpedoes  and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"