On Tue, Sep 11, 2018 at 10:36:51AM +0000, Higuchi, Daisuke wrote:
> So, attached patch help me and strange message disappeared,
> but I ignore the impact of this for others now.
@@ -386,7 +386,6 @@ pgwin32_safestat(const char *path, struct stat *buf)
return -1;
}
- return r;
}
Simply ignoring errors is not a solution, and makes things worse.
At the end, I have finally been able to put my hands on a Windows VM
which uses VS2015, and I am able to see the problem. In short, Windows
definition of stat() is an utter mess as this documentation page, which
is the latest one available, nicely summarizes:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functions?view=vs-2017
It is possible to get away with the error by using _stat64(), which
returns as result a _stat64 structure. Still, it has one difference
with the native result returned by stat() (which maps to _stat64i32) as
st_size is a 32-bit integer in _stat64i32, and a 64-bit integer with
_stat64. This mess is mixed also with the fact that pgwin32_safestat
relies on a result stored in _stat, so we'd lose the 32 high bits from
the size if we only do a direct mapping, which is bad.
Getting full support for stat() with files larger than 4GB would be the
nicest solution, and requires roughly the following things I think:
- Use _stat64 in pgwin32_safestat.
- Enforce the return result stat to map with _stat64, so as st_size gets
the correct 64-bit size.
Postgres could live in a better world if Windows decided that stat() is
able to handle properly files bigger than 4GB with x64, but as
backward-compatibility matters a lot for Redmond's folks, it is hard to
believe that this is going to ever change. I cannot blame the
compatibility argument either.
--
Michael