On Fri, 20 Jul 2018 19:13:21 +0900
Michael Paquier <michael@paquier.xyz> wrote:
> On Fri, Jul 20, 2018 at 05:58:13PM +0900, Yugo Nagata wrote:
> > 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. The attached is the same one. Our client confirmed that this
> > patch resolves the dead-lock problem. Is it acceptable to add this option to
> > PostgreSQL? Any comment would be appreciated.
>
> If the OS startup gets slower, then an arbitrary delay is not going to
> solve things and you would finish by facing the same problem. It seems
> to me that we need to understand what are the low-level locks which get
> stuck, if it is possible to make their acquirement conditional, and then
> loop conditionally with multiple retries.
From investigation of the kernel dump of Windows, it seems that PushLocks
were acqired in postgres processes and that this caused the deadlock.
However, it is still not clear which part of postgres code is involved this
lock. We will investigate this more and report if we found something.
> --
> Michael
--
Yugo Nagata <nagata@sraoss.co.jp>
