On Sat, May 9, 2020 at 2:49 AM Alvaro Herrera
wrote:
> On 2018-Sep-13, Tom Lane wrote:
>
> > What I was vaguely imagining is that win32_port.h could #include
> > whichever Windows header defines these functions and structs, and
> > then do
> >
> > #define stat __stat64
> >
> > static inline ...
On 2018-Sep-13, Tom Lane wrote:
> What I was vaguely imagining is that win32_port.h could #include
> whichever Windows header defines these functions and structs, and
> then do
>
> #define stat __stat64
>
> static inline ... __stat64(...) { return _stat64(...); }
>
> What would need testing is
Robert Haas writes:
> I do not think that using #define to play clever tricks like this can
> reasonably be classified as non-invasive. Non-invasive doesn't mean
> it touches a small number of lines; it means it's unlikely to break
> stuff. Otherwise,
> #define continue break
> would qualify as
On Thu, Sep 13, 2018 at 10:05 PM, Michael Paquier wrote:
> On Thu, Sep 13, 2018 at 02:23:47PM -0400, Robert Haas wrote:
>> This, to me, seems way too clever. Replacing 'struct stat' with
>> something else everywhere in the code is more churn, but far less
>> likely to have surprising
On Thu, Sep 13, 2018 at 02:23:47PM -0400, Robert Haas wrote:
> This, to me, seems way too clever. Replacing 'struct stat' with
> something else everywhere in the code is more churn, but far less
> likely to have surprising consequences down the road. Or so I would
> think, anyway.
I don't have
On Thu, Sep 13, 2018 at 10:29 AM, Tom Lane wrote:
> What I was vaguely imagining is that win32_port.h could #include
> whichever Windows header defines these functions and structs, and
> then do
>
> #define stat __stat64
>
> static inline ... __stat64(...) { return _stat64(...); }
>
> What would
Michael Paquier writes:
> On Wed, Sep 12, 2018 at 08:17:05PM -0400, Tom Lane wrote:
>> 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
On Wed, Sep 12, 2018 at 08:17:05PM -0400, Tom Lane wrote:
> 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 :-(.
There are 130 places where "struct stat " is used, so I'd rather
Michael Paquier 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
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
On Tue, Sep 11, 2018 at 11:27:08PM -0400, Tom Lane wrote:
> Michael Paquier writes:
>> 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
Michael Paquier writes:
> 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:
>
On Tue, Sep 11, 2018 at 10:36:51AM +, 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;
}
-
Michael-san,
From: Michael Paquier [mailto:mich...@paquier.xyz]
>Does something like the patch attached help?
>This makes sure that st_size is set correctly for files with a size larger
>than 4GB.
Thank you for creating patch, but this does not solve current problem.
Of cause setting wrong
Higuchi-san,
On Mon, Sep 10, 2018 at 03:44:54PM +0900, Michael Paquier wrote:
> Yes, the fix needs to happen there. It seems to me that what we are
> looking for here is to complete the calculation of st_size with
> nFileSizeHigh, so as we are able to compile a correct 64-bit integer
> size,
On Mon, Sep 10, 2018 at 02:01:53AM +, Higuchi, Daisuke wrote:
> This mail is about following bug report post:
> https://www.postgresql.org/message-id/flat/153442391458.1505.9181095584291689853%40wrigleys.postgresql.org
Thanks for following up on this thread. I marked that as one of my
TODOs
16 matches
Mail list logo
