Re: stat() on Windows might cause error if target file is larger than 4GB

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

In response to

Responses

Browse pgsql-hackers by date

  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