On Mon, Jun 30, 2014 at 09:16:45PM +0000, Christian Ullrich wrote: > * From: Noah Misch [mailto:n...@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 affected by my patch. It would not. > PostgreSQL's signal emulation on Windows works completely separately from the > actual Windows analogy to signals in console processes. My patch drops these > "analogous" events, but the emulated signals still work the 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 as usual. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
