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

pg_ctl / SCM interaction

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: pgsql-hackers-win32 <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: pg_ctl / SCM interaction
Date: 2004-05-24 14:30:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers-win32
[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

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

Makes sense.



pgsql-hackers-win32 by date

Next:From: Magnus HaganderDate: 2004-05-24 14:35:45
Subject: Re: pg_ctl / SCM interaction
Previous:From: Merlin MoncureDate: 2004-05-24 12:52:33
Subject: Re: nightly win32 builds

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