On Oct 16, 2006, at 9:53 AM, Andrew Sullivan wrote:
anyway. Then your daemon just takes a write lock on the tables you're really concerned about preventing a write in, and releases it when Slony catches up. It's not a cheap solution, but for such a specialised case I think roll-your-own is the way to go anyway.
For normal application work, I let the slave fall behind as much as it does naturally. However when I do maintenance work involving cleaning out old data, I build knowledge of the replication delay into those scripts, so they throttle themselves when replication falls behind. This has zero impact on customers. Blocking the master because the replica is falling behind sounds like a totally idiotic idea to me. Your whole app would be useless.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
