On Mon, Dec 11, 2006 at 10:51:11AM -0500, Christopher Browne wrote:
> The vital bit is that if you don't use EXECUTE SCRIPT, the old
> logtrigger will not get replaced by a new one that properly reflects
> the new set of columns in the table.  Without that change, the new
> column won't get replicated.  
> 
> That may appear to work out fine, for a while, if the new column takes
> on a default value which is (or appears) valid.

That's part of it.  In early versions, there was the additional bit
of pain that the memory bound on the shipped row was not checked by
the log trigger.  The upshot of this was that you could randomly
write garbage into your replication log.

IIRC, Jan fixed this sometime before 1.1.x.  The new behaviour,
however, means that inserts into your recently-altered table MAY fail
under some circumstances.  This means that work on the origin might
fail (and not failing there was actually the reason for the decision
to have allowed the overflow in the first place: our original design
rule was that the replication system was never allowed to cause
failures in a working application.  We later decided that was a bad
criterion, hence the change).

But as I pointed out before, you can get around the EXECUTE SCRIPT
stuff by doing the steps by hand.  Of course, in that case, you're
actually taking the locks EXECUTE SCRIPT would anyway.

A

-- 
Andrew Sullivan  | ajs at crankycanuck.ca
"The year's penultimate month" is not in truth a good way of saying
November.
		--H.W. Fowler