Re: Intermittent pg_ctl failures on Windows

Hello,

I have reproduced the DELETE_PENDING error on the REL_12_STABLE.
I changed the WAITS_PER_SEC to 500000 in the pg_ctl.c file.
Then I launched dummy TAP test ( see attachment ).
The picture in the attachment illustrates the hidden DELETE_PENDING
error.

-------------------------------------------
Log output:
# Postmaster PID for node "master" is 17796
# restarted 233
# 14:31:05
### Restarting node "master"
# Running: pg_ctl -D
C:/HOME/Git/postgrespro/src/test/pg_ctl/tmp_check/t_test_master_data/pgdata
-l C:/HOME/Git/postgrespro/src/test/pg_ctl/tmp_check/log/test_master.log
restart
waiting for server to shut down....pg_ctl: could not open PID file
"C:/HOME/Git/postgrespro/src/test/pg_ctl/tmp_check/t_test_master_data/pgdata/postmaster.pid":
Permission denied
Bail out! system pg_ctl failed
### Stopping node "master" using mode immediate
# Running: pg_ctl -D
C:/HOME/Git/postgrespro/src/test/pg_ctl/tmp_check/t_test_master_data/pgdata
-m immediate stop
pg_ctl: PID file
"C:/HOME/Git/postgrespro/src/test/pg_ctl/tmp_check/t_test_master_data/pgdata/postmaster.pid"
does not exist
Is server running?
Bail out! system pg_ctl failed
-------------------------------------------

On 2019-07-19 11:59, Tom Lane wrote:
> Michael Paquier <michael(at)paquier(dot)xyz> writes:
>> On Thu, Jul 18, 2019 at 04:14:34PM +0700, Жарков Роман wrote:
>>> I have tested clean REL_11_STABLE.
>>> Commit f02259fe was reverted by df8b5f3e in this branch.
>>> So pg_ctl uses “old” open() function.
>
>> 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
>> 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?).
>
> Hm, I think 0ba06e0 is actually the relevant change here? Though
> 40cfe86 was a necessary cleanup fix.
>
> I'm too tired to dig in the buildfarm database to be sure, but my
> impression is that the failure rate is much-better-but-not-zero.
> So I'd support back-patching those two commits, but I'm not sure
> if that's the end of the conversation.
>
> regards, tom lane

--
regards, Roman