| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
| Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #16161: pg_ctl stop fails sometimes (on Windows) |
| Date: | 2019-12-19 15:44:08 |
| Message-ID: | 32374.1576770248@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Alexander Lakhin <exclusion(at)gmail(dot)com> writes:
> Please look at the patch that implements (2). It makes `vcregress
> recoverycheck` pass (and my demo restart test still passes too).
I think we could be a little smarter here. If the problem is
STATUS_DELETE_PENDING, doesn't that affect stat() as well? That is,
if stat() succeeds, we needn't wait, independently of whether it
says S_ISDIR or not? This seems like a noticeable improvement if
true, because it would mean that ordinary file-permission failures
also need not wait. We'd still get confused if we get a permission
failure on a containing directory rather than the file itself, but
that I'm prepared to dismiss as an uncommon case.
Entirely-untested patch along this line attached.
BTW ... it's likely that stat() here is actually going to invoke
pgwin32_safestat(), which has its own opinions about this, and
indeed seems to think we'll get ERROR_DELETE_PENDING. I think
that's harmless here, but it makes me wonder if we should use
a native Windows API instead of going through stat().
> As open(dir) is getting a little more expensive than before, maybe it's
> still worthwhile to patch fsync*(..., isdir,...). I can prepare such a
> patch if so.
I think we should leave that for later, so that the buildfarm can
actually test whatever logic we put in here.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| improve-eacces-handling-2.patch | text/x-diff | 1.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Lakhin | 2019-12-19 20:00:00 | Re: BUG #16161: pg_ctl stop fails sometimes (on Windows) |
| Previous Message | PG Bug reporting form | 2019-12-19 07:14:42 | BUG #16172: failure of vacuum file truncation can cause permanent data corruption |