Re: BUG #15858: could not stat file - over 4GB - Mailing list pgsql-hackers

From Juan José Santamaría Flecha
Subject Re: BUG #15858: could not stat file - over 4GB
Date
Msg-id CAC+AXB01gg7PYY9EZoyWY=0hJBRQUoH2O1=dJzFzcp-GQcQ4SQ@mail.gmail.com
Whole thread Raw
Responses Re: BUG #15858: could not stat file - over 4GB
List pgsql-hackers

On Thu, Sep 17, 2020 at 6:04 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Juan José Santamaría Flecha <juanjo.santamaria@gmail.com> writes:
> Thanks for the reminder. Please find attached a rebased version.

(This hasn't shown up on -hackers yet, maybe caught in moderation?)

Thanks for looking into it. Finally, it went through. I will be removing bug-list from now on. 

I took a quick look through this.  I'm not qualified to review the
actual Windows code in win32stat.c, but as far as the way you're
plugging it into the system goes, it looks good and seems to comport
with the discussion so far.

One thing I noticed, which is a pre-existing problem but maybe now
is a good time to consider it, is that we're mapping lstat() to be
exactly stat() on Windows.  That made sense years ago when (we
believed that) Windows didn't have symlinks, but surely it no longer
makes sense.

I will have to take a better look at it, but from a quick look it, all lstat() calls seem to test just if the file exists, and that can be done with a cheap call to GetFileAttributes(). Would a limited (but fast) lstat(), where only st_mode could be informed, be acceptable?

Another more trivial point is that it'd be good to run the new code
through pgindent before committing.

I do not have pgindent in the WIN32 machine, but I will try to for the next version.

Regards,

Juan José Santamaría Flecha

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgindent vs dtrace on macos
Next
From: Tomas Vondra
Date:
Subject: Re: WIP: BRIN multi-range indexes