> I'd love to fix the root of the problem, but so far the cause is unclear.
> I'm
> about ready to blame postgreSQL; this isn't entirely farfetched, because
> node
> 2 is running 8beta3, whereas node 3 is 8beta2 and node 1 is 7.4.6. But if
> it
> IS postgreSQL, then the only solution is to convince the master node to
> stop
> sending the DDL SCRIPT event. Is there a way to do that?

I think I once "fudged" this by changing the contents of the event to
contain some form of NOOP.  Take a look in sl_event on each of the nodes
to see what has propagated where; you _probably_ want to change it on the
master.

But note that this is a pretty dangerous thing to do.  I wouldn't warrant
that this would do damage to data on the slaves; it just seems likely that
it's one of the "less dangerous" options.  If one of your machines catches
fire, causing hospital control systems to run amok, remember that I said
"this is pretty dangerous."  I hope that some of those databases can be
considered "scratch monkeys..."

When you mention that you're running multiple _differing_ beta versions of
PG 8, this suggests to me that you should simply drop the offending nodes
and restart replication.  After all, who would put _important_ data in
beta versions of PostgreSQL which can't guarantee any kind of
upgradability?

If that appears sarcastic, well, you're definitely riding on the bleeding
edge, and if you don't _think_ you're accepting risks as a result, you'd
better be aware that you are.  So bleeding edge that there's little
likelihood that you can have any upgrade path for two of those instances. 
If pg_dump proved to have any interesting bugs, you'd have a tough time
finding help.

I have some PG 8 instances around, but as proof that Slony-I will do
appropriate things there, not as "production" systems.