Re: win32 signals, part 4

Поиск
Список
Период
Сортировка
От Claudio Natoli
Тема Re: win32 signals, part 4
Дата
Msg-id A02DEC4D1073D611BAE8525405FCCE2B55F2E5@harris.memetrics.local
обсуждение исходный текст
Список pgsql-hackers-win32
Ok. I'm going to outline my rationale, and if you're probably going to
disagree, but I feel compelled to try anyway :-)

> In any production environment, you are going to be running
> postgresql as a service. In that case it's not up to the console ctrl
> handler to handle these events, but the service manager. Since it's not
> a console program, I assume (no, haven't tested) that it will/may fail
> in this cse.

Try it. It won't fail (the multi-threaded port I've got does the very same
thing).


> And if you're just testing, you will want it to run with a warning..

I disagree. If, for some reason I can't fathom, this call actually does fail
and I'm testing at the console, I'd rather it just failed immediately,
instead of dying when I Ctrl-C it and it performs no shutdown actions
whatsoever. Does the tip "don't kill -9 the postmaster" ring a bell? :-)


> Any integration with the Service Control Manager will come later.
> Depending on how that it done, this might change. I suggest we revisit
> it then.

I'll turn that argument back on you. Let it be fatal, and, depending on how
the SCM is done, maybe revisit it (which you probably won't need to).

Bottom line, this call is "never" going to fail. But, IMNSHO, if it did
fail, then something is seriously wrong, and I'd just as soon as not have
that postmaster/backend going anywhere near my data, thank you very much.

Cheers,
Claudio


---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

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

Предыдущее
От: "Magnus Hagander"
Дата:
Сообщение: Re: win32 signals, part 4
Следующее
От: "Magnus Hagander"
Дата:
Сообщение: Re: win32 signals, part 4