From: Tom Lane <tgl@sss.pgh.pa.us>
To: =?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?=
 <juanjo.santamaria@gmail.com>
cc: Michael Paquier <michael@paquier.xyz>, williamedwinallen@live.com,
        pgsql-bugs@lists.postgresql.org, Magnus Hagander <magnus@hagander.net>
Subject: Re: BUG #15858: could not stat file - over 4GB
In-reply-to: <16138.1560966010@sss.pgh.pa.us>
References: <15858-9572469fd3b73263@postgresql.org>
 <20190619012604.GC2135@paquier.xyz>
 <CAC+AXB0j9pN4z5XxMbn6+kcE_QM+CErjfYp-vVz2rU4suU7u=g@mail.gmail.com>
 <16138.1560966010@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Wed, 19 Jun 2019 13:40:10 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <17043.1560967356.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 19 Jun 2019 14:02:36 -0400
Message-ID: <17044.1560967356@sss.pgh.pa.us>
Precedence: bulk

I wrote:
> Another issue here is that pgwin32_safestat() probably needs revisited
> as to its scope and purpose.  Its use of GetFileAttributesEx() can
> presumably be dropped.  I don't actually believe the header comment
> claiming that stat() is not guaranteed to update the st_size field;
> there's no indication of that in the Microsoft documentation.  What
> seems more likely is that that's a garbled version of the truth,
> that you won't get a correct value of _st_size for files over 4GB.

So after further digging around, it seems that this is wrong.  The
existence of pgwin32_safestat() can be traced back to these threads:

https://www.postgresql.org/message-id/flat/528853D3C5ED2C4AA8990B504BA7FB8=
50106DF10%40sol.transas.com
https://www.postgresql.org/message-id/flat/528853D3C5ED2C4AA8990B504BA7FB8=
50106DF2F%40sol.transas.com

in which it's stated that

    It seems I've found the cause and the workaround of the problem.
    MSVC's stat() is implemented by using FindNextFile().
    MSDN contains the following suspicious paragraph =D0=B0bout FindNextFi=
le():
        "In rare cases, file attribute information on NTFS file systems
        may not be current at the time you call this function. To obtain
        the current NTFS file system file attributes, call
        GetFileInformationByHandle."
    Since we generally cannot open an examined file, we need another way.

I'm wondering though why we adopted the existing coding in the face of
that observation.  Couldn't the rest of struct stat be equally out of
date?

In short it seems like maybe we should be doing something similar to the
patch that Sergey actually submitted in that discussion:

https://www.postgresql.org/message-id/528853D3C5ED2C4AA8990B504BA7FB850658=
BA5C%40sol.transas.com

which reimplements stat() from scratch on top of GetFileAttributesEx(),
and thus doesn't require any assumptions at all about what's available
from the toolchain's <sys/stat.h>.

			regards, tom lane