Hi all, I have a postgres DB where beside a load of common tables, each new customer gets one special table of it's own. Customers are created quite frequently by our admins.
The DB is replicated to a slave via slony. The problem is that once the slony replica is set up, the new tables have to be added to the replication each time we create a new customer on the system. This poses a problem, as the DB is quite heavily loaded usually, and the locks involved are problematic. Now all of these per customer tables are not actually very often accessed, so if I could take them out to a separate replication set I guess it would not be anymore so problematic to include adding the per customer table to replication in the automated customer creation script. All these per customer tables have a foreign key to a central 'common denominator' table, which is the source of the biggest contention on the system. Locking this table for 2 minutes brings our system to a halt (due to all connections of our connection pool ending up waiting on the lock)... so I was thinking putting the central table (together with all the other common tables) into a separate replication set, and the per customer tables on a second replication set. The question is, will it work properly, having foreign keys from one set's tables to the other set's tables ? TIA, Csaba. _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
