From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Fw: Windows 10 got stuck with PostgreSQL at starting up. Adding delay lets it avoid. |
Date: | 2018-07-20 14:48:15 |
Message-ID: | 18895.1532098095@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Yugo Nagata <nagata(at)sraoss(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Victor Wagner | 2018-07-20 14:55:08 | Re: Non-portable shell code in pg_upgrade tap tests |
Previous Message | Tom Lane | 2018-07-20 14:25:47 | Re: Non-portable shell code in pg_upgrade tap tests |