PostgreSQL in Windows console and Ctrl-C

Can someone with Windows expertise comment on whether this should be
applied?

---------------------------------------------------------------------------

On Tue, Jan 7, 2014 at 12:44:33PM +0100, Christian Ullrich wrote:

Hello all,

when pg_ctl start is used to run PostgreSQL in a console window on
Windows, it runs in the background (it is terminated by closing the
window, but that is probably inevitable). There is one problem,
however: The first Ctrl-C in that window, no matter in which
situation, will cause the background postmaster to exit. If you,
say, ping something, and press Ctrl-C to stop ping, you probably
don't want the database to go away, too.

The reason is that Windows delivers the Ctrl-C event to all
processes using that console, not just to the foreground one.

Here's a patch to fix that. "pg_ctl stop" still works, and it has no
effect when running as a service, so it should be safe. It starts
the postmaster in a new process group (similar to calling setpgrp()
after fork()) that does not receive Ctrl-C events from the console
window.

--
Christian

diff --git a/src/bin/pg_ctl/pg_ctl.c b/src/bin/pg_ctl/pg_ctl.c
new file mode 100644
index 50d4586..89a9544
*** a/src/bin/pg_ctl/pg_ctl.c
--- b/src/bin/pg_ctl/pg_ctl.c
*************** CreateRestrictedProcess(char *cmd, PROCE
*** 1561,1566 ****
--- 1561,1567 ----
HANDLE		restrictedToken;
SID_IDENTIFIER_AUTHORITY NtAuthority = {SECURITY_NT_AUTHORITY};
SID_AND_ATTRIBUTES dropSids[2];
+ 	DWORD		flags;

/* Functions loaded dynamically */
__CreateRestrictedToken _CreateRestrictedToken = NULL;
*************** CreateRestrictedProcess(char *cmd, PROCE
*** 1636,1642 ****
AddUserToTokenDacl(restrictedToken);
#endif

! r = CreateProcessAsUser(restrictedToken, NULL, cmd, NULL, NULL, TRUE, CREATE_SUSPENDED, NULL, NULL, &si, processInfo);

Kernel32Handle = LoadLibrary("KERNEL32.DLL");
if (Kernel32Handle != NULL)
--- 1637,1650 ----
AddUserToTokenDacl(restrictedToken);
#endif

! flags = CREATE_SUSPENDED;
!
! /* Protect console process from Ctrl-C */
! if (!as_service) {
! flags |= CREATE_NEW_PROCESS_GROUP;
! }
!
! r = CreateProcessAsUser(restrictedToken, NULL, cmd, NULL, NULL, TRUE, flags, NULL, NULL, &si, processInfo);

Kernel32Handle = LoadLibrary("KERNEL32.DLL");
if (Kernel32Handle != NULL)

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Apr 11, 2014 at 7:44 AM, Bruce Momjian <bruce@momjian.us> wrote:

Can someone with Windows expertise comment on whether this should be
applied?

I tested the same in windows and it is working as specified.
The same background running server can be closed with ctrl+break command.

---------------------------------------------------------------------------

On Tue, Jan 7, 2014 at 12:44:33PM +0100, Christian Ullrich wrote:

Hello all,

when pg_ctl start is used to run PostgreSQL in a console window on
Windows, it runs in the background (it is terminated by closing the
window, but that is probably inevitable). There is one problem,
however: The first Ctrl-C in that window, no matter in which
situation, will cause the background postmaster to exit. If you,
say, ping something, and press Ctrl-C to stop ping, you probably
don't want the database to go away, too.

The reason is that Windows delivers the Ctrl-C event to all
processes using that console, not just to the foreground one.

Here's a patch to fix that. "pg_ctl stop" still works, and it has no
effect when running as a service, so it should be safe. It starts
the postmaster in a new process group (similar to calling setpgrp()
after fork()) that does not receive Ctrl-C events from the console
window.

--
Christian

diff --git a/src/bin/pg_ctl/pg_ctl.c b/src/bin/pg_ctl/pg_ctl.c
new file mode 100644
index 50d4586..89a9544
*** a/src/bin/pg_ctl/pg_ctl.c
--- b/src/bin/pg_ctl/pg_ctl.c
*************** CreateRestrictedProcess(char *cmd, PROCE
*** 1561,1566 ****
--- 1561,1567 ----
HANDLE          restrictedToken;
SID_IDENTIFIER_AUTHORITY NtAuthority = {SECURITY_NT_AUTHORITY};
SID_AND_ATTRIBUTES dropSids[2];
+     DWORD           flags;

/* Functions loaded dynamically */
__CreateRestrictedToken _CreateRestrictedToken = NULL;
*************** CreateRestrictedProcess(char *cmd, PROCE
*** 1636,1642 ****
AddUserToTokenDacl(restrictedToken);
#endif

! r = CreateProcessAsUser(restrictedToken, NULL, cmd, NULL, NULL, TRUE, CREATE_SUSPENDED, NULL, NULL, &si, processInfo);

Kernel32Handle = LoadLibrary("KERNEL32.DLL");
if (Kernel32Handle != NULL)
--- 1637,1650 ----
AddUserToTokenDacl(restrictedToken);
#endif

! flags = CREATE_SUSPENDED;
!
! /* Protect console process from Ctrl-C */
! if (!as_service) {
! flags |= CREATE_NEW_PROCESS_GROUP;
! }
!
! r = CreateProcessAsUser(restrictedToken, NULL, cmd, NULL, NULL, TRUE, flags, NULL, NULL, &si, processInfo);

Kernel32Handle = LoadLibrary("KERNEL32.DLL");
if (Kernel32Handle != NULL)

Regards,
Hari Babu
Fujitsu Australia

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Apr 11, 2014 at 11:58:58AM +1000, Haribabu Kommi wrote:

On Fri, Apr 11, 2014 at 7:44 AM, Bruce Momjian <bruce@momjian.us> wrote:

Can someone with Windows expertise comment on whether this should be
applied?

I tested the same in windows and it is working as specified.
The same background running server can be closed with ctrl+break command.

OK. If I apply this, are you able to test to see if the problem is
fixed?

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Apr 11, 2014 at 12:12 PM, Bruce Momjian <bruce@momjian.us> wrote:

On Fri, Apr 11, 2014 at 11:58:58AM +1000, Haribabu Kommi wrote:

On Fri, Apr 11, 2014 at 7:44 AM, Bruce Momjian <bruce@momjian.us> wrote:

Can someone with Windows expertise comment on whether this should be
applied?

I tested the same in windows and it is working as specified.
The same background running server can be closed with ctrl+break command.

OK. If I apply this, are you able to test to see if the problem is
fixed?

I already tested in HEAD by applying the attached patch in the earlier mail.
with ctrl+c command the background process is not closed.
But with ctrl+break command the same can be closed.
if this behavior is fine, then we can apply patch.

Regards,
Hari Babu
Fujitsu Australia

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Apr 11, 2014 at 3:14 AM, Bruce Momjian <bruce@momjian.us> wrote:

Can someone with Windows expertise comment on whether this should be
applied?

I don't think this is a complete fix, for example what about platform where
_CreateRestrictedToken() is not supported. For Example, the current
proposed fix will not work for below case:

if (_CreateRestrictedToken == NULL)
{
/*
* NT4 doesn't have CreateRestrictedToken, so just call ordinary
* CreateProcess
*/
write_stderr(_("%s: WARNING: cannot create restricted tokens on this
platform\n"), progname);
if (Advapi32Handle != NULL)
FreeLibrary(Advapi32Handle);
return CreateProcess(NULL, cmd, NULL, NULL, FALSE, 0, NULL, NULL, &si,
processInfo);
}

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 04/11/2014 01:35 AM, Amit Kapila wrote:

On Fri, Apr 11, 2014 at 3:14 AM, Bruce Momjian <bruce@momjian.us> wrote:

Can someone with Windows expertise comment on whether this should be
applied?

I don't think this is a complete fix, for example what about platform where
_CreateRestrictedToken() is not supported. For Example, the current
proposed fix will not work for below case:

if (_CreateRestrictedToken == NULL)
{
/*
* NT4 doesn't have CreateRestrictedToken, so just call ordinary
* CreateProcess
*/

Are we really supporting NT4 any more? Even XP is about to be at end of
support from Microsoft.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2014-04-11 07:12:50 -0400, Andrew Dunstan wrote:

On 04/11/2014 01:35 AM, Amit Kapila wrote:

On Fri, Apr 11, 2014 at 3:14 AM, Bruce Momjian <bruce@momjian.us> wrote:

Can someone with Windows expertise comment on whether this should be
applied?

I don't think this is a complete fix, for example what about platform where
_CreateRestrictedToken() is not supported. For Example, the current
proposed fix will not work for below case:

if (_CreateRestrictedToken == NULL)
{
/*
* NT4 doesn't have CreateRestrictedToken, so just call ordinary
* CreateProcess
*/

Are we really supporting NT4 any more? Even XP is about to be at end of
support from Microsoft.

I seem to recall that win2k was already desupported?

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Apr 11, 2014 at 4:42 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

On 04/11/2014 01:35 AM, Amit Kapila wrote:

I don't think this is a complete fix, for example what about platform
where
_CreateRestrictedToken() is not supported. For Example, the current
proposed fix will not work for below case:

if (_CreateRestrictedToken == NULL)
{
/*
* NT4 doesn't have CreateRestrictedToken, so just call ordinary
* CreateProcess
*/

Are we really supporting NT4 any more? Even XP is about to be at end of
support from Microsoft.

In Docs, it is mentioned as Windows (Win2000 SP4 and later).
Now what shall we do with this part of code, shall we keep it as it is and
just fix in other part of code or shall we remove this part of code?

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

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* 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).

I can think of three situations in which a postgres process can run on
Windows:

- single backend
- console background via pg_ctl
- service

The only way to deliver a console event to a service process is by
calling GenerateConsoleCtrlEvent() with that process( group)'s PID. If
anyone does that, they will know what they are doing, so we can disregard
that. The other two are tricky. In single-backend mode, we probably expect
both to work as usual (ending the process), while in the pg_ctl case,
they should both be ignored.

Ignoring Ctrl-C in the postmaster and all children is simple, this is what
my patch does. Ctrl-Break is more difficult to do. It is not limited to
the "foreground" process group, but is delivered to all processes attached
to the console that originates it. To ignore it, every process (postmaster,
backends, workers, etc.) will have to handle it in their own console
event handling function.

backend/port/win32/signal.c explicitly turns several of the console events,
including Ctrl-C and Ctrl-Break, into SIGINT. The simplest fix would be to
ignore Ctrl-Break there, effectively disabling it entirely under all
circumstances. I tried that, and it appears to work, but I don't know
enough about the signal emulation and the interactions between the various
processes to be sure this is the right place to do it. Single-backend mode
has no need for signal handling and does not use the emulation layer, so
it is unaffected.

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.

Please be gentle.

diff --git a/src/backend/port/win32/signal.c b/src/backend/port/win32/signal.c
index 322b857..7ce5051 100644
--- a/src/backend/port/win32/signal.c
+++ b/src/backend/port/win32/signal.c
@@ -347,8 +347,12 @@ static BOOL WINAPI
 pg_console_handler(DWORD dwCtrlType)
 {
 	if (dwCtrlType == CTRL_C_EVENT ||
-		dwCtrlType == CTRL_BREAK_EVENT ||
-		dwCtrlType == CTRL_CLOSE_EVENT ||
+		dwCtrlType == CTRL_BREAK_EVENT)
+	{
+		/* Ignore */
+		return TRUE;
+	}
+	else if (dwCtrlType == CTRL_CLOSE_EVENT ||
 		dwCtrlType == CTRL_SHUTDOWN_EVENT)
 	{
 		pg_queue_signal(SIGINT);

--
Christian

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.

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.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sun, Apr 13, 2014 at 5:59 PM, Christian Ullrich <chris@chrullrich.net> wrote:

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?).

Do you mean to say use some existing environment variable?
Introducing an environment variable to solve this issue or infact using
some existing environ variable doesn't seem to be the best way to pass
such information.

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.

We are already creating one job object, so may be that itself can be
used, but not sure if Job Objects are supported on all platforms on which
postgres works.

If you have to pass such information, then why don't pass some special
flag in command to CreateProcess()?

There is always a chance that we ignore the CTRL+C for some app which
we don't intend if we solve the problem by passing some info, as some
other app could also do so, but I think it should not be a big problem.

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.

The problem can be solved this way, but the only question here is whether
it is acceptable for users to have a new console window for server.

Can others also please share their opinion if this fix (start server in new
console) seems acceptable or shall we try by passing some information
from pg_ctl and then ignore CTRL+C && CTRL+BREAK for it?

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* From: Amit Kapila

On Sun, Apr 13, 2014 at 5:59 PM, Christian Ullrich <chris@chrullrich.net>
wrote:

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?).

Do you mean to say use some existing environment variable?
Introducing an environment variable to solve this issue or infact using
some existing environ variable doesn't seem to be the best way to pass
such information.

I meant creating a new one, yes. If, say, PGSQL_BACKGROUND_JOB was set,
the postmaster etc. would ignore the events.

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.

We are already creating one job object, so may be that itself can be
used, but not sure if Job Objects are supported on all platforms on which
postgres works.

I mentioned that in my earlier message; we cannot rely on having that job
object around. If the OS does not support them (not much of a problem
nowadays, I think; anything anyone is going to run the version this will
first be released in on is going to) or, more likely, if something uses
PostgreSQL as "embedded" database and starts it in a job of their own,
pg_ctl will not create its job object.

There may also be software out there that a) runs PostgreSQL in this way,
b) uses the console events to stop it again, and c) does that with or
without a separate job object. Hence, deciding based on the existence of
a job object would break backward compatibility in this case, assuming
it exists in reality.

If you have to pass such information, then why don't pass some special
flag in command to CreateProcess()?

Because I wanted to avoid introducing a command line option to tell the
postmaster who started it. If we cannot look at job objects, and an
environment variable is not an option either, then this looks like the
best remaining solution.

I will create a patch based on this approach.

There is always a chance that we ignore the CTRL+C for some app which
we don't intend if we solve the problem by passing some info, as some
other app could also do so, but I think it should not be a big problem.

No. In fact, if whatever starts the postmaster does pass that flag, we
can safely assume that it did not do so just for fun.

--
Christian

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, Apr 14, 2014 at 09:34:14AM +0530, Amit Kapila wrote:

The problem can be solved this way, but the only question here is whether
it is acceptable for users to have a new console window for server.

Can others also please share their opinion if this fix (start server in new
console) seems acceptable or shall we try by passing some information
from pg_ctl and then ignore CTRL+C && CTRL+BREAK for it?

I wanted to point out that I think this patch is only appropriate for
head, not backpatching. Also, on Unix we have to handle signals that
come from the kill command. Can you send CTRL+C from other
applications on Windows?

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, Apr 14, 2014 at 11:46 AM, Christian Ullrich
<chris@chrullrich.net> wrote:

* From: Amit Kapila

Do you mean to say use some existing environment variable?
Introducing an environment variable to solve this issue or infact using
some existing environ variable doesn't seem to be the best way to pass
such information.

I meant creating a new one, yes. If, say, PGSQL_BACKGROUND_JOB was set,
the postmaster etc. would ignore the events.

Do you plan to reset it and if yes when?
I think there is chance that after setting this environment variable, some other
instance of server (postmaster) can read it and missed the signal
which it should
have otherwise processed.

Irrespective of above problem, I think using environment variable might not be a
good way to solve this problem.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Apr 15, 2014 at 4:21 AM, Bruce Momjian <bruce@momjian.us> wrote:

On Mon, Apr 14, 2014 at 09:34:14AM +0530, Amit Kapila wrote:

The problem can be solved this way, but the only question here is whether
it is acceptable for users to have a new console window for server.

Can others also please share their opinion if this fix (start server in new
console) seems acceptable or shall we try by passing some information
from pg_ctl and then ignore CTRL+C && CTRL+BREAK for it?

I wanted to point out that I think this patch is only appropriate for
head, not backpatching. Also, on Unix we have to handle signals that
come from the kill command. Can you send CTRL+C from other
applications on Windows?

I think there are ways to achieve it, but might not be very straightforward.
If we start server in new console window through pg_ctl, then we *don't*
need to change any signal handler to catch and do something specific
for CTRL+C/CTRL+BREAK.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, Apr 14, 2014 at 2:16 AM, Christian Ullrich <chris@chrullrich.net> wrote:

I meant creating a new one, yes. If, say, PGSQL_BACKGROUND_JOB was set,
the postmaster etc. would ignore the events.

Why not just pass a command-line switch?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* From: Robert Haas

On Mon, Apr 14, 2014 at 2:16 AM, Christian Ullrich
<chris@chrullrich.net> wrote:

I meant creating a new one, yes. If, say, PGSQL_BACKGROUND_JOB was
set, the postmaster etc. would ignore the events.

Why not just pass a command-line switch?

Because, as I wrote in the message you are quoting, I did not think that
having a command-line option for the sole purpose of telling the
postmaster who its parent is was a suitable solution.

I had already given up on that idea based on Amit's advice, and I will
create a patch based on a command-line option.

While I have you here, though, any suggestions on what the name of that
option should be? I think --background is about right. Also, how should
I treat the option on non-Windows platforms? Should it just not be there
(= error), or be ignored if present?

--
Christian

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* From: Bruce Momjian

On Mon, Apr 14, 2014 at 09:34:14AM +0530, Amit Kapila wrote:

The problem can be solved this way, but the only question here is
whether it is acceptable for users to have a new console window for
server.

Can others also please share their opinion if this fix (start server
in new console) seems acceptable or shall we try by passing some
information from pg_ctl and then ignore CTRL+C && CTRL+BREAK for it?

I wanted to point out that I think this patch is only appropriate for
head, not backpatching. Also, on Unix we have to handle signals that

Yes, of course.

come from the kill command. Can you send CTRL+C from other applications
on Windows?

Yes again, using GenerateConsoleCtrlEvent() you can send these events to
any (console-attached) process you have the required permissions for,
but that is not an issue for the same reason it isn't one on Unix. All
the target process sees is the event, it cannot determine (nor does it
care) where the event came from.

--
Christian

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers