Skip site navigation (1) Skip section navigation (2)

Re: win32 service code

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Claudio Natoli" <claudio(dot)natoli(at)memetrics(dot)com>,"PgSql-Win32" <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: win32 service code
Date: 2004-05-28 09:29:57
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE34BB59@algol.sollentuna.se (view raw or flat)
Thread:
Lists: pgsql-hackers-win32
> My 2c,
I'll add mine as well..

> > 1) Separate binary "pgservice.exe" that will CreateProcess() the 
> > postmaster.exe.
> > Advantages: Zero impact on postmaster code. Simple to do.
> > Disadvantages: Adds a platform-specific binary.
> 
> My preference. Personally, I think we should make this pg_ctl.

That sounds like a good idea.

> > 2) Include in postmaster doing an extra CreateProcess().
> > Advantages: No extra binary. Low impact on postmaster code.
> > Disadvantages: Two postmaster.exe:s. running (confusing? overhead?)
>  
> This is what I've currently got. I pretty much hate seeing 
> two postmaster.exe/s running.

In my opinion, this is the worst idea.

> > 3) Include in postmaster but running on a separate thread 
> (not process 
> > as
> (2))
> > Advantages: No extra binary. No extra process. Most integration.
> > Disadvantages: Probably larger impact on postmaster code.
> 
> IMHO, the worst of all options.

Since there is only very little stuff gonig on in a different thread, I
don't think this is the worst idea at all. For me, 1 and 3 are about as
good.

> I'm itching to throw this code somewhere :-)

Yay :-)

From what I can read of the people that post it, it seems option 1 is
probably the most popular one. So unless someone objects, I suggest you
move down that path :-)
(It shouldn't be that much work moving yuor stuff from postmaster,
AFAICS)


//Magnus


pgsql-hackers-win32 by date

Next:From: Cyril VELTERDate: 2004-05-28 10:18:57
Subject: Re: Re : Win32 binaries test / pg_dump problem
Previous:From: Andrew DunstanDate: 2004-05-28 03:28:09
Subject: Re: win32 service code

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group