>> LOCK SET (ID = 1, ORIGIN = 1);
>> WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 2); MOVE SET (ID = 1, OLD 
>> ORIGIN = 1, NEW ORIGIN = 2); WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 
>> 2);
>>
>> I assume I'm missing something in my syntax somewhere.
>
>I'm accustomed to watching logs, and not using WAIT FOR EVENT :-).

Well, I based my syntax on the example on YOUR website! ;-) (which has
been a great help to me in my slony efforts, btw, so thank you!)

I guess I wasn't understanding the whole forwarding concept - I had
associated it only with Publisher->Subscriber->Secondary-Subscriber kind
of scenario.

When you say "watching logs", do you mean the sl_log_1 table, or slon
logs?

>If it's hanging, then some event is failing to propagate, and 
>reviewing sl_event may give some ideas.

I've come to the conclusion that it was actually the LOCK SET that was
hanging, due to some open transaction somewhere. I had not realized that
LOCK SET actually went and put a trigger on every table in the set -
shame on me for not reading the source code. For the use-case I need to
support, it looks like a FAILOVER is really the only option, after all,
because we can't make any assumptions about how busy the system might
be, and having the switch/failover take an indeterminate time isn't
going to be acceptable.

>I would point out that 1.0.5 has quite a lot of bug fixes over 
>1.0.2; I'd suggest that you considering that upgrade, so as to 
>be only 6 months out of date rather than 9 :-).

Moving to 1.0.5 is one of the fondest hopes in my life at the moment,
actually, but it appears to take an international treaty to get anything
new into our build system....

Thanks for your help.

- DAP