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: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2019-12-20T04:22:52Z
Lists: pgsql-bugs 
Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> At Thu, 19 Dec 2019 15:09:45 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote in 
>> Alexander Lakhin <exclusion@gmail.com> writes:
>>> It seems that the check for ERROR_DELETE_PENDING was added to
>>> pgwin32_safestat() blindly, the issue wasn't reproduced at that time:
>>> https://www.postgresql.org/message-id/CAB7nPqRJV6trFta-Qzgi6j2feuYR2ZC%2BKHvWdHnbpDG2scTrxw%40mail.gmail.com

>> Hmm, makes one wonder whether that's actually live code.

> Even if it is actually dead code, it seems reasonable as it stands
> since it is intending to read status of an existing file and the
> caller is assumed not to be knowing of ERROR_ACCESS_DENIED.

What I was wondering about was how come, if stat() can see the specific
error code ERROR_DELETE_PENDING, we don't get to see that from CreateFile.
The whole reason we have a problem here is that CreateFile won't return
that code :-( ... so it seems possible that the code in pgwin32_safestat
is just wrong because the case never happens.

			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.