Thread: Windows 10 got stuck with PostgreSQL at starting up. Adding delaylets it avoid.

I got a trouble in PostgreSQL 9.3.x on Windows 10.
I would like to add new delay code as an official build option.

Windows 10 sometime (approximately once in 300 tries) hung up 
at OS starting up. The logs say it happened while the PostgreSQL 
service was starting. When OS stopped, some postgres auxiliary 
process were started and some were not started yet. 

The Windows dump say some threads of the postgres auxiliary process
are waiting OS level locks and the logon processes’thread are
also waiting a lock. MS help desk said that PostgreSQL’s OS level 
deadlock caused OS freeze. I think it is strange story. But, 
in fact, it not happened in repeated tests when I got rid of 
PostgreSQL from the initial auto-starting services.

I tweaked PostgreSQL 9.3.x (the newest from the repository) to add 
0.5 or 3.0 seconds delay after each sub process starts. 
And then the hung up was gone. This test patch is attached. 
It is only implemented for Windows. Also, I did not use existing 
pg_usleep because it contains locking codes (e.g. WaitForSingleObject
and Enter/LeaveCriticalSection).

Although Windows OS may have some problems, I think we should have
a means to avoid it. Can PostgreSQL be accepted such delay codes
as build-time options by preprocessor variables?


Thanks,
Takatsuka Haruka

TAKATSUKA Haruka schrieb am 29.06.2018 um 08:03:
> I got a trouble in PostgreSQL 9.3.x on Windows 10.
> I would like to add new delay code as an official build option.
> 
> Windows 10 sometime (approximately once in 300 tries) hung up 
> at OS starting up. The logs say it happened while the PostgreSQL 
> service was starting. When OS stopped, some postgres auxiliary 
> process were started and some were not started yet. 
> 
> The Windows dump say some threads of the postgres auxiliary process
> are waiting OS level locks and the logon processes’thread are
> also waiting a lock. MS help desk said that PostgreSQL’s OS level 
> deadlock caused OS freeze. I think it is strange story. But, 
> in fact, it not happened in repeated tests when I got rid of 
> PostgreSQL from the initial auto-starting services.
> 
> I tweaked PostgreSQL 9.3.x (the newest from the repository) to add 
> 0.5 or 3.0 seconds delay after each sub process starts. 
> And then the hung up was gone. This test patch is attached. 
> It is only implemented for Windows. Also, I did not use existing 
> pg_usleep because it contains locking codes (e.g. WaitForSingleObject
> and Enter/LeaveCriticalSection).
> 
> Although Windows OS may have some problems, I think we should have
> a means to avoid it. Can PostgreSQL be accepted such delay codes
> as build-time options by preprocessor variables?

Did you try setting the service to "delayed start"?

On Fri, 29 Jun 2018 08:34:18 +0200
Thomas Kellerer <spam_eater@gmx.net> wrote:

> Did you try setting the service to "delayed start"?

We didn't try it yet. Thanks to give an idea. I think that
MS would advise us already if it were a just solution for this case.
Anyway, we will try and confirm it.

Thanks,
Takatsuka Haruka


> TAKATSUKA Haruka schrieb am 29.06.2018 um 08:03:
> > I got a trouble in PostgreSQL 9.3.x on Windows 10.
> > I would like to add new delay code as an official build option.
> > 
> > Windows 10 sometime (approximately once in 300 tries) hung up 
> > at OS starting up. The logs say it happened while the PostgreSQL 
> > service was starting. When OS stopped, some postgres auxiliary 
> > process were started and some were not started yet. 
> > 
> > The Windows dump say some threads of the postgres auxiliary process
> > are waiting OS level locks and the logon processes’thread are
> > also waiting a lock. MS help desk said that PostgreSQL’s OS level 
> > deadlock caused OS freeze. I think it is strange story. But, 
> > in fact, it not happened in repeated tests when I got rid of 
> > PostgreSQL from the initial auto-starting services.
> > 
> > I tweaked PostgreSQL 9.3.x (the newest from the repository) to add 
> > 0.5 or 3.0 seconds delay after each sub process starts. 
> > And then the hung up was gone. This test patch is attached. 
> > It is only implemented for Windows. Also, I did not use existing 
> > pg_usleep because it contains locking codes (e.g. WaitForSingleObject
> > and Enter/LeaveCriticalSection).
> > 
> > Although Windows OS may have some problems, I think we should have
> > a means to avoid it. Can PostgreSQL be accepted such delay codes
> > as build-time options by preprocessor variables?

> On Fri, 29 Jun 2018 08:34:18 +0200
> Thomas Kellerer <spam_eater@gmx.net> wrote:
> 
> > Did you try setting the service to "delayed start"?
> 
> We didn't try it yet. Thanks to give an idea. I think that
> MS would advise us already if it were a just solution for this case.
> Anyway, we will try and confirm it.

We tried it. "Delayed start" was ineffective.
Also setting a script that start the PostgreSQL service
on the "startup" folder was ineffective.

It has not been solved except by PostgreSQL code modification (inserting delay).

Thanks,
Haruka Takatsuka


> > TAKATSUKA Haruka schrieb am 29.06.2018 um 08:03:
> > > I got a trouble in PostgreSQL 9.3.x on Windows 10.
> > > I would like to add new delay code as an official build option.
> > > 
> > > Windows 10 sometime (approximately once in 300 tries) hung up 
> > > at OS starting up. The logs say it happened while the PostgreSQL 
> > > service was starting. When OS stopped, some postgres auxiliary 
> > > process were started and some were not started yet. 
> > > 
> > > The Windows dump say some threads of the postgres auxiliary process
> > > are waiting OS level locks and the logon processes’thread are
> > > also waiting a lock. MS help desk said that PostgreSQL’s OS level 
> > > deadlock caused OS freeze. I think it is strange story. But, 
> > > in fact, it not happened in repeated tests when I got rid of 
> > > PostgreSQL from the initial auto-starting services.
> > > 
> > > I tweaked PostgreSQL 9.3.x (the newest from the repository) to add 
> > > 0.5 or 3.0 seconds delay after each sub process starts. 
> > > And then the hung up was gone. This test patch is attached. 
> > > It is only implemented for Windows. Also, I did not use existing 
> > > pg_usleep because it contains locking codes (e.g. WaitForSingleObject
> > > and Enter/LeaveCriticalSection).
> > > 
> > > Although Windows OS may have some problems, I think we should have
> > > a means to avoid it. Can PostgreSQL be accepted such delay codes
> > > as build-time options by preprocessor variables?