> People,
>
> It is probably not totally uncommon to have multiple slon backends
> running on the same machine, replicating different databases. For unix,
> this is simple - you just start a separate slon daemon. For win32 it's
> not as simple. I see three options for dealing with this on win32:
>
> 1) Do it the unix way, and require the user to install a separate
> service for each database. This means we cannot use the installer to put
> in the service. It will also require local admin rights in order to
> admin slony, as well as making it harder to deal with complete
> configuration from pgadmin.
> The advantage with this option is that this will have the least effect
> on the codebase, and zero effect on the Unix code.
>
> 2) Implement the capability for Slon to deal with multiple replication
> engines at the same time.
> The advantage with this option is that Unix people get to start a single
> slon daemon as well. The disadvantage is that this is probably the most
> complicated option, and will have a lot of impact on the current system.

That strikes me as a mistake.  It would add considerable complexity to
slon, and introduce new failure modes.

> 3) Implement a "master slon service" that will start and control one or
> more normal "slon" processes. It would read a separate config and just
> launch several normal slons, keeping a lookout on them if they die, and
> handle restarts etc. This could be done either only for win32, or for
> both win32 and unix.
> The advantage with this option is that single-instance slon is not
> affected *at all*, and the code impact is minimal, while still helping
> situations like the win32 one.

Makes sense to me.  If I understand correctly, Win32 services are special
sorts of applications, which means that it wouldn't make sense to run this
on Unix.

> Doing option 3 specific for win32 will certianly make that part of the
> code simpler, as it can make use of more win32 specific functions. I'm
> doubtful if the functionality is actually needed under Unix - the
> concept of starting multiple daemons (possibly just using a special
> init-script) is fairly common there... That is, if option 3 is the way
> to go at all.
>
>
> Oh, and we must not forget - optoin 4, which I didn't think of at all,
> and will learn about shortly.
>
>
> I as personally leaning towards option 3 for win32 only, mainly because
> I think it's what'll give us best functionality for the least amount of
> work.
>
> What do people think? Which is the best way to proceed?

"Option #3" makes a lot of sense to me...