Re: PostgreSQL in Windows console and Ctrl-C

Поиск
Список
Период
Сортировка
От Christian Ullrich
Тема Re: PostgreSQL in Windows console and Ctrl-C
Дата
Msg-id 1cd27aa163e94e039723ea1b086c314c@AMSPR06MB134.eurprd06.prod.outlook.com
обсуждение исходный текст
Ответ на Re: PostgreSQL in Windows console and Ctrl-C  (Noah Misch <noah@leadboat.com>)
Ответы Re: PostgreSQL in Windows console and Ctrl-C  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
* From: Noah Misch [mailto:noah@leadboat.com]

> On Mon, Jun 30, 2014 at 07:28:03PM +0000, Christian Ullrich wrote:

> > * From: Noah Misch [mailto:noah@leadboat.com]

> > > I liked the proposal here; was there a problem with it?
> > > http://www.postgresql.org/message-
> > > id/CA+TgmoZ3aKE4EnCTmQmZSyKC_0pjL_u4C_x47GE48uY1upBNxg@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
bymy patch. It would not. PostgreSQL's signal emulation on Windows works completely separately from the actual Windows
analogyto signals in console processes. My patch drops these "analogous" events, but the emulated signals still work
thesame 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
asusual. 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: bad estimation together with large work_mem generates terrible slow hash joins
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]