From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Lakhin <exclusion@gmail.com>
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16161: pg_ctl stop fails sometimes (on Windows)
In-reply-to: <58a715ac-d118-e7c1-733a-46fa252b345b@gmail.com>
References: <16161-7a985d2f1bbe8f71@postgresql.org>
 <4d28c7e1-fe91-b9fd-3227-478e549b05d5@gmail.com>
 <31098.1576445200@sss.pgh.pa.us>
 <c4c0e925-7b00-a555-9c56-80573af5ff4a@gmail.com>
 <18124.1576527433@sss.pgh.pa.us>
 <58a715ac-d118-e7c1-733a-46fa252b345b@gmail.com>
Comments: In-reply-to Alexander Lakhin <exclusion@gmail.com>
	message dated "Tue, 17 Dec 2019 06:00:00 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <23072.1576626626.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 17 Dec 2019 18:50:26 -0500
Message-ID: <23073.1576626626@sss.pgh.pa.us>
Precedence: bulk

Alexander Lakhin <exclusion@gmail.com> writes:
> 16.12.2019 23:17, Tom Lane wrote:
>> I've pushed this with adjustment of the other loop and some fooling
>> with the comment --- I still don't see a need to cite stackoverflow
>> as an authority.

> Thank you! I hope now Windows machines will concede the first place of
> the race for failures.

Seems like we're not there yet :-(.  Buildfarm members jacana and
fairywren have been failing the recovery tests, in v10 and up,
since this went in.  It looks like we're getting a timeout on
this step in 010_logical_decoding_timelines.pl:

# Should be able to read from slot created before base backup
($ret, $stdout, $stderr) =3D $node_replica->psql(
	'postgres',
	"SELECT data FROM pg_logical_slot_peek_changes('before_basebackup', NULL,=
 NULL, 'include-xids', '0', 'skip-empty-xacts', '1');",
	timeout =3D> 30);

Now, it's mighty suspicious that this has a timeout of 30 sec
which is exactly how long we made pgwin32_open retry for ---
but how is it that this test is causing an ERROR_ACCESS_DENIED
failure?  And if it was, how did we get past that before?

It does look suspiciously like this wait is triggering on these
machines and somehow getting masked in most other test cases.
If you compare the per-step runtimes in jacana's last successful
run,

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Djacana&dt=3D2019=
-12-16%2013%3A01%3A26

with those after this patch went in,

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Djacana&dt=3D2019=
-12-17%2004%3A16%3A40

there's clearly something very wrong.  fairywren likewise.

			regards, tom lane