Re:

On 23 July 2014 08:59, Kalai R <softlinne(dot)kv(at)gmail(dot)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:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683242(v=vs.85).aspx

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