* From: Noah Misch [mailto:n...@leadboat.com]
> On Mon, Jun 30, 2014 at 07:28:03PM +0000, Christian Ullrich wrote: > > * From: Noah Misch [mailto:n...@leadboat.com] > > > I liked the proposal here; was there a problem with it? > > > http://www.postgresql.org/message- > > > id/ca+tgmoz3ake4enctmqmzsykc_0pjl_u4c_x47ge48uy1upb...@mail.gmail.co > > > m > > > > You're referring to the suggestion of accepting and ignoring the > > option on non-Windows, right? I can do that, I just don't see the > > point as long as pg_ctl has a separate code path (well, #ifdef) for > > Windows anyway. > > Yes. We normally recognize platform-specific options on every platform. > For example, the effective_io_concurrency GUC exists on all platforms, but > you can only change it on platforms where it matters. In that light, one > could argue for raising an error for --background on non-Windows systems. > I don't have a strong opinion on raising an error vs. ignoring the option, > but I do think the outcome of --background should be distinguishable from > the outcome of --sometypo on all platforms. I'm convinced, will change to --sometypo treatment. > > > The pg_upgrade test suite and the $(prove_check)-based test suites > > > rely on their pg_ctl-started postmasters receiving any console ^C. > > > pg_ctl deserves a --foreground or --no-background option for callers > > > that prefer the current behavior. That, or those tests need a new > > > way to launch the postmaster. > > > > Ah. More good news. Just to confirm, this is only about the tests, > > right, not the code they are testing? > > 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. > > If so, is there even a way to run either on Windows? The pg_upgrade > > test suite is a shell script, and prove_check is defined in > > Makefile.global and definitely not applicable to Windows. > > contrib/pg_upgrade/test.sh works under MSYS. Perhaps $(prove_check) > currently doesn't, but that's something to be fixed, not relied upon. Yes. That doesn't matter, though. > There's a clone of contrib/pg_upgrade/test.sh in > src/tools/msvc/vcregress.pl, and I expect it would have the same problem. Oh, right. I didn't notice that because it doesn't mention upgradecheck in its usage message. 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. 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. Anyway, I just ran upgradecheck, and it reported success without leaving any stale postmasters around. -- Christian -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
