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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2530 bytes
Desc: not available
Url : http://gborg.postgresql.org/pipermail/slony1-general/attachments/20061017/c9f1a195/attachment-0001.bin