Horton

Re: BUG #16161: pg_ctl stop fails sometimes (on Windows)

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Date: 2019-12-17T23:50:26Z
Lists: pgsql-bugs 
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) = $node_replica->psql(
	'postgres',
	"SELECT data FROM pg_logical_slot_peek_changes('before_basebackup', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1');",
	timeout => 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=jacana&dt=2019-12-16%2013%3A01%3A26

with those after this patch went in,

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

there's clearly something very wrong.  fairywren likewise.

			regards, tom lane

Commits

  1. In pgwin32_open, loop after ERROR_ACCESS_DENIED only if we can't stat.

  2. On Windows, wait a little to see if ERROR_ACCESS_DENIED goes away.