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
_______________________________________________
Slony1-general mailing list
[email protected]
http://lists.slony.info/mailman/listinfo/slony1-general
