Thanks to flaky net and dying slony's while doing MOVE SET from 2 to 5,
and then hastily MOVE SET back to 2 I ended up with the setup below.

I.e. all nodes think that some other node is master, and even refuse to
drop the node, or to drop the only table from that set, not to mention
doing more sensible things.

I forcibly removed slonys _deny_ trigger from old master so that I could
keep providing service, but would like:

1) quick (and possibly dirty ;) advice, how to resolve this situation
withou uninstalling slony from any of the nodes

2) ideas about how to forbid slony from doing things like this in the
future, or some tools build in/bundled with slony for some saniy-check's
and fixing replication-structure.

I know that we can't make it 100% fool-proof without 2PC, but I'm quite
sure more robustness can be added to setup process.


this is what I ended up with.

NODE 1    5-->2-->1

orderdb=# select * from _balance_cluster.sl_subscribe where sub_set = 2;
 sub_set | sub_provider | sub_receiver | sub_forward | sub_active
---------+--------------+--------------+-------------+------------
       2 |            2 |            1 | f           | t
       2 |            5 |            2 | t           | t
(2 rows)


NODE 2    5-->1-->2

accountdb=# select * from _balance_cluster.sl_subscribe where sub_set =
2;
 sub_set | sub_provider | sub_receiver | sub_forward | sub_active
---------+--------------+--------------+-------------+------------
       2 |            5 |            1 | f           | t
       2 |            1 |            2 | t           | t
(2 rows)


NODE 5  2-->1-->5

accountdb=# select * from _balance_cluster.sl_subscribe where sub_set =
2;
 sub_set | sub_provider | sub_receiver | sub_forward | sub_active
---------+--------------+--------------+-------------+------------
       2 |            2 |            1 | f           | t
       2 |            1 |            5 | t           | t
(2 rows)

-- 
Hannu Krosing <hannu at tm.ee>