Andrew Sullivan wrote:
> On Tue, Feb 19, 2008 at 04:30:48PM -0800, Craig James wrote:
>> table ..." on one of the replicated tables.  Since TRUNCATE can't be 
>> handled by Slony, this lead to a duplicate-key violation in the slave 
>> database, 
> 
> Ugh.  Note that you could do TRUNCATE via EXECUTE SCRIPT, I think.  Also, I
> posted here an evil hack some time ago that allowed bulk loading across a
> Slony node.  ISTR it had some bugs, but it might work as a starting point
> for this sort of thing.
> 
>> Is there any way at all to block, trap, or otherwise prevent TRUNCATE of 
>> certain tables?  
> 
> No, no more than there's some way to prevent some clever person from
> performing ALTER TABLE.  I regard this as one of the most severe limitations
> in Slony: it will break if you do certain things, but it can't prevent you
> from doing them.

I don't mind that Slony can't handle truncate -- the documentation is quite clear -- but the real problem is that the daemon just kept trying to repeat an operation that could never succeed.  To all apearances, Slony was just fine.  It was only when I notice that a backup web site was producing different answers than the primary web site that I realized there was a problem.

In a situation like this, some sort of ACTIVE response from Slony would be nice.  Here's an idea.  When the Slony daemon detects an unrecoverable error, it should STOP, and send an email to a configurable administration email address.  Something like this:

  UNRECOVERABLE ERROR: duplicate key violates unique constraint "your_constraint_name".
  Slony is shutting down.  You must correct this error before you restart Slony.

Some errors, like network problems, are recoverable and Slony should keep going.  But others, like a foreign-key constraint violation, won't get better no matter how many times the daemon retries the operation.

Craig