Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: Intermittent pg_ctl failures on Windows
From: =?utf-8?B?0JbQsNGA0LrQvtCyINCg0L7QvNCw0L0=?= <r.zharkov@postgrespro.ru>
In-Reply-To: <20190719030208.GG1859@paquier.xyz>
Date: Fri, 19 Jul 2019 12:00:37 +0700
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Badrul Chowdhury <bachow@microsoft.com>,
 pgsql-hackers@lists.postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <FE69ED0E-0232-406F-8712-16A92F55C53A@postgrespro.ru>
References: <16922.1520722108@sss.pgh.pa.us>
 <DM5PR2101MB0984D3DB39BCCCF189ECD15ED1D30@DM5PR2101MB0984.namprd21.prod.outlook.com>
 <0057a0ce5a8893e4713a9a9d7e352162@postgrespro.ru>
 <26631.1563371508@sss.pgh.pa.us>
 <3b46fc8be044c79b5eff7d26c810d2fd@postgrespro.ru>
 <20190718085148.GI1416@paquier.xyz>
 <B9F855CF-1756-40FA-B9AF-1F48A9480269@postgrespro.ru>
 <20190719030208.GG1859@paquier.xyz>
To: Michael Paquier <michael@paquier.xyz>
Precedence: bulk

First time we found pg_ctl errors while testing our fork.
I reproduced them on REL_11_STABLE.
I found three problems with pg_ctl do_stop/do_restart:
1 - "old" fopen() function;
2 - "delete pending" problem rarely happens with "new" fopen() function when=
 pg_ctl tries to open postmaster.pid file;
3 - cmd.exe shell may block the log file when the server restarts;

Now i try to reproduce it on REL_12_STABLE

regard, Roman

> 19 =D0=B8=D1=8E=D0=BB=D1=8F 2019 =D0=B3., =D0=B2 10:02, Michael Paquier <m=
ichael@paquier.xyz> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):
>=20
>> On Thu, Jul 18, 2019 at 04:14:34PM +0700, =D0=96=D0=B0=D1=80=D0=BA=D0=BE=D0=
=B2 =D0=A0=D0=BE=D0=BC=D0=B0=D0=BD wrote:
>> I have tested clean REL_11_STABLE.
>> Commit f02259fe was reverted by df8b5f3e in this branch.
>> So pg_ctl uses =E2=80=9Cold=E2=80=9D open() function.
>=20
> Yeah, that was a failure from me, so I tend to be rather very careful
> about anything related to Windows.  However, after that we have added=20
> 40cfe86 about which nobody has complained yet, and the number of
> buildfarm failures about pg_ctl concurrency on HEAD has gone down to
> zero since (perhaps I am missing something?).
>=20
> So, instead of trying to invent a new solution only for stable
> branches (which may have its own bugs we would need to deal with only
> on stable branches, and only for Windows), why don't we just try to
> move forward into back-patching those pieces?  Or it happens that we
> still have some potential failures on HEAD and REL_12_STABLE which
> would justify some extra handling?  In this case, I would recommend
> that we focus on HEAD as a first step, and put things in order there.
> --
> Michael