This idea is to try and deal with the following problem. A user has a multi-node cluster and needs to bring one of the nodes down for a while (say a few day). During this time slony collects the transactions to replicate in sl_log_1 and sl_log_2.
The problem is that sl_log_1 or sl_log_2 will bloat to be very big. Generating SYNC's will take a lot longer and reading SYNC's for other nodes can take a lot longer. Slony can get into a state where it can't keep up/catch up with replication because the sl_log table is so large. Does this problem bite people often enough in the real world for us to devote effort to fixing? If instead of having 2 sl_log tables we could have a dynamic number of them. During a log switch if no sl_log table is ready to be truncated we could instead create a new one. This would complicate the logic where we select from sl_log_1 and UNION with sl_log_2. _______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
