>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.

I was thinking of that. That may be the simplest and safest way out of this.

>
>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?

This isn't a production system; it's still in development, and nodes 2 and 3 
will be rebuilt on different machines later anyway. It was set up by someone 
else (I'm not clear why he chose to use beta versions in the first place). So 
dropping the node and rebuilding is another reasonable solution. But I'm not 
entirely sure how to do this; doesn't slon need to be running in order to 
unsubscribe node 2? Or could I just execute the command on node 1, and DROP 
the entire database for node 2?

David Pitkin