Re: BUG #15858: could not stat file - over 4GB

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, williamedwinallen(at)live(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, Magnus Hagander <magnus(at)hagander(dot)net>
Subject: Re: BUG #15858: could not stat file - over 4GB
Date: 2019-06-26 02:22:36
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs pgsql-hackers

On Tue, Jun 25, 2019 at 12:00:45PM +0200, Juan José Santamaría Flecha wrote:
> I will not have much time for this list in the next couple of weeks,
> so I will send this patch in its current WIP state rather than
> stalling without a reply.
> Most of its functionality comes from Sergey's patch with some cosmetic
> changes, and the addition of the 64 bits struct stat and fstat().

The former patch was rather impressive. Or scary. Or both. At which
extent have you tested it? I think that we really need to make sure
of a couple of things which satisfy our needs:
1) Are we able to fix the issues with stat() calls on files larger
than 2GB and report a correct size?
2) Are we able to detect properly that files pending for deletion are
discarded with ENOENT?
3) Are frontends able to use the new layer?

It seems to me that you don't need the configure changes.

Instead of stat_pg_fixed which is confusing because it only involves
Windows, I would rename the new file to stat.c or win32_stat.c. The
location in src/port/ is adapted. I would also move out of
win32_port.h the various inline declarations and keep only raw
declarations. That could be much cleaner.

The code desperately needs more comments to help understand its
logic. Don't we have in the tree an equivalent of cvt_ft2ut? What
does cvt_attr2uxmode do? It would be nice to avoid conversion
wrappers as much as possible, and find out system-related equivalents
if any, and actually if necessary.

+static unsigned short
+cvt_attr2uxmode(int attr, const _TCHAR * name)
This looks rather bug-prone...

I think that this stuff has not been tested and would break at
compilation. If src/tools/msvc/ is not changed, then the
new file won't get included in the compiled set.

In response to


Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2019-06-26 02:26:42 Re: BUG #15872: copy command does not skip special character
Previous Message Michael Paquier 2019-06-26 02:01:25 Re: Bug

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-06-26 02:33:09 Re: GiST VACUUM
Previous Message Alexander Korotkov 2019-06-26 01:20:06 Re: GiST "choose subtree" support function to inline penalty