We should look for foreign key relationships that cross set boundaries from various perspectives: 1. Foreign key on replicated table pointing to a non-replicated table 2. Foreign key on non-replicated table pointing to a replicated table 3. Foreign key on replicated table pointing to a table in a different replication set with the same origin 4. Foreign key on replicated table pointing to a table in a different replication set with a different origin Other scenarios are uninteresting from a Slony perspective. There are several ways that these issues might be reported, and we may wish to consider using some or multiple of the following: a) Initial health check run by slon upon startup, calling stored function slon_node_health_check() b) The tool test_slony_state.pl c) Perhaps a stand-alone tool to add to tools