* From: Amit Kapila
> On Sat, Apr 12, 2014 at 12:36 PM, Christian Ullrich <chris@chrullrich.net>
> wrote:
> > * From: Amit Kapila
> >
> >> Another thing to decide about this fix is that whether it is okay to
> >> fix it for CTRL+C and leave the problem open for CTRL+BREAK?
> >> (The current option used (CREATE_NEW_PROCESS_GROUP) will handle only
> >> CTRL+C).
> >
> > Below is a new (right now very much proof-of-concept) patch to replace
> > my earlier one. It has the same effect on Ctrl-C the change to pg_ctl
> > had, and additionally ignores Ctrl-Break as well.
>
> This fix won't allow CTRL+C for other cases like when server is started
> directly with postgres binary.
> ./postgres -D <data_dir_path>
> I think this doesn't come under your original complaint and as such I
> don't see any problem in allowing CTRL+C for above case.
Good point. I had not thought of that case. Just how do you tell if your
postmaster was started by pg_ctl or directly on the command line?
- pg_ctl starts the postmaster through an intervening shell, so even if it did not exit right after that, we could not
checkthe parent process name (assuming nobody renamed pg_ctl).
- pg_ctl starts the postmaster with stdin redirected from the null device, but so could anyone else. The same is true
foraccess rights, token groups, and most everything else pg_ctl does.
- I don't want to add a new command line flag to postgres.exe just to tell it who its parent is.
- Job objects may not be supported on the underlying OS, or creation may have failed, or the interactive console may
havebeen running in one already, so the sheer existence of a job is no proof it's ours.
There are some possible solutions:
- pg_ctl could set an environment variable (unless it has to be compatible with postmasters from different versions,
andit does not, does it?).
pg_ctl creates a named job object, and the postmaster has all the information it needs to reconstruct the name, so it
cancheck if it is running inside that pg_ctl-created job.
I would appreciate some advice on this.
> One another way could be to use CREATE_NEW_CONSOLE instead of
> CREATE_NEW_PROCESS_GROUP in you previous fix, but I am not sure if it's
> acceptable to users to have a new console window for server.
It might. That would also isolate stderr logging from whatever else the
user is doing in the window, and it would work correctly in the pg_ctl
(and by extension the direct-postmaster) case. It would not do anything
for events generated by keystrokes in the new console window, though.
There would also have to be a command line option to pg_ctl to either
enable or disable it, not sure which.
--
Christian