Re: pg_ctl / SCM interaction

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