On Mon, Jun 30, 2014 at 09:16:45PM +0000, Christian Ullrich wrote:
> * From: Noah Misch [mailto:noah@leadboat.com]
> > Yes; the consequence of ignoring ^C is that the test postmaster would
> > persist indefinitely after the ^C. The system under test doesn't care per
>
> No it won't, please see below.
> I think I know where we're talking past each other. You may be assuming that kill(postmaster, SIGINT) would be
affectedby my patch. It would not. PostgreSQL's signal emulation on Windows works completely separately from the actual
Windowsanalogy to signals in console processes. My patch drops these "analogous" events, but the emulated signals still
workthe same way as before.
I wasn't assuming otherwise.
> When Ctrl-C is pressed in a console window, pg_console_handler() in backend/port/win32/signal.c is called with a
CTRL_C_EVENT,and converts that to an emulated SIGINT (unless I tell it not to). That emulated SIGINT is then processed
asusual. pg_ctl -m fast stop sends the emulated SIGINT directly.
The main point of this patch is to have pg_console_handler() in the postmaster
ignore ^C when "pg_ctl start" had started this postmaster. Right?
> Anyway, I just ran upgradecheck, and it reported success without leaving any stale postmasters around.
By the time the test reports success, it has already shutdown the postmaster
cleanly. I'm focusing on the case where the user decides halfway through the
test run to cancel it. Currently, ^C will reach both the test driver and the
postmaster, and everything will shut down; no "pg_ctl stop" is involved. What
happens if you issue "vcregress upgradecheck" and strike ^C between the
"Setting up data for upgrading" and "Dumping old cluster" messages?
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com