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
signature.asc
Description: PGP signature