>
> 'k, thanks to Darcy's help, I think I've got it all worked out ... and
> I've finally clued into why everyone refers to it as a subscriber, instead
> of slave ...
>
> But, next step I'm not sure about, not so much from the initial setup side
> of things, since that is fairly straightforward, but on a reboot ...
>
> According to how I'm reading the README file, both the subscriber and
> master servers need to be running before I can issue the subscribe set
> command ... at least, assuming I'm reading it right ...

Arguably not.  I'd rather have both slons running so they're easy to
monitor, but Slony-I does queue events.

> Basically, according to the README, I need to start 'slon' up on the
> master, and 'slon' up on the subscriber, and then on the master I need to
> run run the 'subscribe set' command, which, based on the example, makes a
> connection to both master/subscriber and then "links" them, it seems ...
>
> But, what if the subscriber is rebooted?  Do I have to monitor this from
> the master side and re-issue the subscribe set command to get them going
> again?  *Or* is the subscribe set only run *once* when  you first bring on
> the subscriber, so that if the subscriber is rebooted, the only thing that
> is needed is to run the 'slon' command on the subscriber for it to pick
> up/replicate from master again?

Establishing the subscription is an "event;" once it becomes effective, it
continues until it gets turned off, via such things as:
 - unsubscribe set
 - drop node
 - failover

If either box reboots, replication will pick up so long as you've got two
postmasters and (more or less) two slons.  (There's an exception; you can
"fake" the origin node's SYNC events using a stored procedure, which means
that you can live without that slon for at least a little while...)

Restart the postmasters and the slons and it'll "pick up" again where it
left off.

I did some testing with this at IBM's HACMP "Performance Center" in Texas
last month; we kept rebooting servers (failing over to backup hosts), and
as soon as the servers came back up, replication continued.  And 1.0.5
plays much better with this sort of scenario than earlier versions, as it
restarts much more gracefully after graceless slon/postmaster
terminations...