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