On 12/23/2011 11:44 AM, Christopher Browne wrote:
> 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!"

Such a check/warning would have to be added to minor releases of 2.0 and 
2.1. In the past we (at Afilias) used the same outage that would be 
needed to upgrade from 2.0.7 to 2.0.8, to actually upgrade to the next 
major release if that is possible. I would expect other users to have 
different upgrade patterns, so such a warning may never make it to the user.

> - Add a pre-upgrade script that checks for violations

That is certainly a useful thing in general.

> - 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...

As a last stopgap, we will definitely have that.

>
> 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.

There may today be slonik scripts out there that try to change the data 
provider of a node with multiple sets, that temporarily violate this 
requirement. They need to be fixed by placing the multiple SUBSCRIBE SET 
commands into a try block.


Jan

-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin