Обсуждение: pg_ctl / SCM interaction
[discussion moved to mailing list] [context is some preliminary work I did on a C version of pg_ctl, which I need help in finishing due to time constraints] Magnus Hagander wrote: >>>We were planning to map the PAUSE operation on the service to this. >>> >>> >>> >>OK - probably the best we could get although not very untuitive. >> >> > >I find it very intuitive. But only becuase a lot of other products do >just this. Not intuitive-by-design, but intuitive-by-previous-examples. > > Will people have to do a Resume after a Pause? If not, what state will the SCM think the service is in? >You should be able to use both pg_ctl and the SCM, I think. The service >wrapper will basically do what pg_ctl does anyway - send our native >signals to the actual backend. > > Ok, help me out a bit here. We start postmaster using the SCM. As I understand it, that gives us 2 processes, one (process X) that interacts with the SCM and one that it creates (process Y) which is the "real" postmaster, and the one that writes its id in postmaster.pid. Now we use pg_ctl restart. It sends, say, TERM to process Y. I presume process X notices that Process Y has gone away, and registers that the service is stopped. Then pg_ctl starts another postmaster. How does process X know that the new postmaster is its replacement process for process X? >The security on the signals implementation is such that you need to >either be the user that started the postmaster or a local administrator >on the machine to send any signals to it. The SCM requires local admin. >So I don't think we'll be opening things up in a bad way. > > > I wasn't aware we had that security. That is good to know. >>Which stop mode (fast/smart/immediate) will the SCM code use? >> >> > >Haven't been discussed, I think. I'd go for fast. Possible immediate, >but I don't think that's necessary. Definitly not smart. since that can >block the entire service stop more or less indefinitly. >Or we could make it do a combo. Signal "smart", wait a couple of >seconds, see if everybody went away happily, then signal "fast" if thety >didn't. > > > > Makes sense. cheers andrew
> >>>We were planning to map the PAUSE operation on the service to this. > >>> > >>> > >>> > >>OK - probably the best we could get although not very untuitive. > >> > >> > > > >I find it very intuitive. But only becuase a lot of other > products do > >just this. Not intuitive-by-design, but > intuitive-by-previous-examples. > > > > > > Will people have to do a Resume after a Pause? If not, what > state will the SCM think the service is in? No. The SCM will think the service as running. > >You should be able to use both pg_ctl and the SCM, I think. > The service > >wrapper will basically do what pg_ctl does anyway - send our native > >signals to the actual backend. > > > > > > > Ok, help me out a bit here. We start postmaster using the SCM. As I > understand it, that gives us 2 processes, one (process X) > that interacts > with the SCM and one that it creates (process Y) which is the "real" > postmaster, and the one that writes its id in postmaster.pid. That is how it is done with the current code Claudio has. The other options is to have a pgservice.exe do the first step (launching the postmaster). The final option is to have this on a separate thread in the postmaster instead of in a separate process. > Now we use pg_ctl restart. It sends, say, TERM to process Y. > I presume > process X notices that Process Y has gone away, and registers > that the > service is stopped. Then pg_ctl starts another postmaster. How does > process X know that the new postmaster is its replacement process for > process X? It doesn't. You can't do a restart that way. pg_ctl would either have to send some kind of signal to the wrapper process, or use the SCM to restart it. I didn't think of restart when I said what I did - I was thinking reload. *that* can be handled the same way. > >The security on the signals implementation is such that you need to > >either be the user that started the postmaster or a local > administrator > >on the machine to send any signals to it. The SCM requires > local admin. > >So I don't think we'll be opening things up in a bad way. > > I wasn't aware we had that security. That is good to know. It's default for named pipes :-) //Magnus
> -----Original Message----- > From: Andrew Dunstan [mailto:andrew@dunslane.net] > Sent: 24 May 2004 15:30 > To: pgsql-hackers-win32 > Subject: [pgsql-hackers-win32] pg_ctl / SCM interaction > > Ok, help me out a bit here. We start postmaster using the SCM. As I > understand it, that gives us 2 processes, one (process X) > that interacts > with the SCM and one that it creates (process Y) which is the "real" > postmaster, and the one that writes its id in postmaster.pid. > > Now we use pg_ctl restart. It sends, say, TERM to process Y. > I presume > process X notices that Process Y has gone away, and registers > that the > service is stopped. Then pg_ctl starts another postmaster. How does > process X know that the new postmaster is its replacement process for > process X? It doesn't. I was chatting to Magnus earlier suggesting an integrated solution rather than a wrapper. The more I think about it the more I think this is the only way to be certain that the service code is singing from the same hymnsheet as the postmaster. /D
Magnus Hagander wrote:
>>Now we use pg_ctl restart. It sends, say, TERM to process Y.
>>I presume
>>process X notices that Process Y has gone away, and registers
>>that the
>>service is stopped. Then pg_ctl starts another postmaster. How does
>>process X know that the new postmaster is its replacement process for
>>process X?
>>
>>
>
>It doesn't. You can't do a restart that way. pg_ctl would either have to
>send some kind of signal to the wrapper process, or use the SCM to
>restart it.
>
>I didn't think of restart when I said what I did - I was thinking
>reload. *that* can be handled the same way.
>
>
>
>
Aha. Source of confusion found :-) . OK, then we have some work to do.
How about if the SCM interaction code writes out a file in the data dir
when the service is started ("pgservice.pid"?) and removes it when the
service is stopped? If this is found then pg_ctl will do a start/restart
by calling "net start".
cheers
andrew.