Re: Fw: Windows 10 got stuck with PostgreSQL at starting up. Adding delay lets it avoid.
От | Tom Lane |
---|---|
Тема | Re: Fw: Windows 10 got stuck with PostgreSQL at starting up. Adding delay lets it avoid. |
Дата | |
Msg-id | 18895.1532098095@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Fw: Windows 10 got stuck with PostgreSQL at starting up. Addingdelay lets it avoid. (Yugo Nagata <nagata@sraoss.co.jp>) |
Ответы |
Re: Fw: Windows 10 got stuck with PostgreSQL at starting up. Addingdelay lets it avoid.
|
Список | pgsql-hackers |
Yugo Nagata <nagata@sraoss.co.jp> writes: > Recently, one of our clients reported a problem that Windows 10 sometime > (approximately once in 300 tries) hung up at OS starting up while PostgreSQL > 9.3.x service is starting up. My co-worker analyzed this and found that > PostgreSQL's auxiliary process and Windows' logon processes are in a dead-lock > situation. Really? What would they deadlock on? Why is there any connection whatsoever? Why has nobody else run into this? > He reported this problem to pgsql-general list as below. Also, he created a patch > to add a build-time option for adding 0.5 or 3.0 seconds delay after each sub > process starts. This seems like an ugly hack that probably doesn't reliably resolve whatever the problem is, but does manage to kill postmaster responsiveness :-(. It'd be especially awful to insert such a delay after forking parallel worker processes, which would be a problem in anything much newer than 9.3. I think we need more investigation; and to start with, reproducing the problem in a branch that's not within hailing distance of its EOL would be a good idea. (Not that I have reason to think PG's behavior has changed much here ... but 9.3 is just not a good basis for asking us to do anything now.) regards, tom lane
В списке pgsql-hackers по дате отправления: