Обсуждение: win32 service code
Hi! Last I spoke with Claudio, he was still waiting for some reactions from others than me on how we want the service code. So I figured I'd post a recap of the options we have. I've added some advantages/disadvantages, but those are my thoughts only. There are sure to be others. 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. 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?) 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. As said, I've probably missed some in adv/disadv, but I think I got all our options. Thoughts? //Magnus
Magnus wrote: > 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. This is the best way to go, I think. This way we can automatically redirect stderr to the event logger and other nice stuff like that. Also this prevents having to deal weird problem like the postmaster crashing but postserver.exe still running...yuck. Merlin
>> 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. > >This is the best way to go, I think. This way we can automatically >redirect stderr to the event logger and other nice stuff like that. How can we do this in this case when we can't do it from another process? (Note - only "boot messages" are interesting anyway. Once the ereport code is activated (and after GUC loads), we will report directly to the eventlog. >Also this prevents having to deal weird problem like the postmaster >crashing but postserver.exe still running...yuck. Yes, that is a definite advantage. //Magnus
Magnus Hagander wrote: >Hi! > >Last I spoke with Claudio, he was still waiting for some reactions from >others than me on how we want the service code. So I figured I'd post a >recap of the options we have. I've added some advantages/disadvantages, >but those are my thoughts only. There are sure to be others. > > >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. > >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?) > >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. > > >As said, I've probably missed some in adv/disadv, but I think I got all >our options. > > Could we combine 1 and 2? We already have the postmaster/postgres distinction in what is in fact the same binary. Of course, there might be an undesirable memory impact - not sure how good Windows is at shared memory. I'm a fan of low impact, but I have no strong opinion on this. cheers andrew
How would this interact with pg_ctl? I would hate to have to tell people to use a different command to start/stop the postmaster depending on what platform they use. :-( FYI, I like #2. --------------------------------------------------------------------------- Magnus Hagander wrote: > Hi! > > Last I spoke with Claudio, he was still waiting for some reactions from > others than me on how we want the service code. So I figured I'd post a > recap of the options we have. I've added some advantages/disadvantages, > but those are my thoughts only. There are sure to be others. > > > 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. > > 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?) > > 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. > > > As said, I've probably missed some in adv/disadv, but I think I got all > our options. > > Thoughts? > > > //Magnus > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
> >> 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.
> >
> >This is the best way to go, I think. This way we can automatically
> >redirect stderr to the event logger and other nice stuff like that.
>
> How can we do this in this case when we can't do it from another
> process?
> (Note - only "boot messages" are interesting anyway. Once the ereport
> code is activated (and after GUC loads), we will report directly to
the
> eventlog.
Right...that makes sense. I guess it makes little difference on this
point then. I suppose even pg_ctl could handle the boot messages
('server is up', 'server is down', etc.), so it makes no difference to
the postmaster whatsoever.
Whatever is the easiest/safest, then.
Merlin
Bruce Momjian wrote: > How would this interact with pg_ctl? I would hate to have to tell > people to use a different command to start/stop the postmaster depending > on what platform they use. :-( I had a thought that on win32 pg_ctl start/stop would mean start/stop the service (always) on win32, and for this to be the only way to start the postmaster as a service. That neatly solves this problem and we can boot the boot/kill here. It is still of course quite possible to invoke the server directly in special cases. This also fits nicely with Magnus's #2 scnario, I think. Merlin
Merlin Moncure wrote: >Bruce Momjian wrote: > > >>How would this interact with pg_ctl? I would hate to have to tell >>people to use a different command to start/stop the postmaster >> >> >depending > > >>on what platform they use. :-( >> >> > > >I had a thought that on win32 pg_ctl start/stop would mean start/stop >the service (always) on win32, and for this to be the only way to start >the postmaster as a service. That neatly solves this problem and we can >boot the boot/kill here. It is still of course quite possible to invoke >the server directly in special cases. > >This also fits nicely with Magnus's #2 scnario, I think. > > > No, we need to be able to run *not* under the service manager, and pg_ctl needs to be able to control that, IMNSHO. Users might not have admin privs (e.g. in a classroom setting). cheers andrew
Andrew wrote: > >I had a thought that on win32 pg_ctl start/stop would mean start/stop > >the service (always) on win32, and for this to be the only way to start > No, we need to be able to run *not* under the service manager, and > pg_ctl needs to be able to control that, IMNSHO. > > Users might not have admin privs (e.g. in a classroom setting). Ok, fair enough. Do you think start/stop service should still be done through pg_ctl? Merlin
Merlin Moncure wrote: > Andrew wrote: > > >I had a thought that on win32 pg_ctl start/stop would mean start/stop > > >the service (always) on win32, and for this to be the only way to > start > > > No, we need to be able to run *not* under the service manager, and > > pg_ctl needs to be able to control that, IMNSHO. > > > > Users might not have admin privs (e.g. in a classroom setting). > > Ok, fair enough. Do you think start/stop service should still be done > through pg_ctl? What are the advantages of _not_ using pg_ctl? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
>> > >I had a thought that on win32 pg_ctl start/stop would >mean start/stop >> > >the service (always) on win32, and for this to be the only way to >> start >> >> > No, we need to be able to run *not* under the service manager, and >> > pg_ctl needs to be able to control that, IMNSHO. >> > >> > Users might not have admin privs (e.g. in a classroom setting). >> >> Ok, fair enough. Do you think start/stop service should >still be done >> through pg_ctl? > >What are the advantages of _not_ using pg_ctl? That all other services are handled through the service MMC snapin. That's not a reason not to support *both*, though. //Magnus
Merlin Moncure wrote:
>Andrew wrote:
>
>
>>>I had a thought that on win32 pg_ctl start/stop would mean start/stop
>>>the service (always) on win32, and for this to be the only way to
>>>
>>>
>start
>
>
>
>>No, we need to be able to run *not* under the service manager, and
>>pg_ctl needs to be able to control that, IMNSHO.
>>
>>Users might not have admin privs (e.g. in a classroom setting).
>>
>>
>
>Ok, fair enough. Do you think start/stop service should still be done
>through pg_ctl?
>
>
>
>
I think if we are running as a service that the SCM code should create
$PGDATA/pgservice.servicename so we can at least detect it.
Then if that file is present, we have a range of options, including:
. don't allow pg_ctl to do stop/start/restart
. have pg_ctl issue "net {stop,start} servicename" to give effect to the
commands
cheers
andrew
Magnus Hagander wrote: >>What are the advantages of _not_ using pg_ctl? >> >> > >That all other services are handled through the service MMC snapin. > >That's not a reason not to support *both*, though. > > > Not to mention the fact that it is by far the easiest way to ensure that the db is brought back up on reboot. We have to provide both facilities IMNSHO - the issue is not one or the other, but making sure that they don't collide badly. cheers andrew
My 2c, > 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. > 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. > 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. I'm itching to throw this code somewhere :-) Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see <a href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em ailpolicy.html</a>
This doesn't need to be perfect, IMNSHO, just functional. Someone (who?) needs to make a call. My take: If code is there for option 2, let's get it in. ISTM the installer could make a copy of the postmaster.exe called pgservice.exe and install the latter as the service. Then you should see one pgservice and one postmaster instead of two postmasters, right? cheers andrew Claudio Natoli wrote: >My 2c, > > > >>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. > > > > >>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. > > > > >>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. > >I'm itching to throw this code somewhere :-) > >Cheers, >Claudio > >--- >Certain disclaimers and policies apply to all email sent from Memetrics. >For the full text of these disclaimers and policies see ><a >href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em >ailpolicy.html</a> > >---------------------------(end of broadcast)--------------------------- >TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > > >
> This doesn't need to be perfect, IMNSHO, just functional. > > Someone (who?) needs to make a call. Agree on both points. I'm happy making the call, but past experience has shown me that doing so without getting sort form of consensus from the big names is asking for trouble :-) > My take: If code is there for option 2, let's get it in. ISTM the > installer could make a copy of the postmaster.exe called > pgservice.exe and install the latter as the service. Then you should see > one pgservice and one postmaster instead of two postmasters, right? True enough. The only obvious disadvantage being the footprint of the exe, both for running and redistribution (already bad enough that we do this for postgres.exe). That kills it from my view. Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see <a href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em ailpolicy.html</a>
Claudio Natoli wrote: > > >>My take: If code is there for option 2, let's get it in. ISTM the >>installer could make a copy of the postmaster.exe called >>pgservice.exe and install the latter as the service. Then you should see >>one pgservice and one postmaster instead of two postmasters, right? >> >> > >True enough. The only obvious disadvantage being the footprint of the exe, >both for running and redistribution (already bad enough that we do this for >postgres.exe). That kills it from my view. > > > The memory footprint part of this is true whatever you call it. In that case I agree with your other suggestion of rolling it into pg_ctl - it should fit quite nicely, and make it easier for us to make sure that both manager aspects do the right thing w.r.t each other. The "extra thread" option looks too messy at this stage of the game. cheers andrew
> 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