From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | "Higuchi, Daisuke" <higuchi(dot)daisuke(at)jp(dot)fujitsu(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: stat() on Windows might cause error if target file is larger than 4GB |
Date: | 2018-09-13 00:17:05 |
Message-ID: | 32716.1536797825@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Wed, Sep 12, 2018 at 12:47:31PM +0900, Michael Paquier wrote:
>> That's exactly what I would like to do and what I meant two paragraphs
>> above as that's the only solution I think would be clean, and this would
>> take care of st_size nicely. I have not tested (yet), but some tweaks
>> in win32_port.h could be enough before mapping lstat to stat?
> FWIW, I have been digging into this one and as "struct stat" is already
> an existing structure when it comes to MSVC, enforcing a mapping of
> __stat64 to that is proving to be tedious in one of the port headers.
Yeah, I was afraid of that. We could invent a typedef "pg_struct_stat"
that maps to the right thing, but using that everywhere would be a mighty
invasive change :-(. And we can't just "#define stat __stat64" because
that would break the calls to stat(). Or wait, maybe we could do that
and also have a one-liner function named __stat64 that would catch the
calls and redirect to _stat64?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-09-13 00:20:52 | Re: [Patch] Create a new session in postmaster by calling setsid() |
Previous Message | Michael Paquier | 2018-09-13 00:09:11 | Re: stat() on Windows might cause error if target file is larger than 4GB |