On Fri, Dec 23, 2011 at 11:11 AM, Jan Wieck <JanWieck at yahoo.com> wrote:
> I would like to simplify this code and make Slony require that a node
> must use the same data provider for all the sets, that originate on
> another node. In the above scenario, either 2 or 3 would have to
> subscribe both sets and node 4 would have to get both from that node.

I see two theoretical problems, one of which may be sufficiently
aethereal to likely be ignorable:

1.  Suppose someone has a cluster today which violates the
requirement...  What shall we do?

Some quite acceptable answers would include:
- Add a test to tools/test_slony_state.pl which looks for violations
and warns "oh dear, incompatible with 2.2, and mightn't necessarily
work right today!"
- Add a pre-upgrade script that checks for violations
- Add a check to the UPDATE FUNCTIONS slonik functionality that looks
for violations, and causes the upgrade to fail if violations are
found.  This might need to be a query that is run during the load of
slony1_funcs.sql...

Perhaps we need several of these.

2.  Is it possible that we need to have a violation of this
requirement in order to do some reshaping of a cluster?

For usual SUBSCRIBE SET cases, I don't think so.

But it's possible that FAILOVER could violate this, temporarily.  I
don't think so, but it's worth validating.