> Hi all,
>
> I'm not sure what the "forward" flag really does in the SUBSCRIBE SET
> slonik function.  Theoretically, you could always set "forward=yes"
> and then never subscribe anything to it--then there would be no
> reason to ever set it to "forward=no"
>
> Any insights?

It controls whether or not the subscriber records changes in its own
sl_log_1/sl_log_2 tables...

If forward=N, then you can't use that node as a source for another node.

In order to have the feeding...

A --> B --> C --> D

B needs to subscribe to A, with forwarding on;
C needs to subscribe to be, again, with forwarding on;
that allows D to subscribe to C; in that case, forwarding is optional.

If B had forwarding turned off, you couldn't set up a subscription from B
to C...

Does that help answer the question?

There's another detail, too, that comes up if you do a failover.  This may
seems obscure...

Suppose you have nodes A, B, C.

A begins as the origin.

B subscribes to A; forwarding turned on.

C subscribes to A; forwarding turned OFF.

Suppose A falls over.  The only failover option is to go to node B; you
can only failover to a forwarding node.

There is a risk to having forwarding turned off on C; suppose B was only
up to date to event # 8901, whereas C was a bit ahead of that; it was up
to event 8904.  (Apparently node B wasn't replicating for a few seconds,
or something...)

Alas, you cannot keep node C.  There is no way to bring B up to event
#8904, as no remaining node has the data for SYNCs 8902, 8903, and 8904.

Resulting "rule of thumb":  Never have a node that is directly connected
to the origin have forwarding turned off...

If you have a single node at a remote site, and you know you'd never
consider failing over there, that node would be good to have forwarding
turned off on, as it saves a bunch of work populating sl_log_1.

> Also, if I'm setting up a master->relay->offsite_backup architecture,
> would I subscribe them all to the same set, having the relay node
> forward to the offsite_backup node?  That's the way I got it to work,
> but I'm not sure if there's another way, like, say, building a second
> set on the relay machine, and have the offsite_backup subscribe to
> that set (I'm under the impression that such a setup isn't possible).

I'm not sure quite what you mean by the "another way"; what you've done
seems appropriate as how to handle cascaded subscribers...