> When I do a MOVE SET, I am seeing the "forward" attribute getting set to
> TRUE on the subscription. I have two nodes, an active and a standby,
> running slony 1.0.2. Is this correct behavior?

Well, the new origin obviously has to have 'forward' set so that it
collects sl_log_1 entries and such.

The former origin had to have "forward" set for it to be a provider in the
first place.

I'd expect, therefore, that both nodes involved would have forward set at
the end of things.

> In some situations when I try to then do a MOVE SET back (i.e., a
> "fail-back"), I am seeing the MOVE SET hang. I'm wondering if this is
> related to the forward being set to TRUE or not. Here is my move set
> command (this particular command did not hang - the format is always the
> same because it's generated):
>
> CLUSTER NAME = tzreplic;
>
> NODE 1 ADMIN CONNINFO = 'host=192.168.111.62 port=24005 dbname=policy
> user=tazz:dbmgr password=tazz:dbmgr';
> NODE 2 ADMIN CONNINFO = 'host=192.168.111.65 port=24005 dbname=policy
> user=tazz:dbmgr password=tazz:dbmgr';
>
> 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 :-).

I wouldn't expect forwarding to be at issue.

The thing to watch for is what's in the logs.  They may suggest something.

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

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