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

That's exactly what I thought - complexity makes for failures..



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

Yes, they are somehwat special. With regards to slon in the way I was
thinking, you could think of them as a separate "init" process - read a
config file, make sure other programs (the actual slon.exe processes)
are running, and restart them if they fail.



> > What do people think? Which is the best way to proceed?
> 
> "Option #3" makes a lot of sense to me...


//Magnus