Re: PostgreSQL in Windows console and Ctrl-C

From: Christian Ullrich <chris(at)chrullrich(dot)net>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Subject: Re: PostgreSQL in Windows console and Ctrl-C
Date: 2014-04-13 12:29:13
Message-ID: ba0dcea8c4e14b04881bc19725138f44@AMSPR06MB134.eurprd06.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* From: Amit Kapila

> On Sat, Apr 12, 2014 at 12:36 PM, Christian Ullrich <chris(at)chrullrich(dot)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 check the 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 for access 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 have been 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, and it 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 can check 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2014-04-13 12:40:33 Re: pgsql: Add ANALYZE into regression tests
Previous Message Marko Kreen 2014-04-13 12:27:24 Re: Problem with txid_snapshot_in/out() functionality