Re:
| От | Krystian Bigaj |
|---|---|
| Тема | Re: |
| Дата | |
| Msg-id | CAN=kAeGatv-FjQEnYpoBaaaRTDwObx_+j6vqWJL==QvZ74JAsw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: (Kalai R <softlinne.kv@gmail.com>) |
| Список | pgsql-general |
On 23 July 2014 08:59, Kalai R <softlinne.kv@gmail.com> wrote:
Is this a Windows *server* version, or is it one of the newer desktop OS's like Windows 8? Windows 8 seems to shut down rather fast, its quite possible its not bothering to wait for services to exit.I face this problem in Windows XP and Windows 7 but not all windows XP and Windows 7.In Windows 8 and Windows Server no problem.
It seems like Windows isn't waiting for the service to exit cleanly before its pulling the plug.I think so, but I don't know how to solve this problem.
Windows will kill service processes on shutdown based on WaitToKillServiceTimeout registry setting (this will vary by OS, and other application might change it).
This value can be lowered by some stupid 'pseudo' OS optimizer.
Try to increase WaitToKillServiceTimeout value to for example 300000 (it's 5 min.), restart OS, and see if you can still reproduce problem on shutdown. It problem will appear again and system shutdown hangs for 5min then you can suspect some deadlock.
There is also bug in Windows 7/Windows Server 2008 R2 (even with SP1, and all fixes from Windows Update):
http://support.microsoft.com/kb/2549760 (only hotfix - not available on Windows Update) - without this hotfix changing WaitToKillServiceTimeout doesn't have any effect!
Windows 2003 Small Business Server installer incorrectly set this value type: http://support.microsoft.com/kb/839262 - this one might be fixed in SP1, but I haven't time/need to test it.
(Notes below might not be helpful for this case, but it describes problems/solutions that I had with Postgres working as a Windows service).
Another note about Windows services and shutdown is that service dependency isn't considered during system shutdown (this one is documented/by design).
However here I think that Postgres have a problem when working as a Windows service:
- main postmaster and forked sub-postmasters processes calls pgwin32_signal_initialize() (src\backend\main\main.c and src\backend\postmaster\postmaster.c),
- pgwin32_signal_initialize() registers console handler by SetConsoleCtrlHandler(pg_console_handler, ...) - this is registered also when PG works as a Windows service,
- when pg_console_handler receives CTRL_SHUTDOWN_EVENT from OS, then it calls pg_queue_signal(SIGINT).
Problems:
- when OS is in shutdown path, then it sends CTRL_SHUTDOWN_EVENT, and *all* Postgres processes (main and sub/forked) will call pg_queue_signal(SIGINT) - so main and sub processes will start to shutdown independently? Can this have any bad consequences?
- even if Postgres is running as a Windows service (for example by pg_ctl), then postgres.exe process can exit even before pg_ctl will receive event about shutdown - this one was a problem for me, because in our app. I need to wait first that our service stops, and then I let Postgres to stop (I have my own service - not pg_ctl - which will start/stop postgres.exe process).
I think that CTRL_SHUTDOWN_EVENT should be removed from pg_console_handler, because as docs says:
CTRL_SHUTDOWN_EVENT
A signal that the system sends when the system is shutting down. Interactive applications are not present by the time the system sends this signal, therefore it can be received only be services in this situation.
so it will be called only for service processes (because app. processes won't be preset on shutdown),
but in that case, service should be responsible to send shutdown signal to Postgres - like pg_ctl do it by kill(postmasterPID, SIGINT).
This code with CTRL_SHUTDOWN_EVENT (intially in libpg/pgsignal.c) is since:
Revision: f06e79525a57ccbf54ae5d0b673cd904ca978d67
Date: 2004-02-08 23:28:57
so I'm not sure if I'm missing something here, or this bug wasn't noticed for 10 years :)
My workaround: own service which will start/stop Postgres (mainly to wait for our service to stop, running initdb.exe in context of NetworkService, etc.).
I've also written small Postgres module loaded via shared_preload_libraries which will call SetConsoleCtrlHandler, and my HandlerRoutine which simply returns TRUE. Because of this pg_console_handler won't be called (so no processing CTRL_SHUTDOWN_EVENT by any Postgress process).
Best regards,
Krystian Bigaj
Krystian Bigaj
В списке pgsql-general по дате отправления: